Сценарий, которые продолжают читать поток

Я использовал jwm долгое время на моем старом Ноутбуке на 199 МГц только с 32 МБ RAM.

Работавший вполне хорошо и выглядел довольно хорошим. Конфигурация также приятно реализована с XML-файлом.

7
05.03.2011, 04:16
2 ответа

Из сценария оболочки Вы будете ограничены для завершения строк. Необходимо будет использовать C/Perl/Python/whatever для более прекрасного гранулярного чтения.

while read line; do
  # do something based on content of $line; remember to quote it
done </dev/input/event0
5
27.01.2020, 20:17
  • 1
    Много поддержки оболочек, читая меньше, чем строка, это просто не стандартно. ksh может читать (например). пять байтов с read -N5, удар может читать пять (возможно многобайтовый) символы с read -rN5, zsh может читать 5 (возможно многобайтовый) символы с read -u0 -k5. Оба удара и zsh могут считать байты вместо символов при помощи локали C (или вероятно любого 8-разрядного символа ctype). –  Chris Johnsen 05.03.2011, 07:02
  • 2
    @Chris Рассматривает описывание ответа! –  Steven D 05.03.2011, 07:13
  • 3
    По-видимому, read -N является новым в ударе 4.2, таким образом, это не может быть везде. Кроме того, удар LC_CTYPE=C IFS= read -rN 1 кажется, ест определенные байты (0x00, 0xff). ksh, кажется, ест, 0x00 (вероятно, из-за использования NUL завершил строки внутренне). zsh, кажется, работает правильно все же. –  Chris Johnsen 05.03.2011, 07:30

Вариация на ответ geekosaur:
Вы могли бы хотеть попробовать read -n 1 byte для чтения одного байта за один раз затем сделайте что-то с $byte.

Править:

Просто попробованный это, поскольку я никогда не использовал ту команду прежде (просто искавший info bash), но это, кажется, громко жует весь пробел и окончания строки. У меня еще нет объяснения этого.

Попробуйте следующие сценарии для точной настройки аргументов команды:

(for j in $(seq 1 10); do for i in $(seq 1 100); do echo -n "$i, "; sleep .02; done; echo "& $j."; done) | (while read line; do echo $line; done)

(for j in $(seq 1 10); do for i in $(seq 1 100); do echo -n "$i, "; sleep .05; done; echo "& $j."; done) | (while read -n 1 byte; do echo -n "$byte"; done)

Таким образом, к сожалению, это не дает ожидаемый результат.

РЕДАКТИРОВАНИЕ (со справкой Chris):

(for j in $(seq 1 10); do for i in $(seq 1 100); do echo -n "$i, "; sleep .02; done; echo "& $j."; done) | (while IFS= read -N 1 byte; do echo -n "$byte"; done)

Это дает точно ожидаемый результат.
Примечание: использую ли я -n, -N, или -rN не изменяет результат, именно вся польза (с текстом, я не протестировал ограничение, Chris говорит о: 0x00 и 0xff).

4
27.01.2020, 20:17
  • 1
    Это, которым состоит в том "жевание", почему я сказал, "не забывает заключать его в кавычки"; если Вы говорите echo $foo, $foo получит весь пробел (все символы в $IFS, быть педантичным) уплотненный к одиночным пробелам, тогда как echo "$foo" сохранит их. Но необходимо использовать его последовательно, чтобы удостовериться, что пробел всегда заключается в кавычки. –  geekosaur 05.03.2011, 07:15
  • 2
    @geekosaur, это не проблема заключения в кавычки, это - вследствие того, что удар, кажется, игнорирует членов IFS в read -nread -N в 4,2). Обходное решение должно использовать IFS= read -rn 1 (даже затем удар все еще ест 0x00 и 0xff). –  Chris Johnsen 05.03.2011, 07:37
  • 3
    Это было бы то, почему я не использую bash; это всегда, кажется, имеет глупые ошибки как этот. (Мой "фаворит" bash ошибка была в некоторых 2.x версия, где обратные косые черты в случае, если шаблоны не остановились * от того, чтобы быть соответствием шарика.) –  geekosaur 05.03.2011, 07:40

Теги

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