49

I am writing a POSIX shell script that may or may not receive input from stdin as in foo.sh < test.txt, non-interactively.

How do I check whether there is anything on stdin, to avoid halting on while read -r line...?

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
l0b0
  • 55,365
  • 30
  • 138
  • 223

4 Answers4

83

If I get the question right, you may try the following:

#!/bin/sh
if [ -t 0 ]; then
    echo running interactivelly
else
    while read -r line ; do
        echo $line
    done
fi
dmedvinsky
  • 8,046
  • 3
  • 31
  • 25
  • Just a heads up, this is triggered for stdin and when your capturing stdout. (both run interactivelly) ./yourscript < ./the_input_your_giving_your_script.txt && ./yourscript > ./what_your_script_outputs.txt – DebugXYZ Jun 29 '14 at 05:23
  • 4
    @DeShawnWilliams No, @dmedvinsky's answer is correct: `test -t n` is true if the file descriptor `n` is opened on a terminal, thus `test -t 0` only checks for stdin, and `test -t 1` only checks for stdout. – bootleg May 22 '15 at 07:55
  • Any idea why `echo hello | interactive` and `interactive <(echo world)` produce different outputs (in zsh)? (`interactive` just returns 'yes' or 'no'.) I see that `interactive <<<"goodnight"` and `interactive – John P Jan 07 '19 at 05:46
  • 1
    Oh, er, that's not working the way I remembered. `<(command)` is still an argument, it's just replaced by the file descriptor of the stdout of `command`. – John P Jan 07 '19 at 05:50
8

To answer the question literally (but not what you actually want): read -t 0

Timeout, zero seconds.

  1. this is a race-condition, depending on when the left-hand-side is ready to provide data. You can specify -t 5 but on a thrashing system even that is problematic.
  2. read -t is not standardised in SUSv3. It is in BSD sh, bash, zsh. It's not in ksh or dash.

So you can't just use #!/bin/sh and expect to have this.

The basic problem is that even if there's nothing on stdin now, that doesn't mean there won't be soon. Invoking a program normally leaves stdin connected to the terminal/whatever, so there's no way to tell what's needed.

So, to answer your question literally, you can do it, but in practice your options are:

  1. test if stdin is a tty: [ -t 0 ]
  2. use argv to control behaviour
Phil P
  • 792
  • 5
  • 10
  • 1
    I just experimented with this using zsh. I noticed that `read -t` or equivalently `read -t0` have **nondeterministic** behavior. So as you mentioned already, avoid using it. – Tarrasch Jan 01 '13 at 18:25
  • 2
    But, that's to be distinguished from the _test_ `-t` used in the answer. – erik258 Nov 20 '14 at 00:21
7

You can easily implement a similar behaviour as the "cat" command, that is read from a list of provided files or if they're not provided, then read from the stdin.

Although you may not use this idea, I think this Linux Journal article will be interesting for you http://www.linuxjournal.com/content/determine-if-shell-input-coming-terminal-or-pipe

:-)

darkturo
  • 124
  • 3
1

If you never want to run the script interactively, make it take the input file as a parameter, rather than using stdin. Some programs use a flag or a special filename to indicate that they should take input from standard input rather than from a file; that case lets you handle command line jockeying if necessary.

If you want your script to take the standard input, why don't you want to let it be interactive (or at least behave like other POSIX tools)?

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • 5
    A common way to tell programs to read from stdin instead of a file is to provide `-` instead of a filename. – Cascabel Mar 16 '10 at 18:07