Esta es una pregunta bastante hipotética, así que no me pregunten por qué querría hacer esto.
Suponiendo que tengo una variable GIFque contiene datos binarios, y suponiendo que no puedo usar el |operador de tubería , la siguiente debería ser la forma correcta de usar el operador 'triple-less-than':
openssl enc -base64 <<< $GIF
Sin embargo, me parece que <<<no es seguro para los binarios y, por lo tanto, los datos binarios se corrompen.
¿Existe un equivalente binario seguro?
Respuestas:
La redirección de cadena here ( <<<) es una forma simple de redirección de documento here ( <<). Aquí la redirección de cadenas no es "segura para binarios"; Bash realizará una expansión en la cadena aquí. Además, Bash agregará una nueva línea al final de la cadena aquí (emita el comando xxd -p <<< "foo"y obtendrá 666f6f0aa cambio).
Su única apuesta segura, con exclusión de los tubos, es de E / S de redirección .
Pregunta similar no segura binaria aquí . Puede almacenar datos codificados y probar esto
COMMAND_WITH_BIN_INPUT <(uudecode <(echo "$uuEncodedData")) sin embargo esto no está lejos de
echo "$uuEncodedData"|uudecode|COMMAND_WITH_BIN_INPUTpero sin pipa metachar.
od -a <<< ""y verá en nllugar del valor hexadecimal.
Bash no es seguro para binarios en general, y corromperá nulos y nuevas líneas en variables que contengan contenido binario durante la sustitución.
Así que creo que la respuesta es "no", pero más fundamentalmente "no en un lenguaje de scripts de shell" porque todos parecen tener problemas con el binario.
Sin embargo, diría que planea obtener los datos en $ GIF, en su lugar los obtiene en un archivo o usa python como un lenguaje de script alternativo que manejará los datos binarios sin problemas.
$GIF, para empezar, no tiene binario completo incluso antes de comenzar. Sin embargo, a excepción del personaje NUL, está reteniendo a todos los demás. (como referencia: vaab.blog.kal.fr/2014/05/03/… )