Я нашел странное и совершенно неожиданное поведение при работе с перенаправлением в bash, и даже если мне удастся обойти его, я хотел бы знать, почему это происходит.Неожиданное поведение в переназначении bash
Если я запустил эту команду: { echo wtf > /dev/stdout ; } >> wtf.txt
N раз, я ожидаю увидеть заполненные строки N "wtf". То, что я нашел в файле, - это одна строка.
Я думаю, что поскольку первая команда открывает/dev/stdout в режиме усечения, тогда режим наследуется вторым файловым дескриптором (wtf.txt), который затем полностью удаляется, но я хотел бы знать если некоторые из вас могут объяснить это лучше, и если это правильное поведение или ошибка.
Просто, чтобы быть ясным, команда, которую я использовал, была другой, но пример echo проще понять. Первоначальная команда была командой, которой нужен выходной файл в качестве аргумента, и поскольку я хочу, чтобы вывод на stdout прошел в качестве аргумента /dev/stdout. Такое же поведение можно проверить с помощью команды openssl rand -hex 4 -out /dev/stdout >> wtf.txt
.
Наконец, решение мне удалось решить проблему делегирования операции добавления к тройнику следующим образом: { echo wtf > /dev/stdout } | tee -a wtf.txt > /dev/null
Это происходит потому, что сначала выполняется перенаправление '>> wtf.txt', а затем, когда обрабатывается'>/dev/stdout', вы больше не добавляете в stdout из-за '>' вместо '> > '. Итак, он работает: '{echo wtf >>/dev/stdout; } >> wtf.txt' – whoan
Думайте, что вы делаете что-то вроде: 'echo wtf >> wtf.txt> wtf.txt'. С '>> wtf.txt' вы указали'/dev/stdout' * * на 'wtf.txt'. Затем, используя '>/dev/stdout', вы заменяете предыдущее перенаправление. '/ dev/stdout', на данный момент, является символической ссылкой на' wtf.txt'. – whoan
Невозможно воспроизвести либо в bash 3.2, либо в bash 4.3, либо выполнив каждую из N команд вручную или быстро в цикле. – chepner