30

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?

1
  • Please note that bash variables can't contains NUL chars. So your variable $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/… )
    – vaab
    Apr 28, 2016 at 4:05

3 Answers 3

34

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.

2
5

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.

1
  • 1
    References or precision, or simple examples would have been more helpful than a wild guess and general feeling from your side. There are ways to get binary data parsed through bash.
    – vaab
    Apr 28, 2016 at 4:08
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .