На самом деле я искал перенаправление вывода сразу в два отдельных потока, но оказалось, что это не нужно, ибо задача сводилась к тому, чтобы отображать вывод некоей программы на экран и одновременно писать этот же вывод в log-файл.

В Linux нашлось готовое решение: команда tee

Команда tee делает следующее — берет переданный ей от другой команды или потока команд (pipe) вывод, пишет его в файл и одновременно выводит на stdout. Вывод на stdout можно переопределить дальше, например, устроить вывод на отдельный терминал, но об этом далее.

Общий синтаксис таков:

<команда>|tee [параметры] файл1 [файл2 файл3 ...]

где:

<команда> — любая команда оболочки Linux
| — обозначение перенаправления, вывод команды <команда> передается tee
файл1 [файл2 файл3 ...] — файлы, в которые необходимо вести запись.

ls | tee log.txt

Выведет список файлов текущего каталога на консоль и одновременно сохранит вывод в файл log.txt

Если добавить к команде tee параметр -a, то информация будет дозаписываться в указанные файлы. Без этого параметра файлы будут перезаписаны.

Чтобы не использовать какие-то команды, создадим тестовый скрипт tscript, десять раз выводящий на консоль случайное число:

#!/bin/bash

SEC=1
CTR=10

echo "Test script, write to STDOUT random number after $SEC sec."

while [ "$CTR" -ne 0 ];do
    let "CTR=CTR-1"
    printf '%x Number: %x\n' $CTR $RANDOM
    sleep $SEC
done

echo "Complete!"

Теперь в каталоге со скриптом выполним:

./tscript | tee log.txt

На экран будут выведены случайные числа, они же будут в файле log.txt

./tscript | tee -a log.txt

Аналогично, только log-файл будет дополнен новыми случайными числами.

После команды tee, вывод можно перенаправить и дальше, например, можно совместить этот пример с выводом на другой терминал (копия):

./tscript | tee ./test.log >/dev/tty4

Можно пойти дальше и скрипт сделать автономным, «демонизировать» его, тогда можем, запустив следующую команду, или использовав ее в скрипте, освободить и/или текущую консоль или запускающий скрипт для дальнейших действий:

./tscript | tee ./test.log >/dev/tty4 &

Вывод на консоль четвертого терминала (tty4):

Вывод в test.log:

Test script, write to STDOUT random number after 1 sec.

9 Number: 2378
8 Number: 2cf9
7 Number: 132c
6 Number: 4a3c
5 Number: 6367
4 Number: 3384
3 Number: 5660
2 Number: 6655
1 Number: 6141
0 Number: 1870
Complete!

Тестовый пример на GitHub

Кстати, обязательно загляните, там есть дополнительные примеры использования:

1. Команда Tee в Linux: Примеры Использования (копия).

Команда, вы будете смеяться, очень простая:

tty

Результат работы на локальном терминале (с консоли, «с клавиатуры») и «без иксов»:

/dev/tty1

Эмуляторам терминала (из иксов или PuTTY), естественно, выделяется виртуальный терминал:

Иксы:

PuTTY:

В некоторых встраиваемых системах команда tty может не работать.

В переменную скрипта можно сохранить результат выполнения команды:

#!/bin/bash

CUR_TTY=`tty`
echo $CUR_TTY

Вывод (для первого случая):

/dev/tty1

Неделя инвентаризации продолжается, так что настало время поговорить и о тестировании устройств на битые сектора под Linux.

Естественно, все команды выполняются от root или через sudo.

badblocks -v /dev/sdc2 >/tmp/badsect.txt

где:
-v — подробный вывод информации о процессе. Правда слово «подробный» здесь некоторое преувеличение. В процессе вывод будет такой:

Checking blocks 0 to 1805311
Checking for bad blocks (read-only test):

Но, без ключа -v программа будет молчать, как партизан на допросе.

/dev/sdc2 — раздел, который необходимо проверить.
/tmp/badsect.txt — куда выводить список bad-секторов.

Программка стандартная (входит в пакет e2fsprogs), так что в неурезанных дистрибутивах есть.

Служебные сообщения она выводит на stderr, так что «наблюдать» за процессом перенаправление вывода в файл не помешает

Если после окончания работы утилиты вывод такой, то все OK, битых секторов нет:

Checking blocks 0 to 1805311
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found. (0/0/0 errors)

Примечание: Если у вас только консоль, посмотреть список разделов можно командой

ls /dev/sd*

Вывод:
/dev/sda /dev/sdb /dev/sdb1 /dev/sdb2 /dev/sdc /dev/sdc1 /dev/sdc2

Или через fdisk:
fdisk -l

Чтобы ОС не могла записать данные в битый сектор.
Примечание: способ работает только на ext файловых системах (ext2, ext3, ext4)

e2fsck -l /tmp/badsect.txt /dev/sdc2

где:

-l взять список bad-блоков из файла и пометить их.
/tmp/badsect.txt — файл со списком bad-секторов
/dev/sdc2 — раздел, с которым надо работать.

Плюсы:
+ способ работает почти во всех линуксах
Минусы:
— работает только на линуксовых файловых системах (fsck не понимает ключ -l)
— если битых секторов слишком много, проще выкинуть винчестер e2fsck начинает писать, что сектор находится «вне диапазона» и не метит его.

Внимание! Никогда, слышите, никогда так не делайте! Начав сыпаться, жесткий диск может крякнуть в любой момент, проще (и дешевле, если у вас на харде что-то кроме котофото из интернетов) купить новый хард. Меня заставили под пытками. Мне пришлось, т.к. HDD был от древнего квадраттера, работающего на линухе, и HDD требовался IDE-шный, который сейчас хрен найдешь (да, для работы я не делюсь своими IDE HDD, я жадный).

Так вот, если битые сектора кучкуются в начале или в конце жесткого диска, то возможно, глюк оттуда не расползется, так что часть с битыми секторами можно просто отрезать и пометить в gparted как unformatted

Но никогда так не делайте. Я предупреждал.

Довольно частой задачей является узнать, встречается ли в строке какое-нибудь слово или же, в более общем случае, подстрока.
Для решения можно воспользоваться внутренними механизмами bash, но я покажу более башенезависимый способ, с помощью grep. Благо он есть практически везде, даже в каких-нибудь системах, основанных на BusyBox, а вот вместо bash может встретится и просто sh, и что-нибудь более экзотическое.

Предположим, что в переменной STR имеется строка:

STR="cat lynx lion coguar"

В переменную SUBSTR запишем первый параметр командной строки скрипта ($1):

SUBSTR="$1"

Выводим содержимое переменной $STR, передаем вывод grep с нужными параметрами, а результат сохраняем в переменную-счетчик:

CNTR=`echo "$STR" | grep -w -c "$SUBSTR"`

В данной команде более всего интересны параметры grep:

-w — искать целое слово.

Примечание: Словом по умолчанию считается все, что отделено от других символов пробелом(-ами) табуляцией(-ами) или переводом(-ами) строки.

-с — подсчитать количество строк с нужным вхождением

Примечание: Ключ -с заставляет grep подсчитывать строки, а не сами вхождения, так что количество вхождений слова в строку, так посчитать не получится.

В итоге в переменной CNTR оказывается 0, если совпадений нет, и 1, если совпадение есть, остается только проверить:

if [ "$CNTR" -ne 0 ];then
    echo "Exist"
else
    echo "Not exist"
fi

Демо-скрипт на GitHub

Примеры работы:

./exist-word lion

Вывод:
Exist

./exist-word dog
./exist-word li

Вывод:

Not exist

Под подстрокой имеется любой набор символов, идущих подряд.

Задача решается аналогично предыдущей, только из параметров grep удаляется ключ -w

Если из вышеуказанного скрипта удалить ключ -w grep‘а, то вывод будет таким:

./exist-word li

Вывод:

Exist

Т.е. теперь была найдена подстрока li (часть слова lion).

Хотел, конечно, назвать как-нибудь типа «гадское поведение wget» или «уничтожение файлов wget‘ом», но остановился на этом. Добавлю ссылку в пост о кодах ошибок (копия) на этот пост.

Но на самом деле, это вроде маленькая и многим известная штука, но которой мало кто задумывается. Особенно, если использует wget в своих скриптах. Отдельно отметить это меня сподвиг тот самый скрипт, с которого я начал сегодняшний разговор о wget (копия)

Оказывается, wget создает новый файл перед закачкой. Несмотря на то, появятся там какие-то ошибки или нет, и несмотря на то, какие ошибки это будут, хоть это ошибки сервера (например 404, файл не найден), или ошибки сети (файл не удалось докачать), файл все равно будет создан. Хотя по логике, например, ошибку сервера (пусть 404) можно было бы сначала и проверить. Но wget этого не делает, если не случилась ошибка с кодом 2 (ошибка параметров командной строки или конфигурационных файлов).

На самом деле, такой подход довольно правильный, ну и правда, какая разница, почему оно не скачалось (или не сохранилось на диск в случае I/O error). И для анализа ошибок проблем меньше.

Наибольшую проблему это представляет собой тогда, когда пользователь указывает в параметрах wget ключ -O <путь к файлу>, тогда wget придется его полюбому перезаписать.

Так-то у wget есть «защита от дурака», если файл, например, file уже существует, то при следующей закачке файл file (под тем же именем) будет сохранен, как file.1, и если что, старый файл останется в целости и сохранности. Но в скриптах ключ -O удобно использовать. Не надо следить за этими номерами файлов, и вообще в скрипте, wget без ключей, один сплошной геморрой. Так что ключи используют. Но как же правильно это сделать? Да выбирать место сохранения скачанного и проверять коды ошибок wget!

1. Скачиваем файл во временный:
wget -O "/tmp/test.tmp" "http://example.org/test.dat"
2. Проверяем коды ошибок (здесь самый простой вариант)

if [ "$?" -eq 0 ]; then
	#Пункт 3
fi

3. Копируем скачанный файл в целевой: cp /tmp/test.tmp /home/pi/test.dat

Естественно, все имена файлов и пути меняем на свои.

1. Скачиваем файл:
wget -O "~.data/test.dat" "http://example.org/test.dat"

2. Проверяем коды ошибок (здесь самый простой вариант). Если ошибка — завершаем работу:

if [ "$?" -ne 0 ]; then
	rm "~.data/test.dat"
	echo "Data download error!"
	exit
fi

Заметка от склероза. Способ ниже удаляет закомментированные, а заодно и пустые строки из файла, но не трогает комментарии в строках. Хорошо помогает почистить какой-нибудь конфиг, в котором комментариев больше, чем самих параметров, и хрен че найдешь:

grep -o '^[^#]*' file.txt > cleaned.txt

Вместо file.txt подставляем исходный файл, вместо cleaned.txt — выходной.

Нашел здесь Копия в PDF

Там есть и другие варианты решения задачи.

Как однажды сказал мой учитель, «линукс может все, а многое еще и из коробки, надо только знать как». Вот в данном случае именно так и оказалось. Понадобилось мне массово перекодировать файлы в/из BASE64.

BASE64 это такой древний формат данных, использующийся для передачи двоичных данных по сети. В век всеобщего юникода и кучи всякого софта это не так видно пользователю, но когда все только начиналось, с передачей данных была большая жопа. Даже на «железном» уровне некоторые машины поддерживали только семибитную кодировку, а уж о софте, не поддерживающем ничего кроме великого и могучего английского языка и говорить не приходится. Т.е. любой символ кроме букв английского алфавита и цифр мог быть либо выкинут к чертям собачьим, либо невозбранно использован как служебный. Соответственно, любой бинарный файл мог каким либо софтом, например, хитровыебанным почтовым сервером, разорван в клочья при передаче из пункта А в пункт Б.

Вот и придумали умные люди, а давайте все, что не влазит в английский алфавит и цифры, будем по хитрому алгоритму заменять, таки да. На английский алфавит и цифры. Так и получился BASE64. Подобная хрень в криптографии называется «транспортная броня».

Так вот, в Linux из коробки (входит в пакет Coreutils, который есть почти везде) есть утилита, способная кодировать/декодировать BASE64. Называется она, внезапно, base64.

Для опытов возьмем восьмибитного Сиро Исии. Он, когда живой был, много кого брал на опыты.

base64 isia.png >isia.b64

Закодированный Сиро Исии на Pastebin

base64 -d isia.b64 >isia.decoded.png

Тот случай, когда суть получилась короче преамбулы.