VPF::Привязка потоков в bash для стартуемого процесса

ToshaCh

Дата 1.7.2010, 11:54 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 555
Регистрация: 10.11.2005
Где: Москва, РФ

Репутация: нет
Всего: 26

Столкнулся с одной особенностью работы bash (врочем, думаю, что не только bash), которая вызвает у меня лютое непонимание.

Для начала пример.

Код


$ chmod -x w.sh
$ ./w.sh
bash: ./w.sh: Permission denied
$ ./w.sh 2>/dev/null
$

Собственно, спрашивается, куда делось сообщение "bash: ./w.sh: Permission denied", во втором случае. Не спешите отвечать: "Балбес, да ты же его сам в /dev/null". Это сообщение, по логике вещей генерится bash сессией в которой я нахожусь, а поток я хочу перенаправить для запускаемого w.sh.

bash получает команду: запустить исполняемый файл x и перенаправить его поток ошибок в y
bash привязывает дескриптор потока ошибок к объекту y
bash запускает объект x, дескриптор указывающий на y наследуется.
bash восстанавливает (sic!) дескриптор потока ошибок

bash получает команду: запустить исполняемый файл x и перенаправить его поток ошибок в y
bash запускает объект x, привязывая дескриптор потока ошибок процесса x` к объекту y

Т.е. в общем я хочу, чтобы ошибки типа "bash: ./w.sh: Permission denied" выдавались на экран, а внутренние ошибки w.sh уходили в лог (без переписывания w.sh).

--------------------

Slackware 12.2 | Linux 2.6.27 | Fluxbox 1.1.1 | Wmii 3 | Opera 9.63
--
Oracle это не только способ отмывания денег, но и вполне себе преличная база данных.

ToshaCh

Дата 1.7.2010, 13:34 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 555
Регистрация: 10.11.2005
Где: Москва, РФ

Репутация: нет
Всего: 26

Дальнейшее чтение священных мануалов наталкивает меня на мысль, что дело не в bash, а в posix реализации fork, которая не даёт возможности переписывать дескрипторы, а жаль.

--------------------

mihanik

Дата 1.7.2010, 14:51 (ссылка)

(нет голосов)

Загрузка ...

-=Белый Медведь=-

Профиль
Группа: Комодератор
Сообщений: 4054
Регистрация: 24.4.2006
Где: г. Тверь

Репутация: 13
Всего: 109

Цитата

Перенаправление ввода/вывода, каналы и фильтры

Хотя обычно, как было сказано, ввод/вывод программы связаны со стандартными потоками, в оболочке существуют специальные средства для перенаправления ввода/вывода.
Операторы >, < и >>

Для обозначения перенаправления используются символы ">", "<" и ">>". Чаще всего используется перенаправление вывода команды в файл. Вот соответствующий пример:

[user]$ ls -l > /home/jim/dir.txt

По этой команде в файле /home/jim/dir.txt будет сохранен перечень файлов и подкаталогов того каталога, который был текущим на момент выполнения команды ls; при этом если указанного файла не существовало, то он будет создан; если он существовал, то будет перезаписан; если же вы хотите, чтобы вывод команды был дописан в конец существующего файла, то надо вместо символа > использовать >>. При этом наличие пробелов до или после символов > или >> несущественно и служит только для удобства пользователя.

Вы можете направить вывод не только в файл, но и на вход другой команды или на устройство (например, принтер). Так, для подсчета числа слов в файле /home/jim/report.txt можно использовать следующую команду:

[user]$ cat /home/jim/report.txt > wc -w

а для вывода файла на печать - команду:

[user]$ cat /home/jim/report.txt > lpr

Как видите, оператор > служит для перенаправления выходного потока. По отношению к входному потоку аналогичную функцию выполняет оператор <. Приведенный выше пример команды для подсчета числа слов в определенном файле можно переписать следующим образом (обратите внимание на отсутствие команды cat):

[user]$ wc -w < /home/jim/report.txt

Этот вариант перенаправления часто используется в различных скриптах, применительно к тем командам, которые обычно воспринимают ввод (или ожидают ввода) с клавиатуры. В скрипте же, автоматизирующем какие-то рутинные операции, можно дать команде необходимую информацию из файла, в который заранее записано то, что нужно ввести для выполнения этой команды.

В силу того, что символы <, > и >> действуют на стандартные потоки, их можно использовать не только тем привычным образом, как это делается обычно, но и несколько по-другому. Так, следующие команды эквивалентны:

[user]$ cat > file
[user]$ cat>file
[user]$ >file cat
[user]$ > file cat

Однако сам по себе (без какой-либо команды, для которой определены стандартные потоки) символ перенаправления не может использоваться, так что нельзя, например, введя в командной строке

[user]$ file1 > file2

получить копию какого-то файла. Но это не уменьшает значения данного механизма, ведь стандартные потоки определены для любой команды. При этом перенаправить можно не только стандартный ввод и вывод, но и другие потоки. Для этого надо указать перед символом перенаправления номер перенаправляемого потока. Стандартный ввод stdin имеет номер 0, стандартный вывод stdout - номер 1, стандартный поток сообщений об ошибках stderr - номер 2. То есть полный формат команды перенаправления имеет вид (напомним, что пробелы возле > не обязательны):

command N > M

где N и M - номера стандартных потоков (0,1,2) или имена файлов. Употребление в некоторых случаях символов <, > и >> без указания номера канала или имени файла возможно только потому, что вместо отсутствующего номера по умолчанию подставляется 1, т. е. стандартный вывод. Так, оператор > без указания номера интерпретируется как 1 >.

Кроме простого перенаправления стандартных потоков существует еще возможность не просто перенаправить поток в тот или иной канал, а сделать копию содержимого стандартного потока. Для этого служит специальный символ &, который ставится перед номером канала, на который перенаправляется поток:

command N > &M

Такая команда означает, что выход канала с номером N направляется как на стандартный вывод, так и дублируется в канал с номером M. Например, для того, чтобы сообщения об ошибках дублировались на стандартный вывод, надо дать команду 2>&1, в то время как 1>&2 дублирует stdout в stderr. Такая возможность особенно полезна при перенаправлении вывода в файл, так как мы тогда одновременно и видим сообщения на экране, и сохраняем их в файле.

--------------------

Программистами не рождаются, - это родовая травма...

ToshaCh

Дата 1.7.2010, 15:22 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 555
Регистрация: 10.11.2005
Где: Москва, РФ

Репутация: нет
Всего: 26

mihanik, cпасибо, конечно, за титаническую работу c ctrl-c, ctrl-v - но что-то ответа я на вопрос не увидел.

Это сообщение отредактировал(а) ToshaCh - 1.7.2010, 15:23

--------------------

Mephisto

Дата 1.7.2010, 18:22 (ссылка)

(нет голосов)

Загрузка ...

Волкъ

Профиль
Группа: Завсегдатай
Сообщений: 1818
Регистрация: 27.8.2003
Где: Питер

Репутация: нет
Всего: 34

Цитата(ToshaCh @ 1.7.2010, 12:54

)

пиши первое в cout, второе в cerr. Если первое и второе пишется в cerr, то как разделить их тогда?

bilbobagginz

Дата 2.7.2010, 08:28 (ссылка)

(голосов:1)

Загрузка ...

Naughtius Maximus

Профиль
Группа: Экс. модератор
Сообщений: 8813
Регистрация: 2.3.2004
Где: Israel

Репутация: 113
Всего: 317

Цитата(ToshaCh @ 1.7.2010, 10:54

)

дело в том, что "bash: ./w.sh: Permission denied"
пишется программой bash.
проблема не только в реализации форки.
проблема в том, что пишет тот, кто жив.
незапустившийся процесс из w.sh не запускаем, поэтому bash воспринимает это как инструкцию перенаправления СВОЕГО stderr в /dev/null

а для достижения своей цели тебе нужно обернуть твой запуск тестом:

Код


TRG=./w.sh
if [ ! -x ${TRG} ]; then
  echo "ERROR: ${TRG} is not executable!"
  exit ${NON_EXEC_ERROR}
fi

${TRG} 2> ${TRG}.err

Это сообщение отредактировал(а) bilbobagginz - 2.7.2010, 08:31

--------------------

Я ещё не демон. Я только учусь.

ToshaCh

Дата 5.7.2010, 10:46 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 555
Регистрация: 10.11.2005
Где: Москва, РФ

Репутация: нет
Всего: 26

Цитата(bilbobagginz @ 2.7.2010, 08:28

)

незапустившийся процесс из w.sh не запускаем, поэтому bash воспринимает это как инструкцию перенаправления СВОЕГО stderr в /dev/null

Едрит его так. Только мне это кажется глупым?

Цитата(bilbobagginz @ 2.7.2010, 08:28

)

а для достижения своей цели тебе нужно обернуть твой запуск тестом:

Это не очень хороший вариант. Все ведь не предусмотреть. Да и опять таки это глупо выглядит.

--------------------

Mephisto

Дата 5.7.2010, 15:48 (ссылка)

(голосов:1)

Загрузка ...

Волкъ

Профиль
Группа: Завсегдатай
Сообщений: 1818
Регистрация: 27.8.2003
Где: Питер

Репутация: нет
Всего: 34

ToshaCh, т.е. ты считаешь что если некий скрипт не может запустить программу, то залогировать это должна сама программа, а не считать это ошибкой в скрипте?

bilbobagginz

Дата 5.7.2010, 20:08 (ссылка)

(нет голосов)

Загрузка ...

Naughtius Maximus

Профиль
Группа: Экс. модератор
Сообщений: 8813
Регистрация: 2.3.2004
Где: Israel

Репутация: 113
Всего: 317

Цитата(ToshaCh @ 5.7.2010, 09:46

)

Это не очень хороший вариант. Все ведь не предусмотреть. Да и опять таки это глупо выглядит.

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

--------------------

Я ещё не демон. Я только учусь.

ToshaCh

Дата 12.7.2010, 14:04 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 555
Регистрация: 10.11.2005
Где: Москва, РФ

Репутация: нет
Всего: 26

Цитата(Mephisto @ 5.7.2010, 15:48

)

ToshaCh, т.е. ты считаешь что если некий скрипт не может запустить программу, то залогировать это должна сама программа, а не считать это ошибкой в скрипте?

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

Цитата(bilbobagginz @ 5.7.2010, 20:08

)

Шутку понял, смешно.

--------------------

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| *NIX системы: Общие вопросы \| Следующая тема »