This is a rather hypothetical question, so please don't ask me why I'd want to do this.
Assuming that I have a variable GIF that contains binary data, and assuming that I cannot use the pipe | operator, the following should be the correct way to use 'triple-less-than' operator:
openssl enc -base64 <<< $GIF
However, it appears to me that <<< is not binary-safe and therefore the binary data gets corrupt.
Is there a binary-safe equivalent?
The here string redirection (<<<) is a simple form of here document redirection (<<). Here string redirection is not "binary safe"; Bash will perform expansion on the here string. In addition, Bash will append a new-line to the end of the here string (issue the command xxd -p <<< "foo" and you'll get 666f6f0a in return).
Your only safe bet, excluding pipes, is I/O redirection.
Similar not binary safe question here. You can store encoded data and try this
COMMAND_WITH_BIN_INPUT <(uudecode <(echo "$uuEncodedData")) however this is not far from
echo "$uuEncodedData"|uudecode|COMMAND_WITH_BIN_INPUT but without pipe metachar.
od -a <<< "" and you'll see nl instead of the hex value. Bash isn't binary safe in general, and will corrupt nulls and newlines in variables containing binary content during substitution.
So I think the answer is "no" but more fundamentally "not in a shell scripting language" because they all seem to have problems with binary.
I'd say however you plan to get the data into $GIF, you instead get it into a file, or use python as an alternative scripting language which will handle binary data without problems.
first define some test set - three characters, a and a - in total 5 characters (or bytes if you like to understand it that way). the second command "xxd" after the pipe symbol just prints the received data in a very compacted hexadecimal fashion - all chars convert to two digits of hexadecimal represenation:
$ echo "abc\0\r" | xxd -p 6162635c305c720a as you can see each char beyond the quotes is taken literally and results in a two digit hex number. backslashes will result in "5c" hex number pairs. the "0" will result in hex "30" and an additional "0a" is in place.
$ echo -e "abc\0\r" | xxd -p 616263000d0a now in above lines the option "-e" instructs the "echo" command to interpret regular expressions for the and the characters. as you can see they nicely translate to hex "00" and hex "0d".
$ echo -en "abc\0\r" | xxd -p 616263000d with the final variant above the freshly added "-n" option even the former "0a" as appended by the echo command does disappear. the 5 characters from the test set are resulting in a print of 10 hexadecimal digits, each pair of two digit matches one of the input chars. thus proof that the echo command with options and the pipe symbol works as we would like it to work is achieved - at least for the test set.
now its up to you to hook in your data on the left side of the pipe and on the right side your worker.
$GIF, for a start, is not holding full-binary even before starting. However, to the exception of the NUL character, it is holding all the others. (as a ref: vaab.blog.kal.fr/2014/05/03/… )