Questa è una domanda piuttosto ipotetica, quindi per favore non chiedermi perché vorrei farlo.
Supponendo che io abbia una variabile GIFche contiene dati binari e supponendo che non riesca a usare l' |operatore pipe , il seguente dovrebbe essere il modo corretto di usare l' operatore "triple-less-than":
openssl enc -base64 <<< $GIF
Tuttavia, mi sembra che <<<non sia binario e quindi i dati binari vengano danneggiati.
Esiste un equivalente binario sicuro?
Risposte:
Il reindirizzamento here string ( <<<) è una forma semplice del reindirizzamento here document ( <<). Qui il reindirizzamento delle stringhe non è "binario sicuro"; Bash eseguirà l'espansione sulla stringa qui. Inoltre, Bash aggiungerà una nuova riga alla fine della stringa qui (emetti il comando xxd -p <<< "foo"e otterrai 666f6f0ain cambio).
La vostra unica scommessa sicura, esclusi i tubi, è redirezione I / O .
Domanda simile non binaria sicura qui . Puoi archiviare i dati codificati e provare questo
COMMAND_WITH_BIN_INPUT <(uudecode <(echo "$uuEncodedData")) tuttavia questo non è lontano da
echo "$uuEncodedData"|uudecode|COMMAND_WITH_BIN_INPUTma senza pipe metachar.
od -a <<< ""e vedrai nlinvece il valore esadecimale.
Bash non è binario sicuro in generale e corromperà null e newline in variabili che contengono contenuto binario durante la sostituzione.
Quindi penso che la risposta sia "no", ma fondamentalmente "non in un linguaggio di scripting di shell" perché sembrano avere tutti problemi con il binario.
Direi comunque che prevedi di inserire i dati in $ GIF, invece li inserisci in un file o usi python come un linguaggio di script alternativo che gestirà i dati binari senza problemi.
$GIF, per cominciare, non tiene il binario completo nemmeno prima di iniziare. Tuttavia, ad eccezione del carattere NUL, contiene tutti gli altri. (come riferimento: vaab.blog.kal.fr/2014/05/03/… )