I have one quick question.
Is it normal that bash (i am using 4.4.11) is not displaying lines/text that is separated / end with plain \r
?
I was a bit surprised to see this behavior:
$ a=$(printf "hello\ragain\rgeorge\r\n")
$ echo "$a"
george
But "hello again" text is still there,somehow "hidden":
$ echo "$a" |od -w32 -t x1c
0000000 68 65 6c 6c 6f 0d 61 67 61 69 6e 0d 67 65 6f 72 67 65 0d 0a
h e l l o \r a g a i n \r g e o r g e \r \n
And as soon as we just play with bash is fine.... But is this a potential security risk? What if contents of variable "a" come from outter world and include "bad commands" instead of just hello?
Another test, a bit unsecure this time:
$ a=$(printf "ls;\rGeorge\n")
$ echo "$a"
George
$ eval "$a"
0 awkprof.out event-tester.log helloworld.c oneshot.sh rightclick-tester.py tmp uinput-simple.py
<directory listing appears with an error message at the end for command George>
Imagine a hidden rm
instead of a hidden ls
.
Same behavior when using echo -e:
$ a=$(echo -e "ls;\rGeorge\r\n"); echo "$a"
George
Is it me that does something wrong...?
bash
, though; it is entirely up to the terminal how to "display" the carriage return, or how to display the overwritten characters. For example, it would be perfectly valid for a terminal to display-\r|
as something resembling a plus sign, rather than just a pipe. – chepner Apr 03 '17 at 14:07bash
just writes bytes to a file; it's up to whoever reads those bytes to interpret them. – chepner Apr 03 '17 at 14:28printf
, which is a bash built-in command (although it also exists as a standalone executable), interprets the\r
(a sequence of two bytes:0x5c
and0x72
and produces the carriage return (a single byte:0x0d
). Then, yes, the terminal interprets the byte0x0d
in a special way, but it does not interpret the original string\r
. – Suzanne Soy Feb 15 '19 at 09:52