I am building a interactive bash script and I have been using whiptail for input and message boxes. However the infoboxes will not always work. (Works on my active server but not on my VM. Same Ubuntu 14.04 accessed with Putty in windows)
I am trying to switch to dialog but the code I was using with whiptail to output to a variable rather than a file does not seem to work in dialog.
UNAME=$(whiptail--inputbox "Enter the user you want your scripts to run as. (Case sensitive, Must exist)" 10 50 --title "System Username" 3>&1 1>&2 2>&3)
I tried changing whiptail to dialog and I get a box and can enter and submit data but then the variable is not set. I got this from another forum and there was no real description of whats actually happening here. All I know is it sets the variable with the input data rather than what is normally output to stderr.
dialog appears to be sensitive to option ordering. Put the --title option before the --inputbox option and it should work (at least it does here).
Related
I found out about Dialogs, so I'm updating menus today. So far, so good.
I came to one where I need to collect a user's input.
I have
dialog --title " INPUT FILE NAME: " --inputbox "$(ls)" 30 40 2> answer
This will send the users input to a file named "answer"
I have tried
dialog --title " INPUT FILE NAME: " --inputbox "$(ls)" 30 40 2> $answer
but that doesnt seem to do anything.
I tried
answer=$(dialog --title " INPUT FILE NAME: " --inputbox "$(ls)" 30 40 2)
but there is some kind of error.
The manual page (for dialog) tells the story:
Some widgets, e.g., checklist, will write text to dialog's output.
Normally that is the standard error, but there are options for changing
this: "--output-fd", "--stderr" and "--stdout". No text is written if
the Cancel button (or ESC) is pressed; dialog exits immediately in that.
The reason dialog uses the standard error by default for its output is that it uses the curses/ncurses library, which normally prints its output (for the screen updates) to the standard output. To change dialog's behavior (and write to the standard output), use the "--stdout" option.
Interestingly (though it may appear an obvious problem to solve because it complicates scripting), the Xdialog program implemented this option first; it seemed a Good Thing to add to dialog (see changelog).
Done
dialog --title " INPUT FILE NAME: " --inputbox "$(ls )" 30 40 2>answer
ans=$(cat answer)
rm answer
I very frequently work on multiple items in parallel and end up running some long tests or regression after working on something. I usually add a mail -s "foo" id < /dev/null at the end to know when a task ends so that I don't have to baby sit a long test or regression.
I was trying to automate this, where in I don't have to type the mail every time, just call a script (alias this to fewer characters - optimizing on how much I type) and the script figures out the test/regression from the cwd and sends an email. I thought it would be useful to send the terminal title or the screen session name in the email. Is there a way I can extract the terminal title or Linux screen window name?
You can find the screen session name, when attached, in $STY (the window number is available in $WINDOW if you need it):
$ echo "$STY"
6367.sessionname
You can find the uniquely identifying tty/pty device with tty:
$ tty
/dev/pts/34
Titles and such are features of xterm and not of the terminal itself, so terminals programs have a hard time deducing it.
Here's an example using both of the above to show the screen name if any, or the tty device otherwise:
mail -s "${STY:-$(tty)} done" < /dev/null
Screen also has a "wait for silence" feature where you can get a notification when processes in other screen windows have stopped outputting.
I'm working on an embedded linux system; my console is a serial port and there is a VGA video output at /dev/tty0.
I am trying to use the 'dialog' (1) utility to display menu-like displays on the VGA screen.
I can get dialog output on the console:
dialog --inputbox "Hello Dialog World" 10 30
and I can get something similar on the VGA screen by redirection:
dialog --inputbox "Hello Dialog World" 10 30 >/dev/tty0
But I want to use the '--output-fd' parameter to dialog to achieve a similar result and I can't get it to work.
I've tried things in a bash script like:
exec 4>/dev/tty0
dialog --output-fd 4 --inputbox "Hello Dialog World" 10 30
exec 4>&-
but this seems to write to the console as previously.
I seem to be misunderstanding the operation of the --output-fd parameter - can anyone help?
(in actual fact, I want to use the python-dialog wrapper for dialog; but I need to understand how to use the underlying dialog utility before I take the next step)
Quote from the manual page:
Some widgets, e.g., checklist, will write text to dialog’s output.
Normally that is the standard error, but there are options for
changing this: "--out-put-fd", "--stderr" and "--stdout".
This means that the --output-fd option does not specify a file descriptor for any output but only for the data generated by some widgets.
I use InstallAnywhere in console mode in Linux for installation and want to run some interactive shell script after finishing the installation. By "interactive" I mean that the script should ask some questions and receive user input.
I tried to run it with "Execute target file" action, but the script prints nothing to the console (it surely executed because prints debug information to output file). I also tried to bring the script to foreground using "fg %1" (it was the last command in InstallAnywhere), but it did not work too.
Is there any way to execute interactive script by InstallAnywhere in console mode?
Rather than using a shell script for user interaction, leverage IA to collect the answers you need, stuff them into IA variables, then use those variables in one or more "Execute Script/Batch file" Actions to do the post-install work.
Say you want to collect a first name, last name and phone then write those to a file in your installation directory (contrived, I know, but hopefully demonstrative).
Add a Jump Label and name it something like "Get User Info"
Add the Console Action "Get User Input" to read the first name. Assign the result to $FIRST_NAME$.
Add the Console Action "Get User Input" to read the last name. Assign the result to $LAST_NAME$.
Add the Console Action "Get User Input" to read the phone number. Assign the result to $PHONE_NUMBER$.
Add the "Jump To Target" Action with a NEXT Jump Action of "Get User Info" (#1, above). Add rules to validate these three variables such that a TRUE result will execute the jump to "Get User Info". In other words, a BAD first name or BAD last name or BAD phone number should evaluate to TRUE. This will send the user back to the "Get User Info" Target Label. Three valid values should evaluate to false, thereby NOT executing the jump. I know. It's weird.
Finally, add as many "Execute Script/Batch file" Actions as needed to for each target installation platform. For each of these actions, add a rule that limits execution of that Action to a specific platform. For the Unix/Linux actions, be sure to check the checkbox "Do not substitute unknown variables" or IA will substitute YOUR script variables with blanks. (word of caution: use the full variable name form ${MY_VARIABLE_NAME} to help IA distinguish your variables from its own variables).
A Unix/Linux version might look like this:
#!/bin/sh
echo <<EOF
Name: $FIRST_NAME$ $LAST_NAME$
Phone: $PHONE_NUMBER$
EOF > $USER_INSTALL_FOLDER$$/$userName.txt
The Windows version is similar:
echo "Name: $FIRST_NAME$ $LAST_NAME$" > $USER_INSTALL_FOLDER$$/$userName.txt
echo "Phone: $PHONE_NUMBER$" >> $USER_INSTALL_FOLDER$$/$userName.txt
Note the use of $/$ which IA converts to the appropriate path separator for the current platform.
After the "Execute Script/Batch file" Actions you can add steps to evaluate the success of the Script/Batch file. Add rules on "Jump To Target" Actions to evaluate the value of $EXECUTE_EXITCODE$. $EXECUTE_EXITCODE$ is the default variable where the process' exit code is stored by "Execute Script/Batch file" Actions.
Real-life installation scripts could be more complex than this. You could collect any number of variables and use them in any number of post-installation script(s). These scripts then focus on doing the work, not on talking to the user. That should be IA's job.
Two parting thoughts:
First, this same technique could be used with a GUI installer, too. In fact, mixing GUI and console input actions in the same project extends your installer to both graphical and console target platforms. The Post-Install scripts remain the same regardless of how you collect the input.
Finally, you should ask your questions (if possible) during Pre-Install. That way the user can decide to bail on the installation if they can't or won't answer the questions. Asking the questions during post-installation could leave the installation hanging, or force the user to roll back, if they are unwilling or unable to provide the information you need.
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.