5

I have a device in /var/iot/data which I'm trying to get the data from remotely.

On the machine itself:

# cat /var/iot/data | xxd -ps -c 32
80de004a030270055678013ac591e5c6abac2185f4319c8088e3

That's the correct data.

If I run the same thing remotely, it looks correct:

$ ssh -T -x dragino 'cat /var/iot/data | xxd -ps -c 32' 
80de004a030270055678013ac591e5c6abac2185f4319c8088e3

But it's actually coming through with a bunch of escape sequences:

$ ssh -T -x dragino 'cat /var/iot/data | xxd -ps -c 32' | xxd
00000000: 1b5d 3131 3b23 3138 3464 3666 0738 3064  .]11;#184d6f.80d
00000010: 6530 3034 6130 3330 3237 3030 3535 3637  e004a03027005567
00000020: 3830 3133 6163 3539 3165 3563 3661 6261  8013ac591e5c6aba
00000030: 6332 3138 3566 3433 3139 6338 3038 3865  c2185f4319c8088e
00000040: 330a 1b5d 3131 3b23 3139 3139 3730 07    3..]11;#191970.

What is all that .]11;#184d6f. at the beginning?

closed as off-topic by Greg Bell, Jeff Schaller Aug 15 at 0:07

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Jeff Schaller
If this question can be reworded to fit the rules in the help center, please edit the question.

  • I've had this exact problem with echo, it just adds the \n at the end and I had no idea why, in your case these are actually the control characters before and after, yet the #184d6f and #191970 makes me wonder why there's a hex color representation there, it's not something that bash usually works with. – Yaron Aug 14 at 12:49
  • Related but not an answer: serverfault.com/a/746638/237978 – Greg Bell Aug 14 at 12:53
  • 3
    Do you have a .bashrc on the remote server? That may be generating those strings. What does `ssh -T -x dragino 'cat /dev/null' | xxd show? – wurtel Aug 14 at 13:52
  • The two commands are not equivalent. Could you also try ssh -T -x dragino 'cat /var/iot/data' | xxd -ps -c 32 ? As far as I can see, there is no reason to run xxd remotely. – Kusalananda Aug 14 at 15:06
  • What shell are you using on the dragino machine? – icarus Aug 14 at 15:20
11

The sequences are

OSC 1 1 ; # 1 8 4 d 6 f BEL
OSC 1 1 ; # 1 9 1 9 7 0 BEL

which is are xterm control sequences to request to set the terminal text background color. Probably caused by a badly written shell initialization file which causes these to be output in an attempt to distinguish the output of commands from the shell prompt, but does so unconditionally

  • 1
    This was it. My fault. Smoking shoe award. I've setup ssh to change my terminal background so I'm always reminded that I'm on a remote machine. Stupid! Will delete the question. Thanks for this decoding Icarus - it's what made the lightbulb turn on. – Greg Bell Aug 14 at 20:50
2

It's likely that you're being bitten by bash's bizarre behavior with respect to initialization files. Bash loads .bashrc in two completely different cases:

So when you log in over SSH, bash loads .bash_profile if the shell is interactive, and .bashrc if it isn't. Passing -T to ssh doesn't affect that, and it actually doesn't make a difference in your case since SSH only creates a terminal if you don't pass a command or if you pass -t to ssh.

Your .bashrc apparently contains some code that interacts by the terminal by emitting some escape sequences (specifically, to set the background color). To avoid this causing havoc, don't run anything from .bashrc if bash isn't running interactively. Put this at the top of .bashrc:

if [[ $- != *i* ]]; then return; fi
1

I had an function called ssh which set terminal background before ssh'ing so that I always know what terminal is remote. Sorry for wasting everyone's time.

  • And the moral of this is not to call it ssh, but something else, rt for remote terminal, or term. I would avoid gcc for get copious characters. Changing the behavior of standard commands frequently works out poorly, the classic example being alias rm="rm -i". – icarus Aug 15 at 0:35
-1

The -T option for ssh will cause the remote SSH server to allocate a virtual terminal for the session and therefore programs (such as the shell) will act accordingly.

For transferring arbitrary data omit the -T option.

  • 2
    You're thinking of the -t option. The -T does the opposite, explicitly disables pseudo-terminal allocation. – Kusalananda Aug 14 at 16:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.