Automatize an interactive program, how???

[calexica]

Hi there!
I need to run an easy program consisting in 4 file executions in a row. But in between, the user has to type 'enter' or '1' a number of times, always the same.

My question: in the following script:
#!/bin/bash
vors
rnd
smor3D
bintoc

I need to input 'Enter' while some of the programs run; plus to stop the third one (smor3D) when it's result file has certain size (let's say >0; would suffice by now).

So, it's this program that's brought me to Linux, & it's great, but I have no clue on how to do this & have an approaching deathline to submit results. I need to automatize this program run (so to install it in a few computers & let them work for a week, or two).

Any help will be greatly, madly appreciated!!!! I'll keep doing my own research meanwhile.
Cheers!!!

[tetsujin]

Hi there!
I need to run an easy program consisting in 4 file executions in a row. But in between, the user has to type 'enter' or '1' a number of times, always the same.

My question: in the following script:
#!/bin/bash
vors
rnd
smor3D
bintoc

I need to input 'Enter' while some of the programs run; plus to stop the third one (smor3D) when it's result file has certain size (let's say >0; would suffice by now).

OK, first off, I assume these are text-mode (TTY) programs, and not windowed applications?

Basically there are two ways a TTY program can take user keyboard input: the first is via "standard input", the second is by accessing the process's controlling TTY directly.

Ordinarily these two approaches yield the exact same result: but if you redirect a program's input, then stdin for that program will not be the program's TTY but rather whatever you've redirected stdin to be... For instance:

mkdir test; cd test
touch a b c d e f g
chmod a-w *
# The files are now not writable: attempts to remove them using "rm" without the "force" flag will result in a user prompt, if "rm" is in interactive mode...  "rm" is normally in interactive mode only if stdin is a TTY - so here we force it interactive with --interactive...
(while true; do echo y; done) | rm --interactive *
# All the "are you sure?" prompts from interactive mode were answered "yes" by the pipeline input...

Now, that kind of pipelining input works only if the program takes its input from stdin. If it goes directly to the TTY (by opening /dev/tty, etc.) then it effectively bypasses this mechanism. Certain programs will do this when printing password prompts, for instance, to discourage users from putting passwords into shell scripts. If you need to provide input to a program that takes input from its TTY, then you need to either run the program in such a way that its controlling TTY is a pseudo-TTY, and then write the data in on the PTY master, or else you need to use an ioctl to push data into the TTY's input buffer...

Either method is a bit more complicated to explain fully - but the point I want to get across mostly is just that if the program uses TTY input, then the normal shell redirects won't affect it. You could use a program like "expect" to interact with the program in this case...

If it is a GUI app, then the way it interfaces with the keyboard is totally different - I don't know the answer in that case.

[calexica]

Hey!!!!!!!! thanks so, so much! it was so terribly easy!!

#!/bin/bash
vors < inputEnter
rnd < inputEnter
smor3D
bintoc < inputEnter

Being the content of inputEnter = ^M

hahahahahahahaha!!!!!!!!!!!!!!!!!!! not yet finished with the second part (to stop the third one (smor3D) when it's result file has certain size (let's say >0; would suffice by now), but no worries now.

'stdin' was the keyword.