这是一个相当假设性的问题，所以请不要问我为什么要这样做。
假设我有一个GIF包含二进制数据的变量，并且假设我不能使用管道|运算符，则以下应该正确使用“三重小于”运算符的方法如下：
openssl enc -base64 <<< $GIF
然而，在我看来<<<，二进制安全因此二进制数据被损坏。
是否存在二进制安全的等效物？
答案1
这这里是字符串重定向（<<<）是一种简单的形式这里的文件重定向（<<）。here 字符串重定向不是“二进制安全的”；Bash 将对 here 字符串执行扩展。此外，Bash 还会将换行符附加到 here 字符串的末尾（发出命令xxd -p <<< "foo"，您将得到666f6f0a返回结果）。
除了管道之外，唯一安全的选择是I/O 重定向。
类似的非二进制安全问题这里。您可以存储编码数据并尝试此操作
COMMAND_WITH_BIN_INPUT <(uudecode <(echo "$uuEncodedData"))
然而这与
echo "$uuEncodedData"|uudecode|COMMAND_WITH_BIN_INPUT
但没有管道元字符。
答案2
Bash 通常不是二进制安全的，并且会在替换过程中破坏包含二进制内容的变量中的空值和换行符。
因此我认为答案是“否”，但更根本的答案是“不是在 shell 脚本语言中”，因为它们似乎都存在二进制问题。
我想说的是，无论您计划如何将数据放入 $GIF，您都可以将其放入文件中，或者使用 python 作为替代脚本语言，它可以毫无问题地处理二进制数据。
答案3
首先定义一些测试集 - 三个字符，a 和 a - 总共 5 个字符（或者如果您愿意这样理解的话，是字节）。管道符号后的第二个命令“xxd”只是以非常紧凑的十六进制方式打印接收到的数据 - 所有字符都转换为两位十六进制表示：
$ echo "abc\0\r" | xxd -p
6162635c305c720a
如您所见，引号以外的每个字符都按字面意思理解，结果是一个两位数的十六进制数。反斜杠将产生“5c”十六进制数对。“0”将产生十六进制“30”，并且还有一个“0a”。
$ echo -e "abc\0\r" | xxd -p
616263000d0a
现在在上面的几行中，选项“-e”指示“echo”命令解释和字符的正则表达式。如您所见，它们很好地转换为十六进制“00”和十六进制“0d”。
$ echo -en "abc\0\r" | xxd -p
616263000d
使用上述最后一种变体，新添加的“-n”选项甚至连 echo 命令附加的先前“0a”都会消失。测试集中的 5 个字符导致打印出 10 个十六进制数字，每对两位数字与一个输入字符匹配。因此，证明了带有选项和管道符号的 echo 命令可以按我们希望的方式工作 - 至少对于测试集而言。
现在你需要将你的数据挂接到管道的左侧，将你的工作者挂接到管道的右侧。