So I am trying to basically ssh into a server and run a local expect script on there. I tried to follow something similar to how you'd do a bash command i.e.

    ssh -A user@remote "bash -s" < ./script "arg1" "arg2"

I did it in the format of this for my expect script:

    ssh -A user@remote "expect" < ./script "arg1" "arg2"

But I keep getting the error of:

    couldn't read file "arg1": No such file or directory.

I assume it is trying to read my first argument as a file and have tried to remedy this by looking at this post: How can I execute local script on remote machine and include arguments? However, none of these solutions are working for me. What could be the problem?


2 Answers 2


expect appears to be trying really hard to read from the first argument as if it were a file, even if one uses - for that slot. One workaround appears to be to give /dev/stdin as the filename for expect to read.

$ printf 'puts [lindex $argv 1]' | ssh host 'expect /dev/stdin one two'
  • That does not run my local expect script on a remote machine though.
    – AAlred
    Jan 23, 2018 at 21:51
  • That does not run my local script on a remote server though @thrig
    – AAlred
    Jan 23, 2018 at 22:08
  • printf 'puts [lindex $argv 1]' is a local script. it is equivalent to putting puts [lindex $argv 1] into a file called ./script and piping that same data over SSH
    – thrig
    Jan 23, 2018 at 22:11

The easiest way is to scp the expect script to the remote machine and run it there. This avoids all manner of quoting and file descriptor and variable scope (and more) issues that will really mess up your day and waste your time.

A better alternative is to re-write your expect script as a perl script (the Net::SSH CPAN module is perfect for this job. There's also a more generic Expect CPAN module), or as a python script using one of several available ssh methods or Pexpect.

IMO, if you're not already expert in the expect or tcl languages, learning a narrowly-focused tool like expect is a waste of time that could more usefully be spent learning or improving your skill with a generically-useful tool/language.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .