| 1 |
On Friday, 15 July 2022 18:39:25 CEST Grant Taylor wrote: |
| 2 |
> On 7/14/22 3:22 PM, Steve Wilson wrote: |
| 3 |
> > Have you looked at dev-tcltk/expect? |
| 4 |
> |
| 5 |
> Expect has it's place. |
| 6 |
> |
| 7 |
> Just be EXTREMELY careful when using it for anything security related. |
| 8 |
|
| 9 |
I agree |
| 10 |
|
| 11 |
> Always check for what is expected before sending data. Don't assume |
| 12 |
> that something comes next and blindly send it (possibly after a pause). |
| 13 |
> |
| 14 |
> Things break in a really weird and unexpected way. (No pun intended.) |
| 15 |
> |
| 16 |
> Also, do as much logic outside of expect as possible. E.g. don't try to |
| 17 |
> add a user and then respond to a failure. Instead check to see if the |
| 18 |
> user exists /before/ trying to add it. |
| 19 |
|
| 20 |
I've been using ansible for some of my automation scripts and am happy with |
| 21 |
the way that works. The existing implementations for "adding users" and such |
| 22 |
is tested plenty by others and does actually check if the user exists before |
| 23 |
trying to add one. |
| 24 |
|
| 25 |
> Plan on things failing and try to control the likely ways that it can fail. |
| 26 |
> |
| 27 |
> Paying yourself forward with time and effort developing (expect) scripts |
| 28 |
> will mean that you reap the rewards for years to come. |
| 29 |
|
| 30 |
I only use expect to automate the login-process as mentioned in the original |
| 31 |
email. The line it's expecting is more then just "*?assword" like in all the |
| 32 |
examples. |
| 33 |
|
| 34 |
Currently, SSH puts the password-prompt as: |
| 35 |
(<username>@<hostname>) Password: |
| 36 |
|
| 37 |
As I know both, the expected string is this full line. If SSH changes its |
| 38 |
behaviour, the script will simply fail. |
| 39 |
|
| 40 |
-- |
| 41 |
Joost |
Archives