The Computer Oracle

Is there a binary-safe "triple less than" <<< operator in bash?

--------------------------------------------------
Hire the world's top talent on demand or became one of them at Toptal: https://topt.al/25cXVn
and get $2,000 discount on your first invoice
--------------------------------------------------

Take control of your privacy with Proton's trusted, Swiss-based, secure services.
Choose what you need and safeguard your digital life:
Mail: https://go.getproton.me/SH1CU
VPN: https://go.getproton.me/SH1DI
Password Manager: https://go.getproton.me/SH1DJ
Drive: https://go.getproton.me/SH1CT


Music by Eric Matyas
https://www.soundimage.org
Track title: Forest of Spells Looping

--

Chapters
00:00 Is There A Binary-Safe &Quot;Triple Less Than&Quot; ≪≪≪ Operator In Bash?
00:34 Answer 1 Score 5
01:03 Accepted Answer Score 34
01:45 Answer 3 Score 0
03:06 Thank you

--

Full question
https://superuser.com/questions/342982/i...

--

Content licensed under CC BY-SA
https://meta.stackexchange.com/help/lice...

--

Tags
#bash #redirection

#avk47



ACCEPTED ANSWER

Score 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.




ANSWER 2

Score 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.




ANSWER 3

Score 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.