Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been teaching myself bash scripting and have run into an issue. I have written a script to take input from the user, using the 'read' command, and make that input a variable to use later in the script. The script works, but....

I would like to be able to get it setup using 'dialog'. I found out that

'dialog --inputbox' will direct the output to 'stderr' and in order to get that input as a variable you have to direct it to a file and then retrieve it. The code I found to explain this is:

dialog --inputbox \

"What is your username?" 0 0 2> /tmp/inputbox.tmp.$$


input=`cat /tmp/inputbox.tmp.$$`

rm -f /tmp/inputbox.tmp.$$

case $retval in

echo "Your username is '$input'";;

echo "Cancel pressed.";;


I see that it is sending the sdterr to the /tmp/inputbox.tmp.$$ with 2>, but the output file looks like 'inputbox.tmp.21661'. When I try and cat the file it gives me an error. So I am still unable to get the user input from the --inputbox as a variable.

Example Script:

echo "  What app would you like to remove? "

read dead_app

sudo apt-get remove --purge $dead_app

So as you can see it is a basic script. Is it even possible to get the variable as a word from dialog --inputbox?

share|improve this question
In my experience the script works fine, if you remove the empty line after the 2nd line. Alternatively, you could use mktemp command to create a temporary file. – jarno Jul 16 at 20:52

:D I can't explain it!!! If you can understand what they are saying in the reference:Advanced Bash-Scripting Guide: Chapter 20. I/O Redirection, write a new answer and I will give you 50rep

Bounty was given, for explanation see ByteCommander's answer. :) This is a part of the history.

exec 3>&1;
result=$(dialog --inputbox test 0 0 2>&1 1>&3);
exec 3>&-;
echo $result $exitcode;

Source: Dialog in bash is not grabbing variables correctly
Reference:Advanced Bash-Scripting Guide: Chapter 20. I/O Redirection

share|improve this answer
is that offer still valid? I think I could explain what you found there one and a half years ago... :-) – Byte Commander Dec 1 '15 at 13:15
@ByteCommander, but however if you can provide that, I will give you that, I will be at my words :D. – Sneetsher Dec 1 '15 at 13:25
@ByteCommander, please , ping me after you post it. – Sneetsher Dec 1 '15 at 13:41
Finished! I hope you understand everything and enjoy the "Eureka!" moment. :-D Leave a comment if anything was left unclear. – Byte Commander Dec 1 '15 at 14:29

:D I can't explain it!!! If you can understand what they are saying in Advanced Bash-Scripting Guide: Chapter 20. I/O Redirection, write a new answer and I will give you 50rep:

exec 3>&1;
result=$(dialog --inputbox test 0 0 2>&1 1>&3);
exec 3>&-;
echo $result $exitcode;

Reference: Dialog in bash is not grabbing variables correctly

^ answer from @Sneetsher (Jul 4, 2014)

As requested, I will try to explain what this snippet is doing line by line.

Note that I will simplify it by omitting all the ; semicolons at the line ends, because they're not necessary if we write one command per line.

I/O - Streams:

First, you need to understand the communication streams. There are 10 streams, numbered from 0 to 9:

  • Stream 0 ("STDIN"):
    "Standard input", the default input stream to read data from the keyboard.

  • Stream 1 ("STDOUT"):
    "Standard output", the default output stream used to show normal text in the terminal.

  • Stream 2 ("STDERR"): "Standard error", the default output stream used to display errors or other text for special purposes in the terminal.

  • Streams 3-9:
    Additional, freely usable streams. They're not used by default and do not exist until something attempts to use them.

Note that all "streams" are internally represented by file descriptors in /dev/fd (which is a symbolic link to /proc/self/fd which contains another symbolic link for every stream... it's a bit complicated and not important for their behaviour, so I stop here.). The standard streams also have /dev/stdin, /dev/stdout and /dev/stderr (which are symbolic links again, etc...).

The script:

  • exec 3>&1

    The Bash built-in exec can be used to apply a stream redirection to the shell, that means it affects all following commands. For more info, run help exec in your terminal.

    In this special case, the stream 3 gets redirected to stream 1 (STDOUT), that means everything we send to stream 3 later will appear in our terminal as if it was normally printed to STDOUT.

  • result=$(dialog --inputbox test 0 0 2>&1 1>&3)

    This line consists of many parts and syntactical structures:

    • result=$(...)
      This structure executes the command in the brackets and assigns the output (STDOUT) to the bash variable result. It's readable through $result. All this is described somehow in the veeeery looong man bash.

    • dialog --inputbox TEXT HEIGHT WIDTH
      This command shows a TUI box with the given TEXT, a text input field and two buttons OK and CANCEL. If OK gets selected, the command exits with status 0 and prints the entered text to STDERR, if CANCEL gets selected, it will exit with code 1 and print nothing. For more info, read man dialog.

    • 2>&1 1>&3
      These are two redirection commands. They will be interpreted from right to left:

      1>&3 redirects the command's stream 1 (STDOUT) to the custom stream 3.

      2>&1 redirects afterwards the command's stream 2 (STDERR) to stream 1 (STDOUT).

      That means that everything the command prints to STDOUT now appears in stream 3, while everything that was intended to show up on STDERR now gets redirected to STDOUT.

    So the entire line displays a text prompt (on STDOUT, which got redirected to stream 3, which the shell again redirects back to STDOUT in the end - see the exec 3>&1 command) and assigns the entered data (returned through STDERR, then redirected to STDOUT) to the Bash variable result.

  • exitcode=$?

    This code retrieves the previously executed command's exit code (here from dialog) through the reserved Bash variable $? (always holds the last exit code) and simply stores it in our own Bash variable exitcode. It can be read through $exitcode again. You can search for more info on this in man bash, but that might take a while...

  • exec 3>&-

    The Bash built-in exec can be used to apply a stream redirection to the shell, that means it affects all following commands. For more info, run help exec in your terminal.

    In this special case, the stream 3 gets redirected to "stream -", which just means it should be closed. Data sent to stream 3 will not get redirected anywhere any more from now on.

  • echo $result $exitcode

    This simple echo command (more info on man echo) just prints the content of the two Bash variables result and exitcode to the STDOUT. As we have no explicit or implicit stream redirections here any more, they will really appear on STDOUT and therefore simply get displayed in the terminal. What a miracle! ;-)


First, we set the shell up to redirect everything we send to the custom stream 3 back to STDOUT, so that it shows up in our terminal.

Then we run the dialog command, redirect its original STDOUT to our custom stream 3, because it needs to get displayed in the end, but we temporarily need to use the STDOUT stream for something else.
We redirect the original STDERR of the command, where the dialogue window's user input gets returned, to STDOUT afterwards.
Now we can capture the STDOUT (which holds the redirected data from STDERR) and store it in our variable $result. It contains the wanted user input now!

We also want the dialog command's exit code, which shows us whether OK or CANCEL was clicked. This value is presented in the reserved Bash variable $? and we just copy it to our own variable $exitcode.

After that we close stream 3 again, as we don't need it any more, to stop further redirections of it.

Finally, we normally output the contents of both variables $result (the user input of the dialogue window) and $exitcode (0 for OK, 1 for CANCEL) to the terminal.

share|improve this answer

You can use zenity:

sudo apt-get install zenity

Then in your script:

RETVAL=`zenity --entry --title="Hi" --text="What is your username"`

Useful link.

share|improve this answer
Unless there is no X server – user877329 Dec 1 '15 at 20:23
Obviously, it is a graphic utility. – Wtower Dec 1 '15 at 20:58
OP wants to know about dialog. It's like I come and ask you "How do I write this and that in python ? " , but you give me bash - i'm very happy this can be done different way, but that's not what I am asking – Serg Jul 17 at 4:01

If you read man page for dialog, there is option --output-fd, which allows you to explicitly set where the output goes (STDOUT 1 , STDERR 2), instead of by default going to STDERR.

Bellow you can see me running sample dialog command , with explicitly stating that output must go to file descriptor 1, which allows me to save it into MYVAR.

MYVAR=$(dialog --inputbox "THIS OUTPUT GOES TO FD 1" 25 25 --output-fd 1)

enter image description here

Alternative approach which has a lot of hidden potential, is to use something known as named pipe.

xieerqi:$ cat


mkfifo /tmp/namedPipe1 # this creates named pipe, aka fifo

dialog --inputbox "This is an input box  with named pipe" 40 40 2> /tmp/namedPipe1 & # to make sure the shell doesn't hang, we run redirection in background, because fifo waits for output to come out

OUTPUT="$( cat /tmp/namedPipe1  )" # release contents of pipe

echo  "This is the output " $OUTPUT

enter image description here

share|improve this answer
The manpage also says that --stdout option can be dangerous and is easily failing on some systems, and I think --output-fd 1 is doing the same: --stdout: Direct output to the standard output. This option is provided for compatibility with Xdialog, however using it in portable scripts is not recommended, since curses normally writes its screen updates to the standard output. If you use this option, dialog attempts to reopen the terminal so it can write to the display. Depending on the platform and your environment, that may fail. - However, the named pipe idea is cool! – Byte Commander Dec 1 '15 at 15:51
@ByteCommander "May fail" isn't a very convincing , as this doesn't provide examples. In addition, they don't mention anything about --output-fd , which is the option I used here, not --stdout. Second, the dialog is being drawn on stdout first, the output returned is second. We don't do these two things at the same time. However, --output-fd doesn't specifically require one to use fd 1 (STDOUT). It can easily be redirected to another file descriptor – Serg Dec 1 '15 at 15:58
I am not sure, maybe it works everywhere, maybe it works only on most systems. It works on mine and the manpage says to use a similar option with caution is all I know for sure. But as I already said, the +1 is deserved for the named pipes anyway. – Byte Commander Dec 1 '15 at 16:10
I should comment here, to keep some equilibrium. To me, this may the only direct canonical answer (1) it uses only same tool & it implemented options without any external tool (2) It does work in Ubuntu and that all what AU is about. :/ sadly the OP seems to abandon this question. – Sneetsher Dec 4 '15 at 16:16
What is the advantage of using named pipe instead of regular file here? Don't you want to delete the pipe after use? – jarno Jul 16 at 20:38

The answer provided by Sneetsher is somewhat more elegant, but I can explain what's wrong: The value of $$ is different inside the backticks (because it starts a new shell, and $$ is the PID of the current shell). You'll want to put the file name in a variable, then refer to that variable throughout instead.

t=$(mktemp -t inputbox.XXXXXXXXX) || exit
trap 'rm -f "$t"' EXIT         # remove temp file when done
trap 'exit 127' HUP STOP TERM  # remove if interrupted, too
dialog --inputbox \
    "What is your username?" 0 0 2>"$t"
input=$(cat "$t")  # Prefer $(...) over `...`
case $retval in
  0)    echo "Your username is '$input'";;
  1)    echo "Cancel pressed.";;

In this case, avoiding the temporary file would be a better solution, but there will be many situations where you cannot avoid a temp file.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.