Автоматизация текстового входа из сценария удара, не используя EOF
Я думаю, что зафиксировал его. Я заметил при редактировании /etc/fstab в энергии, что одна из строк была красной. Я не очень знаком с энергией, но я думаю, что она указывала на некоторую ошибку, таким образом, я переписал строку:
Теперь, когда я загружаюсь, это работает:
Почти для всех программ, обоих echo $i | myprogram -options и myprogram -options <<<$i должен работать, путем питания программы $i через стандартный вход.
<foo будет использовать содержание названного файла foo как stdin.
<<foo будет использовать текст между этим и строкой, состоящей только из foo как стандартный вход. Это здесь документ (heredoc), как сказал Gilles; EOF на самом деле не означает конец файла, это - просто общий heredoc проектировщик (мы используем "нечто" вместо этого в этом примере).
<<<foo будет использовать строку "нечто" в качестве стандартного входа. Можно также указать переменную $foo, и оболочка будет использовать свое содержание в качестве stdin, когда я показал выше. Это называют herestring, поскольку он использует короткую строку в отличие от целого блока, как в heredoc. Работа Herestrings в ударе, но не в /bin/sh.
Синтаксис, рекомендуемый этим веб-сайтом, называют здесь документ. Вход к программе файла сразу запускается ниже строки, содержащей <<EOF, и это не завершается к концу сценария, но строкой, содержащей точно текст EOF (заботьтесь, чтобы не иметь дополнительный пробел). Между прочим, можно использовать любой маркер конца, который не содержит специального символа оболочки: EOF не ключевое слово, это просто традиционно.
#!/bin/bash
for i in {1..100}
do
myprogram -options <<EOF
$i
EOF
for j in {1..42}; do
myprogram2 <<EOF
$i
$j
EOF
done
done
-
1, другими словами, EOF в этом контексте означает маркер конца файла, не фактический конец файла сценария. текст "EOF" является любым произвольным текстом - независимо от того, что Вы сразу используете после <<символы укажут на конец здесь теперь документ. Я обычно использую EOF, потому что он выделяется и очень вряд ли будет в herenow документе, если, например, я programatically-генерирую сценарий оболочки (который я делаю довольно часто). – cas 08.07.2012, 16:24
-
2, которым должен быть полужирный EOF <подчеркивает> <подчеркивают> EOF <подчеркивание> <подчеркивание> – cas 08.07.2012, 16:53
-
3Используя здесь-документы как это, я часто изменял конечный маркер на что-то намного более значимое (и менее вероятно быть "случайным образом" согласованным), как
END_OF_WHATEVER_FUNCTION. Иногда, попытка "оставить" свободное место является на самом деле тратой усилия, потому что это вызывает неоднозначность относительно того, что на самом деле происходит. – killermist 08.07.2012, 19:51 -
4
-
5@unexpected62 я не понимаю то, что Вы спрашиваете. Необходимо, вероятно, задать новый вопрос на этом сайте. Обязательно дайте достаточно контекста. – Gilles 'SO- stop being evil' 08.03.2014, 03:11
здесь документы, как упомянуто и Kevin и Gilles выше, или простая передача по каналу будут работать во многих случаях.
Для более сложных ситуаций можно хотеть изучить, Ожидают или подобный (например, Ожидание:: Простой модуль CPAN является очень простой в использовании реализацией жемчуга). лично, я предпочитаю модуль жемчуга (Ожидайте себя, tcl), но существуют реализации для многих общих языков сценариев. Даже возможно записать очень примитивную реализацию идеи в sh или использовании удара, в то время как и читают.
Общее представление об Ожидает, и подобные инструменты должен ожидать указанной строки или шаблона в выводе программы, и затем подать его, независимо от того, что введено, Вы хотите.
Использование типичного примера должно автоматизировать вход в систему путем "ожидания" (т.е. ожидания) строка "ogin": отправьте имя для входа в систему, затем ожидайте строку "слово": и отправьте пароль.
Одна заключительная опция, если у Вас есть источник myprogram, состоит в том, чтобы просто изменить его для взятия входа, который Вы хотите дать ему как параметр командной строки. Это могло бы быть немного большим количеством работы заранее, но будет намного менее ухудшать, чем бездельничание с Ожидает или данные передачи по каналу в программу, которая не была разработана, чтобы использоваться тот путь.
... и не забывайте отправлять свой патч к myprogram назад в восходящем направлении :) Даже если им не нравится способ, которым Вы кодировали его, им могло бы понравиться, когда идея достаточно добавила опцию самим. Восходящий поток devs имеет тенденцию ценить людей, которые выходят из их торцов и вносят, а не требуют или жалуются.