1
 ssh user@myserver.com<<EOF
    cd ../../my/path/
    sh runscript.sh
    wait
    cd ../../temp/path
    sh secondscript.sh
 EOF

The first script runs and asks me the questions in that script, but before i'm even able to start typing to answer them the second script starts running. From what I'm reading this shouldn't be happening even without the wait.

  • you need to append `&` char to end of runscript.sh cmd for it to run in the background, then `wait` can have some effect. But given that you want to NOT have `secondscript.sh` run until first is complete, forget the `&` and forget the `wait`. You can put a `read myVar?"Press Enter Key to continue"` to fake a `pause` feature. Good luck. – shellter Mar 21 '14 at 18:23
  • From WHERE the script1 reading? From the STDIN? You have redirected the STDIN to local HEREDOC... Or me missed some point? – clt60 Mar 21 '14 at 18:43
  • runscript.sh will read user input from the terminal. So I don't really want to fake a pause. I need to be entering information that runscript.sh will use. Then once it finishes, secondscript.sh will run. – user1958833 Mar 21 '14 at 18:51
  • `wait` won't even be seen/started until `sh runscript.sh` has finished. `wait` has nothing to do because you are not backgrounding anything. To put you on a different track, are you sure that `sh runscript.sh` is getting your terminal input? `ssh ...` is reading its input from a here-doc, and likely just ignoring your terminal (which may not even be connected since you don't use `ssh -t`...). – twalberg Mar 21 '14 at 19:23
  • Twalberg. I think this is what is happening. This script I'm writing starts running the runscript.sh and I get a warning "Pseudo-terminal will not be allocated because stdin is not a terminal". I assume this means it doesn't care whether it's finished or not, nor will it get any of my stdin. – user1958833 Mar 21 '14 at 19:43
  • @user1958833 Not so much that it doesn't care, but any attempts by `runscript.sh` to read from the terminal are likely to fail - what happens in that case depends entirely on what `runscript.sh` does, but I can't guess at that. It's quite possible it just terminates quickly after it fails to get the expected input, either because it is well-behaved and does so intentionally, or because it does a whole bunch of things with an empty string that end up causing other things to fail... – twalberg Mar 21 '14 at 20:37

0 Answers0