Вопросы Теги

В какой поток xsel печатает предупреждение об отсутствии новой строки?

Прежде всего создайте файл для проверки задания Cron: 

 $touch echo.sh

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

Установить разрешение: 

$ chmod +x /path/to/file/echo.sh

Пример задания Cron: 

 crontab -e

* * * * * /path/to/file/echo.sh

Сохранить запись.

Вы также можете проверить вывод для cron: 

grep CRON /var/log/syslog

OR 

tail -f /var/log/syslog | grep CRON
6
13.01.2017, 18:50
2 ответа

Обратите внимание, что это поведение xsel в еще не выпущенных версиях xsel . Внесено это изменение в 2008 году.

Обычно выделение X содержит текст, не оканчивающийся символами новой строки. Если вы сбросите его как есть, это приведет к отображению незавершенной строки. В старых оболочках, таких как bash , на дисплее отображается: 

bash-4.4$ xsel -b
xselbash-4.4$

(здесь при выборе CLIPBOARD, содержащем xsel ). Следующая подсказка добавляется к содержимому выделения.

Современные оболочки, такие как zsh или fish , работают над этим, обнаруживая, когда результат последней команды не заканчивается символом новой строки, и затем дают вам визуальную индикацию.

С zsh : 

prompt% xsel -p
xsel%
prompt%

(обратное видео % после xsel указывает на отсутствие новой строки).

С рыбой : 

prompt ~> xsel -p
x⏎
prompt ~>

Эти новые xsel сами дают вам визуальную индикацию: 

bash-4.4$ xsel -b
xsel
\ No newline at end of selection
bash-4.4$

Теперь это полезно, только если xsel запускается по запросу старого интерактивная оболочка.

В частности, указание «Нет новой строки» нежелательно при использовании как: 

selection=$(xsel -b)

(где stdout xsel - канал) или: 

xsel -b > selection.txt

(где xsel Стандартный файл - это обычный файл).

Вот почему xsel выводит эту индикацию только тогда, когда stdout идет на tty-устройство.

Итак, где это отображается? Ну, намерение состоит в том, чтобы отобразить его на этом устройстве tty. Если вы запустите его под strace, вы увидите: 

$ strace -e write ./xsel -b
write(1, "xsel", 4xsel)                     = 4
write(2, "\n\\ No newline at end of selectio"..., 34
\ No newline at end of selection
) = 34
+++ exited with 0 +++

Что подтверждает источник : он выводится на stderr. И когда stdout не является терминалом: 

$ strace -e write ./xsel -b  > /dev/null
write(1, "$ strace -e write ./xsel -b | ca"..., 104) = 104
+++ exited with 0 +++

Он вообще не выводится. Теперь можно утверждать, что выводить на stderr немного глупо, когда намерение состоит в том, чтобы вывести это уведомление на терминал (stderr может быть перенаправлен, например, в файл журнала, как в xsel -b 2> logfile ), но:

  • Обычно, когда stdout является оконечным устройством, stderr тоже.
  • Это означает, что вы можете отключить это уведомление при запуске в терминале с помощью xsel -b 2> / dev / null , что будет более эффективно, чем xsel -b | кот .
  • isatty () вернет истину для последовательного устройства, которое не подключено к терминалу.
5
27.01.2020, 20:28

Достаточно просто проверить с помощью: 

xsel -b > xsel.out 2> xsel.err

Сообщение будет в одном из двух файлов. Если он находится в xsel.out , то сообщение проходит через стандартный вывод; если он находится в другом файле, то это стандартная ошибка; если он в другом, то происходит что-то очень странное, и вам нужно долго и серьезно поговорить с вашим ядром.

1
27.01.2020, 20:28

Теги

Похожие вопросы