How could I know inside a script if stdout has been redirected for it?

Question

I have a script in ksh; depending whether there is a redirection from the command line, I redirect the output via a exec 1>file. How can I test from inside the script itself if the command calling it has redirected its output?

I tried using $@, $*, $0, and even a ps on the PID of the script (hopefully there is a shebang) but the redirection never appears.

The script is running on AIX in this case.

Answer 1

On AIX, the stdout file descriptor is available at /proc/$$/fd/1, so you could test it for being a regular file or not:

if [ -f "/proc/$$/fd/1" ]
then
  echo stdout has already been redirected
else
  echo redirecting stdout
  exec 1>file
  echo some output
fi

/bin/sh is hardlinked to /bin/ksh, so you get the same behavior in either shell.

You could test separately for stdout having been redirected to /dev/null, if you wanted:

if [ "/proc/$$/fd/1" -ef /dev/null ]; then : ...; fi

Answer 2

In general, you can't. Redirections don't appear as arguments to the running command. Even if they did, you wouldn't be able to tell where the script output goes in all cases. Consider these two:

bash -c 'somecmd > /dev/null; othercmd'

and

bash -c 'somecmd; othercmd'  > /dev/null

In the first case, the output of somecmd is redirected to /dev/null, but in the second case, the output of the whole shell is redirected, including both somecmd and othercmd. Seeing the command line of somecmd in the second case wouldn't tell how the output is redirected.

That said, it appears Bash's DEBUG trap can be used for this.

$ trap 'export CMDLINE=$BASH_COMMAND' DEBUG
$ env 2>/dev/null |grep CMD
CMDLINE=env 2> /dev/null

The trap exports the command to be run as CMDLINE, which we can see is exported since it shows in the output of env. Note that the full pipeline is not shown, just the one command.

---

That said, in most cases there are better ways to deal with things than trying to second-guess the user's redirections. Many commands check if the output goes to a terminal and change their behavior based on that.

To check if stdout is a terminal, you can use [ -t 1 ]:

$ if [ -t 1 ]; then echo terminal; else echo not terminal; fi  |cat
not terminal

This is most often used to disable some interactive functionality or extraneous output in case the output doesn't go to a terminal and hence, by assumption, to a user.

---

If just testing if a file descriptor points to a terminal isn't enough, it might be easiest to arrange to pass an additional argument to the program to tell it what mode to operate in. That is, instead of caring about redirections, have the program do one thing if started with someprog --mode=cron, another if started with someprog --mode=batch and run interactively if started without a --mode argument. (Make interactive or command line mode the default so that the user doesn't need to manually type --mode=commandline each time they run it by hand.)

Answer 3

In my testing, on Linux (Debian 10.12) with Bash 5 (GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)), you can use the [ -p test.

• Consider a script test.sh

  #!/bin/bash
  ls -lah /proc/$$/fd/1
  if [ -p "/proc/$$/fd/1" ]; then echo "pipe"; else echo "nopipe"; fi
  exec 1> >( cat ) 2>&1
  ls -lah /proc/$$/fd/1
  if [ -p "/proc/$$/fd/1" ]; then echo "pipe"; else echo "nopipe"; fi
  

• Execute the script without and with redirection:

  $ ./test.sh
  lrwx------ 1 [...] /proc/123/fd/1 -> /dev/pts/2
  nopipe
  l-wx------ 1 [...] /proc/123/fd/1 -> pipe:[12345]
  pipe
  $ ./test.sh | cat
  l-wx------ 1 [...] /proc/124/fd/1 -> pipe:[12346]
  pipe
  l-wx------ 1 [...] /proc/124/fd/1 -> pipe:[12347]
  pipe