Як я міг запам'ятати, як використовувати перенаправлення?

Я знаю що

  program > /dev/null 2>&1 

робить. Він перенаправляє висновок на /dev/nullі 2>&1означає перенаправляти вихід помилки там же, куди надсилається вихід.

Моя проблема полягає в тому, що я завжди мушу його гуляти, тому що я його ніколи не пам'ятаю.

Отже, я намагаюся &2>1, 1>2&, 1>&2... Я намагаюся кожну комбінацію , поки я не Google це ...

Яка хитрість легко запам'ятати його?

Вихід кращий, ніж помилка, тому він стає першим (1 проти 2).

>є скороченням для "іде до". Зліва - те, що я хочу надіслати, а праворуч - це те, куди я хочу його надіслати. Оскільки "де" - це (майже) завжди файл, щось подібне

program > /dev/null 2>1

буде перенаправляти на файл з ім'ям 1. Таким чином, ampersand (&)змінює файл на дескриптор файлу.

На жаль, я не натрапив і не розробив власну мнемоніку, але коли я вперше вчився * nix, я знайшов цей логічний спосіб добре працювати. Після декількох пробігів це стає другою природою.

Один фокус - просто пам’ятати, що 1 = стандартний вихід, 2 = стандартна помилка. Тому:

2>&1= стандартний потік помилок переходить у стандартний вихідний потік.
1>&2= навпаки.

Якщо ви коли-небудь програмували мовою, подібною до С, легко запам'ятати ampersand ( &). Я вирішу вважати це посиланням на "адресу" існуючого дескриптора файлу, щоб ви не змінювали сам файл або не створювали новий.

Бачити &як вузол може допомогти: подумайте, що ви хочете зробити, як взяти вихід 2, так 2>, і зв’язавши його разом з 1, так2>&1

Насправді це залежить від того, яку оболонку ви використовуєте. Bash, як правило, дуже прощає, і ви можете просто зробити:

program &> file

Розглянемо ці три варіанти:

program  2>1
program  2>1& 
program  2>&1

Перший надсилає stderr до імен файлів "1": зрештою, bash розраховує перенаправити на файл.

Другий також переспрямовує на той самий файл, але працює programу фоновому режимі: саме так &має означати трейлінг .

Це залишає третю можливість як єдину, яка має сенс у Всесвіті bash для переадресації до файлової ручки.

Як запам'ятати, що є серед 0, 1, 2? Подумайте про запуск комп'ютера з консолі. Спочатку потрібно щось набрати (0 = stdin). Потім ви бачите вихід (1 = stdout). Нарешті, і лише якщо щось піде не так, ви бачите stderr (2).

Намалюйте його на шпалерах.

Тепер, серйозно, цей та інші основні речі я забував, тому я додав меню швидких порад у додаток, який я розробив і яким користуюся щодня. Ви можете спробувати або скористатися чимось на зразок гноти, щоб зберегти нотатку.

Що стосується панцирної оболонки, я вважаю, що найкращий спосіб запам'ятати це розуміння того, що відбувається.
Якщо все, що ви хочете зробити, це пам'ятати, як правильно виправити команду, ви можете спробувати

program > /results 2> /results

Це приємно і очевидно, що відбувається, і легко запам'ятовується. тобто

• 1 STDOUT збирається /results
• 2STDERR також збирається безпосередньо в/results

проблема полягає в тому, що це не працює так, як ви очікували. врахуйте наступне:

файл: /tmp/poem.txt

the quick brown fox jumped over the lazy dog

і запустіть команду

grep "brown" /tmp/poem.txt NOT_A_FILE > /tmp/results 2> /tmp/results

тоді

$ cat /tmp/results
grep: NOT_A_FILE: No such file or directory
 lazy dog

що тут сталося?
Моє розуміння - це bash налаштування перенаправлення, що вказує STDERR безпосередньо на файл /tmp/resultsі через природу >якого робить 2 речі

1. як правило, створити новий файл - у цьому випадку можливість минула, коли bash пройшов повз цю процедуру під час отримання результату.
2. вставити прямо на початок файлу. і не додавати, як >>це робиться.

Тож у цьому випадку STDERR вставляє безпосередньо на початок /tmp/resultsпереопределення виводу STDOUT.
Примітка: якщо ви >>додавали додавання, ви, ймовірно, могли піти з цього синтаксису.
Однак для усунення необхідної проблеми - не перенаправляти STDERR - у файл безпосередньо, а скоріше об'єднати висновок STDERR у потік STDOUT, щоб у вас не виникло зіткнення.
Використання оператора 2>&1оператора цього досягає

grep "brown" poem.txt NOT_A_FILE > /tmp/results 2>&1

&Дозволяє Баш відрізнити від файлу з ім'ям 1і 1дескриптор файлу.
Для мене саме твердження 2>&1пояснює, що саме відбувається - STDERR переспрямовується на STDOUT сам - і закінчується лише /tmp/resultsтому, що саме там вказано STDOUT (майже як побічний ефект).
На відміну від того, що претендує багато довідників, а саме те, що 2>&1посилає STDERR туди, де колись вказано STDOUT. Якби це було правдою - у вас все одно виникне проблема перезапису.

Для отримання додаткової інформації дивіться - http://mywiki.wooledge.org/BashGuide/InputAndOutput#File_Redirection