Esta é uma pergunta bastante hipotética, portanto, não me pergunte por que eu gostaria de fazer isso.
Supondo que eu tenha uma variável GIFque contenha dados binários e supondo que eu não possa usar o |operador de canal , a seguinte deve ser a maneira correta de usar o operador 'triplo-menos que':
openssl enc -base64 <<< $GIF
No entanto, parece-me que <<<não é seguro para binários e, portanto, os dados binários ficam corrompidos.
Existe um equivalente binário-seguro?
Respostas:
O redirecionamento de string here ( <<<) é uma forma simples de redirecionamento de documento aqui ( <<). Aqui o redirecionamento de string não é "binário seguro"; O Bash executará a expansão na string here. Além disso, o Bash acrescentará uma nova linha ao final da string here (emita o comando xxd -p <<< "foo"e você receberá 666f6f0aem troca).
Sua única aposta segura, excluindo tubos, é I / O redirecionamento .
Pergunta segura não binária semelhante aqui . Você pode armazenar dados codificados e tentar isso
COMMAND_WITH_BIN_INPUT <(uudecode <(echo "$uuEncodedData")) no entanto, isso não está longe de
echo "$uuEncodedData"|uudecode|COMMAND_WITH_BIN_INPUTmas sem metacarpo.
od -a <<< ""e verá em nlvez do valor hexadecimal.
Bash não é binário seguro em geral e corromperá nulos e novas linhas em variáveis que contêm conteúdo binário durante a substituição.
Então, acho que a resposta é "não", mas mais fundamentalmente "não em uma linguagem de script de shell", porque todos parecem ter problemas com o binário.
Eu diria que, no entanto, você planeja colocar os dados em $ GIF, em vez disso, coloca-os em um arquivo ou usa o python como uma linguagem de script alternativa que manipulará os dados binários sem problemas.
$GIF, para começar, não fica com o binário completo antes mesmo de começar. No entanto, à exceção do caractere NUL, ele está mantendo todos os outros. (como um ref: vaab.blog.kal.fr/2014/05/03/… )