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?

Greg Bell
  • 595
  • 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 '19 at 12:49
  • Related but not an answer: https://serverfault.com/a/746638/237978 – Greg Bell Aug 14 '19 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 '19 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 '19 at 15:06
  • What shell are you using on the dragino machine? – icarus Aug 14 '19 at 15:20
  • I'm voting to close this question as off-topic because it was a very specific, self-caused problem, unlikely to apply to others. – Greg Bell Aug 14 '19 at 23:09
  • @GregBell Oh yes, this Q does apply to others, and should not be closed. If you're so embarassed by it (I don't see why), you can ask for it to be anonymized (via the "Contact" link at the bottom of the page). –  Aug 15 '19 at 00:22
  • @mosvy other SO answers address the solutions to similar problems that have real (not self-inflicted) causes. Thanks for the anonymize tip. – Greg Bell Aug 16 '19 at 03:10

4 Answers4

10

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

icarus
  • 17,920
  • 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 '19 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
Gilles 'SO- stop being evil'
  • 829,060
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.

Greg Bell
  • 595
  • 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 '19 at 00: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.

Timothy Baldwin
  • 432