Це досить гіпотетичне питання, тому, будь ласка, не запитуйте мене, чому я хотів би це зробити.
Якщо припустити, що у мене є змінна, GIFяка містить двійкові дані, і якщо припустити, що я не можу використовувати |оператор труби , слід використовувати правильний спосіб використання оператора "потрійний менший ніж":
openssl enc -base64 <<< $GIF
Однак мені здається, що <<<це не є безпечним для бінарних даних, і тому двійкові дані пошкоджуються.
Чи існує бінарний безпечний еквівалент?
Відповіді:
Тут рядок Перенаправлення ( <<<) є простою формою тут документ перенаправлення ( <<). Тут перенаправлення рядків не є "бінарним безпечним"; Bash виконає розширення на рядок тут. Крім того, Bash додасть новий рядок до кінця рядка here (видайте команду, xxd -p <<< "foo"і ви отримаєте 666f6f0aвзамін).
Ваша єдина безпечна ставка, крім труб, - це перенаправлення вводу / виводу .
Подібне не бінарний безпечний питання тут . Ви можете зберігати закодовані дані та спробувати це
COMMAND_WITH_BIN_INPUT <(uudecode <(echo "$uuEncodedData")) однак це далеко не далеко
echo "$uuEncodedData"|uudecode|COMMAND_WITH_BIN_INPUTале без метахарів труб.
od -a <<< ""і ви побачите nlзамість шістнадцяткового значення.
Bash взагалі не є бінарним безпечним і пошкоджує нулі та нові рядки змінних, що містять бінарний вміст під час заміни.
Тому я думаю, що відповідь "ні", але більш принципово "не в мові сценаріїв оболонок", тому що всі вони, мабуть, мають проблеми з бінарними.
Я б сказав, однак, ви плануєте отримати дані в $ GIF, замість цього ви отримаєте їх у файл або використовуєте python як альтернативну мову сценаріїв, яка без проблем обробляє бінарні дані.
$GIF, для початку, не має повноцінного двійкового файлу навіть перед запуском. Однак, за винятком символу NUL, він тримає всі інші. (як ref: vaab.blog.kal.fr/2014/05/03/… )