Я собираюсь предположить, что "многие люди" в вопросе относятся к людям, пишущим учебники, руководства или ответы на -веб-сайтах, таких как этот.
При написании команд терминала в текстовом документе команда cat
обычно используется для отображения содержимого файла.
Пример этого:
$ cat script.sh
#!/bin/sh
echo 'hello'
$ chmod +x script.sh
$./script.sh
hello
Здесь я показываю, что у меня есть файл с именем script.sh
, каково его содержимое, что я делаю его исполняемым, запускаю его и каков результат этого.
Использование cat
в этом примере является просто способом «показать все свои карты», т.е. явно отобразить все предпосылки для примера (и сделать это как часть текстового представления терминальной сессии ). ].
less
и другие экранные пейджеры, в зависимости от того, как они используются, не обязательно будут давать такой вывод в терминале. Итак, если бы я написал
$ less script.sh
#!/bin/sh
echo 'hello'
и пользователь попробовал это самостоятельно, они могут задаться вопросом, почему текст скрипта выглядит иначе в их терминале, а затем исчезает из терминала после закрытия less
пейджера (, если они так настроили пейджер ), или их less
отличается от less
, используемого в ответе (, или учебнике, или чем-то еще ), или они делают что-то еще неправильно. Допущение возможности такого хода мыслей контрпродуктивно и разрушительно для пользователя.
Использование cat
при отображении примера в терминале в виде текста хорошо, поскольку дает довольно простой способ воспроизведения точных тех же результатов, что и в данном тексте. Для больших файлов может быть лучше показать файл отдельно, а затем сосредоточиться на том, как этот файл используется при написании команды терминала в виде текста.
Если вы предпочитаете использовать less
, more
, most
, view
, sublime
или какой-либо другой пейджер или программу для просмотра файлов, это совершенно нормально. Иди и сделай это. Но если вы хотите предоставить воспроизводимый текст, описывающий какой-либо рабочий процесс в терминале, вам также придется предупредить пользователя о том, что вывод может отличаться между тем, что он читает, и тем, что он видит в своем собственном терминале, в зависимости от того, какой пейджер используется. и как он настроен.
Наконец-то я нашел решение. Кажется, это как-то связано с обновлением до bridge-utils
или, может быть, с ядром (, к сожалению, я не могу определить его конкретную версию/обновление ).
Поведение до заключалось в том, что мост автоматически использует MAC-адрес из интерфейса, поведение после обновления заключалось в том, что мост назначает случайно сгенерированный MAC-адрес (, который был заблокирован на стороне сети ).
После установки MAC-адреса моста(ip link set xenbr0 address 44:8a:5b:29:e6:40
)доступ к сети снова работает, как ожидалось.