Automatically pass a value to a script menu for automation's sake in Bash/KSH - linux

Trying to make a small script and cron job it in order to automate a task. Said script runs another script which has already been created, grabs the output, emails to specified recipients, and cleans up the output. I've got it almost down however am running into one major issue. The script that mine is running has a menu on the outset. That is to say, running the script by itself manually, i would have to select option 1 in order to get the output i want (the only other option, 2, is quit.)
How can I automatically enter (or simulate entering) the value 1 into the other script, so it does not hang when in a cron job waiting for user input?
Is there a sane way to do this?
Thanks in Advance.

You could try something as simple as using yes | command if answering yes is all that is needed. Otherwise you probably want to use expect to drive the imaginary keyboard for you.
http://expect.sourceforge.net/
Using autoexpect to record your session is a convenient way to come up with rough draft expect scripts as well.

Related

Detect and Enter Input on a prompt in shell script

I'm working on a shell script, which has lot of network calls and installations. When it is executed I need to enter yes/no for each prompt. Which is fine.
But now i have a requirement to run it as cron. In which case i won't be able to give inputs for each of the prompt that comes up.
Is there any way I can automate this or have some mechanism of knowing in script that a prompt has come up?
Use the yes command to answer interactive prompts,
yes Y | ./script.sh
The above syntax constantly puts the string Y to all your prompts. You can pass the string as you need after yes.
You can also use expect tool meant for this, but you need to know the exact prompt message for capturing and responding to it accordingly. If your prompt is simple and just need a simple input to pass yes would be the right tool.
Also you can use bash built-in printf, but you need to add the responses manually depending upon the number of prompts you have to respond to, e.g.
printf 'Y\nY\nY\n' | ./script.sh
to send response as Y for three prompts. As again, to avoid doing this manually, prefer using the yes command.

Python - (SSH/Telnet) connection with multiple commands

I need to run a shell script that should interact with couple of servers / routers in daily schedule. The script will simply login to the remote end, run a command. Up to here i hear that you are saying it is easy. The real problem here is that i need to analyze the output of the first command and based on the output i need to organize the second command. This is also doable, but the situation here is that i do not want to login and logout from the box for every command.
What i need is to login once, stay alive ,run the command take the output, analyze it and then run the second command later on logout and close connection.
Correct me if i am wrong but expect is not an option here. I want to ask for your suggestions.
Which language / module of this language i can use to complete this requirement.
Environment is not pure ssh, so i should have something general that can be used for both ssh/telnet.
Thanks in advance
Since you mentioned python, pexpect should do the job pretty well:
https://pexpect.readthedocs.org/en/latest/overview.html

get userinput from bash script (executed by cron or udev)

EDIT, the question might have not been totally clear, short version:
How to popup a dialog asking for user input if the script is running in the background and not in an active console?
/EDIT
When I run a bash script from udev or cron, it usually runs quietly somewhere in the background. Example could be plugging in an external harddrive runs rsync for data backup. So not every time I plug in the harddrive do I want to launch this action.
What is the most minimal way to fire up some user input dialog and ask yes or no? I could write some interface with PyQt but I want as little dependencies as possible, ideally cross window manager and maybe even without window manager.
Thanks!
EDIT 2: The lightweight (and hence as ugly as expected) version is xmessage, this would probably be the answer to the question, unless you have a better one:
xmessage "Do you want to run the backup script?" -buttons yes,no
http://linux.byexamples.com/archives/87/using-gui-dialog-box/
EDIT: So there's KDialog for kde, is there something really lightweight for X?
http://www.linux-magazine.com/Issues/2009/99/Zenity-and-KDialog
kdialog --title "Do you want to run the backup script?"
--yesno "Do you want to run the backup script?"
I'm currently leaning towards zenity, only trouble is it pulls in a whole array of gtk dependencies on kde, but is cross platform and works on windows. In essence, this is exaclty what I was looking for:
if zenity --question --text="Please press a button."; then
zenity --info --text="You pressed Yes\!"
else
zenity --error --text="You pressed No\!"
fi
But was hoping it would be a lot lighter on the resources / dependencies. Any alternative suggestions?
A simple approach would be for the automated script to simply email you, or perhaps alert with wall with instructions (containing the location of the real script).
Another approach would be for the automated script to touch a file in /var/lib and proceed if the file is still present after 5 minutes. This gives the user the option to stop the process (by removing the file), but maintains some automation.
This is not something you should have cron or udev handling in the first place. Write a userland daemon that listens for the appropriate D-Bus messages and performs the appropriate actions.
This should be post in linux or superuser or serverfault.
But, the number one google search on linux read user input links back here to StackOverflow:
https://www.google.com/search?q=linux+read+user+input&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a&channel=fflb
so I guess it's not too off base.
Again, the third or so google result for linux invoke command usb device plugin links to ServerFault:
https://serverfault.com/questions/399698/execute-a-command-when-a-device-is-connected-via-usb
I'll leave combining those two as an exercise.

Check from within bash script that autocompletion is initialized

I'm looking for a method to check from within my shell script that script specific completion have been initialized by user using complete -F ...
I want this check to print out an advice on how to initialize the completion like:
Warning: Auto completion is not initialized. Please run : source ....; complete -F ...
The problem is that the script,being run in a sub-shell has no information about "complete" environment of the parent shell where user is working.
So complete -p| grep my-script-name never return any result.
User is expected to run "source" and "complete" commands or add them into his .bashrc manually, because we're working on a server where we have no access to the bash completion system directory.
Alternatively if you know a method of initializing(and not only checking) the auto-complete from within the script, I would happily accept it.
The only way your script can have access to such information for the parent shell is if it is included instead of executed as a sub-shell. Rather than instructing your users they can include some configuration, you can design your script so it works whether it is run or included.
Then you can simply inform your users that if they want completion enabled they need to include your script rather than run it as an executable script (with instuctions to use source or . as you wish).
However, in this case, I would be inclined to either add this information in documentation or add it into a banner which is always displayed (but can be disabled with an option switch like -q), rather than support two modes of running the script (since the gain is so small).
Either you want every user to use bash completion (which I don't think is good, for example I prefer to have it turned off), or let users decide themselves, but having them this message printed out on each TABTAB is a threat, don't you think?
I'd put into /etc/bash.bashrc what you think every user should run.

Shell script - input redirection when prompted by the shell script multiple times

We have a shell script that expects multiple user inputs to be entered when prompted. e.g
At first it may ask for the operation to be performed. When that answer is given, it may ask for username then password etc. We want to automate this task by providing the inputs using file redirection i.e.
script < input.
The input file will have all the answers for different questions that the script may ask. However it is not working and the shell script is reading only the first line of the input file. What do I need to change or use to make this work?
What you can use is the program expect. You create a script for it that tells it when to give what input to some command it executes. This way you can automate exactly the kind of thing you're struggling with.
More info on Google and here:
http://www.linuxjournal.com/article/3065
man page: http://linux.die.net/man/1/expect
You say 'it only reads the first line of input.'
So you have to kill the script?
Is there any output? (error messages especially)?
Are you redirecting STDERR to /dev/null or else where? If so, remove that.
Here is the hightest probability helper ... Modify the top-level script and add set -vx at the 2nd line. Then you'll be able to see what was processed, where it has stopped and possibly formulate theories about why it is not processing data.
Any chance that the input file was created in a Windows environment and the cr\lf pair is messing up the expected input?
I hope this helps.
Thanks all for commenting and answering. I tried except and that did not work. So I am going to mention what worked for us. Here was our workflow - 1. At the linux prompt, type the command, it was connect() in our case. 2. Once that command is given, the script would ask for parameters for the command like port number, server etc. we had to provide that manually 3. Then we again are presented with a shell prompt with another input. In our case, we were able to provide the first command connect() at the prompt using file redirection, but the parameter passing was an issue. The solution we found was provide the parameters inside the parentheses of connect only i.e. our input file for redirection would contain - connect(). This worked for us.

Resources