Bash – Is It Safe to Type Another Command into STDIN While Writing to STDOUT

bashshellstdinstdout

Perhaps this has been answered previously, I would welcome a link to another answer…

If I execute a shell command (in a bash shell) like the following:

make

Then while the output from make is scrolling by from the STDOUT of the make command, if I type make check and press enter before the first command is finished executing, when the make command finally finishes the next command make check will pick right up and run.

My question(s) are simply:

Is this dangerous to do?
Are there any potential unexpected behaviors from this kind of rush typing?
Why does this work the way it does?

Best Answer

It works the way it does because Unix is full-duplex. As Ritchie said in The UNIX Time-sharing System: A Retrospective:

One thing that seems trivial, yet makes a surprising difference once one is used to it, is full-duplex terminal I/O together with read-ahead. Even though programs generally communicate with the user in terms of lines, rather than single characters, full-duplex terminal I/O means that the user can type at any time, even if the system is typing back, without fear of losing or garbling characters. With read-ahead, one need not wait for a response to every line. A good typist entering a document becomes incredibly frustrated at having to pause before starting each new line; for anyone who knows what he wants to say any slowness in response becomes psychologically magnified if the information must be entered bit-by-bit instead of at full speed.

[end quote]

That being said, there are some modern programs that eat up or discard any typeahead; ssh and apt-get are two examples. If you type ahead while they're running, you may find that the first part of your input has disappeared. That could conceivably be a problem.

ssh remotehost do something that takes 20 seconds
mail bob
Dan has retired. Feel free to save any important files and then do
# ssh exits here, discarding the previous 2 lines
rm -fr *
.

Related Solutions

Pipe Command – How to Pipe Stdout on One Server to Stdin on Another Server

This is an unabashed yes.

When one uses ssh to execute a command on a remote server it performs some kind of fancy internal input/output redirection. In fact, I find this to be one of the subtly nicer features of OpenSSH. Specifically, if you use ssh to execute an arbitrary command on a remote system, then ssh will map STDIN and STDOUT to that of the command being executed.

For the purposes of an example, let's assume you want to create a backup tarball, but don't want to, or can't, store it locally. Let's have a gander at this syntax:

$ tar -cf - /path/to/backup/dir | ssh remotehost "cat - > backupfile.tar"

We're creating a tarball, and writing it to STDOUT, normal stuff. Since we're using ssh to execute a remote command, STDIN gets mapped to the STDIN of cat. Which we then redirect to a file.

Shell – the difference between the use of ; and executing a script

Yes, there is a big difference. && is short-circuiting, so the subsequent command would be executed only if the previous one returned with an exit code of 0.

Quoting from the manual:

expression1 && expression2
True if both expression1 and expression2 are true.

On the other hand, a script containing

expression1
expression2

would execute the second expression even if the first failed. (Unless you specified the script to exit on error by saying set -e.)

EDIT: Regarding your comment whether:

command1; command2

is the same as:

command1
command2

The answer is usually. Bash parses an entire statement block before evaluating any of it. A ; doesn't cause the previous command to be evaluated. If the previous command were to have an effect on how the subsequent one would be parsed, then you'd notice the difference.

Consider a file containing aliases, lets call it alias, with an entry:

alias f="echo foo"

Now consider a script containing:

shopt -s expand_aliases
source ./alias
f

and another one containing:

shopt -s expand_aliases; source ./alias; f

then you might think that both would produce the same output.

The answer is NO. The first one would produce foo but the second one would report:

... f: command not found

To clarify further, it's not expand_aliases that's causing the problem. The problem is due to the fact that a statement like:

alias f="echo foo"; f

would be parsed in one go. The shell doesn't really know what f is, this causes the parser to choke.

Best Answer

Related Solutions

Pipe Command – How to Pipe Stdout on One Server to Stdin on Another Server

Shell – the difference between the use of ; and executing a script

Related Question