exepect vs. аналоги (отрезано от "запуска пароленных программ")

[drBatty]

Кстати, эта expect - чрезвычайно простая вещь мне достаточно было всего минут 15 на её освоение (ну конечно на примитивном уровне, так, на сервер по SSH зайти, и там команды по выполнять)
Есть и мануал по-русски с примерами: http://www.ibm.com/developerworks/ru/library/l-expect_1/

i	Уведомление от модератора /dev/random
	Отрезано отсюда: Запуск пароленых программ из скрипта

[ZyX]

Кстати, у expect есть как минимум две альтернативы, позволяющие не изучать его синтаксис: dev-perl/Expect (модуль для perl) и app-shells/zsh со своим модулем zpty.

[t.t]

Кстати, у expect есть как минимум две альтернативы, позволяющие не изучать его синтаксис: dev-perl/Expect (модуль для perl) и app-shells/zsh со своим модулем zpty.

Позволяющие вместо синтаксиса expect изучать синтаксис перла или zsh. (:

[drBatty]

Кстати, у expect есть как минимум две альтернативы, позволяющие не изучать его синтаксис: dev-perl/Expect (модуль для perl) и app-shells/zsh со своим модулем zpty.

кстати, некий Mikhail E. Zakharov, ещё в 2005м году приспособил для этих целей dd, но что-то у него не очень получилось, ну он свою программу написал.

В принципе, я могу это и на sed изобразить, только зачем? Какой в этом практический смысл?

[ZyX]

Кстати, у expect есть как минимум две альтернативы, позволяющие не изучать его синтаксис: dev-perl/Expect (модуль для perl) и app-shells/zsh со своим модулем zpty.

кстати, некий Mikhail E. Zakharov, ещё в 2005м году приспособил для этих целей dd, но что-то у него не очень получилось, ну он свою программу написал.

В принципе, я могу это и на sed изобразить, только зачем? Какой в этом практический смысл?

Синтаксис Perl и zsh мне уже известен, а от tcl хочется плеваться. Да и вряд ли кто будет писать скрипты на expect и при этом не знать синтаксис хотя бы POSIX shell (с которым zsh совместим в одну сторону). Практический смысл: не надо учить ещё один язык, можно воспользоваться уже известным. Ещё для Python: dev-python/pexpect.

[drBatty]

Практический смысл: не надо учить ещё один язык, можно воспользоваться уже известным.

а что там учить? я за 15 минут разобрался. (и то, я в это время обедал ;) )

[ZyX]

Практический смысл: не надо учить ещё один язык, можно воспользоваться уже известным.

а что там учить? я за 15 минут разобрался. (и то, я в это время обедал )

Совершенно неверно. Вы целых 15 минут потратили на то, чтобы написать (что, кстати?), я разобрался с zpty за 5 минут, потому что это всего лишь ещё одна команда shell. А вот когда я не знал про zpty я убил полчаса на то, чтобы понять, что я не разберусь за приемлемое для меня время в синтаксисе tcl (частично из-за того, что взял слишком сложный пример) настолько хорошо, чтобы вызвать две разных команды с одним паролем, получаемым от пользователя, при этом информация об аргументах содержалась в переменных окружения. Результатом был скрипт zsh, который создаёт скрипт tcl, в котором пароль жёстко прописан, при этом если я где-то ошибся при вводе, то приходилось перезапускать всё.

Относительно 15 минут: сколько вам понадобится времени, чтобы повторить, скажем, rftp из примеров, приложенных к expect? Если нужно что-то сложное, то не лучше ли воспользоваться тем, что уже знаешь?

[drBatty]

Совершенно неверно. Вы целых 15 минут потратили на то, чтобы написать (что, кстати?)

зайти на сервер и выполнить несколько команд.
по ssh. и ещё отправить туда 1 файл по scp.

А вот когда я не знал про zpty я убил полчаса на то, чтобы понять, что я не разберусь за приемлемое для меня время в синтаксисе tcl (частично из-за того, что взял слишком сложный пример) настолько хорошо, чтобы вызвать две разных команды с одним паролем, получаемым от пользователя, при этом информация об аргументах содержалась в переменных окружения.

http://www.ibm.com/developerworks/ru/library/l-expect_1/
найдено гуглом за доли секунды.

Код: Выделить всё

    01: #!/usr/bin/expect -f
    02: if {[llength $argv] != 2} {
    03:   puts "Вызов: auto_rsync.exp <ИМЯ_ХОСТА> <ПАРОЛЬ_ROOT>"
    04:   exit 1
    05: }
    06: set hostname [lindex $argv 0]
    07: set password [lindex $argv 1]
    08: set timeout -1
    09: spawn date
    10: expect -re "# $"
    11: spawn rsync -av -e ssh $hostname:/etc /archive/sys
    12: expect "password:" {send "$password\r"}
    13: expect -re "# $"
    14: spawn date
    15: expect -re "# $"
    16: spawn rsync -av -e ssh $hostname:/usr/etc /archive/sys
    17: expect "password:" {send "$password\r"}
    18: expect -re "# $"
    19: spawn date
    20: expect -re "# $"
    21: spawn rsync -av -e ssh $hostname:/usr/work /archive/works
    22: expect "password:" {send "$password\r"}
    23: expect -re "# $"
    24: spawn date
    25: expect -re "# $"
    26: exit 0

Относительно 15 минут: сколько вам понадобится времени, чтобы повторить, скажем, rftp из примеров, приложенных к expect? Если нужно что-то сложное, то не лучше ли воспользоваться тем, что уже знаешь?

ну мне и надо было сложное. я написал 2 примитивных expect скрипта, и вызывал их по мере надобности.

[ZyX]

<...>

Относительно 15 минут: сколько вам понадобится времени, чтобы повторить, скажем, rftp из примеров, приложенных к expect? Если нужно что-то сложное, то не лучше ли воспользоваться тем, что уже знаешь?

ну мне и надо было сложное. я написал 2 примитивных expect скрипта, и вызывал их по мере надобности.

Ну, этот пример гораздо понятнее, чем то что я ковырял ранее. Но без изучения tcl я по-прежнему не знаю, как сделать обработку случая неправильного ввода пароля. И по-прежнему знаю, как это сделать с помощью zpty. В данном примере не хватает ввода пользователя и проверки exit code (по-моему, такое невозможно с zpty, но я вижу соответствующий метод в perldoc Expect, несколько больше времени занял поиск его в pexpect). Кроме того, я не привык искать в Google то, что можно написать за 5 минут самому и вообще считаю это плохой практикой для несложных задач.

Кстати, получается у вас тот же способ обхода сложности использования tcl: просто не использовать его, когда его можно не использовать (я про то, что у вас два примитивных скрипта, управляемых явно не expect). Вас не волнует то, что количество языков на одну задачу превышает минимально необходимое?