Tengo una pregunta rapida.
¿Es normal que bash (estoy usando 4.4.11) no muestra líneas / texto que está separado / finaliza con plain \r
?
Me sorprendió un poco ver este comportamiento:
$ a=$(printf "hello\ragain\rgeorge\r\n")
$ echo "$a"
george
Pero el texto "hola de nuevo" sigue ahí, de alguna manera "oculto":
$ 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
Y tan pronto como juguemos con bash está bien ... ¿Pero es esto un riesgo potencial de seguridad? ¿Qué sucede si los contenidos de la variable "a" provienen de un mundo externo e incluyen "comandos incorrectos" en lugar de solo hola?
Otra prueba, un poco insegura esta vez:
$ 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 un oculto en rm
lugar de un oculto ls
.
Mismo comportamiento cuando se usa echo -e:
$ a=$(echo -e "ls;\rGeorge\r\n"); echo "$a"
George
¿Soy yo quien hace algo mal ...?
fuente
bash
, sin embargo; depende completamente de la terminal cómo "mostrar" el retorno de carro, o cómo mostrar los caracteres sobrescritos. Por ejemplo, sería perfectamente válido que un terminal se muestre-\r|
como algo parecido a un signo más, en lugar de solo una tubería.bash
solo escribe bytes en un archivo; depende de quien lea esos bytes interpretarlos.printf
, que es una fiesta de comando integrado (aunque también existe como un archivo ejecutable independiente), interpreta la\r
(una secuencia de dos bytes:0x5c
y0x72
y produce el retorno de carro (un solo byte:0x0d
.) Entonces, sí, el terminal interpreta el byte0x0d
de una manera especial, pero no interpreta la cadena original\r
.