Home ›

Determine If Shell Input is Coming From the Terminal or From a Pipe

Feb 10, 2010  By Mitch Frazier
 in

Working on a little script the other day I had the need to determine if the input to the script was coming from a pipe or from the terminal. Seems like a simple enough thing to determine but nothing jumped immediately to mind and a quick internet search didn't help much either. After a bit of pondering I came up with two solutions: the stat command and using information from the proc file system.

The first solution uses the stat command to determine what type of file is connected to standard input. First we find out what is connected to standard input:

stdin="$(ls -l /dev/fd/0)"
stdin="${stdin/*-> /}"

The file /dev/fd/0 is the standard input, which is a symbolic link. So we use ls to get the file it's linked to. Then we remove everything that matches *-> from the front of the value, that leaves us with the linked to file.

Now we use stat to get the file type:

ftype="$(stat --printf=%F $stdin)"

Then we just test the file type:

if   [[ "$ftype" == 'character special file' ]]; then
    echo Terminal
elif [[ "$ftype" == 'regular file' ]]; then
    echo Pipe: $stdin
else
    echo Unknown: $stdin
fi

We can test it via:

$ sh ckpipe.sh
Terminal
$ sh ckpipe.sh <ckpipe.sh
Pipe: .../ckpipe/ckpipe.sh

The next solution I came up with involves using information from the proc file system. In the proc file system the files for each process appear in the directory /proc/PROCESS_ID/fd (for the current process the special directory /proc/self/fd can be used):

$ ls -la /proc/self/fd
total 0
dr-x------ 2 mitch users  0 2010-02-10 11:04 .
dr-xr-xr-x 7 mitch users  0 2010-02-10 11:04 ..
lrwx------ 1 mitch users 64 2010-02-10 11:04 0 -> /dev/pts/2
lrwx------ 1 mitch users 64 2010-02-10 11:04 1 -> /dev/pts/2
lrwx------ 1 mitch users 64 2010-02-10 11:04 2 -> /dev/pts/2
lr-x------ 1 mitch users 64 2010-02-10 11:04 3 -> /proc/29328/fd

As before we need the name of file that is linked to, so we get that with:

stdin="$(ls -l /proc/self/fd/0)"
stdin="${stdin/*-> /}"

From there we can just test to see if it's linked to a /dev/pts file:

if [[ "$stdin" =~ ^/dev/pts/[0-9] ]]; then
    echo Terminal
else
    echo Pipe: $stdin
fi

We test this the same way:

$ sh ckpipe2.sh
Terminal
$ sh ckpipe2.sh <ckpipe2.sh
Pipe: .../ckpipe/ckpipe2.sh
AttachmentSize
ckpipe_sh.txt263 bytes
ckpipe2_sh.txt156 bytes
______________________

Mitch Frazier is an Associate Editor for Linux Journal.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

-t / isatty / ioctl

Anonymous's picture
Submitted by Anonymous on Fri, 05/07/2010 - 12:00.

I have had the same problem recently and had to implement it in C too -- the solution: isatty

I found out that -t and isatty uses an ioctl to achieve the result, which led me to the following C solution:

#include 
#include 
#include 
#include 

#define STDIO 0

int main()
{
  struct termios NewTermios;

  if (isatty(STDIO))
    printf("Input from a terminal (according to isatty)\n");
  else
    printf("Input NOT from a terminal (according to isatty)\n");
  if (ioctl(STDIO, TCGETS, &NewTermios) == 0)
    printf("Input from a terminal (according to ioctl)\n");
  else
    printf("Input NOT from a terminal (according to ioctl)\n");
}

Really nice post

Pedro Oliveira's picture
Submitted by Pedro Oliveira (not verified) on Tue, 02/23/2010 - 07:25.

I really enjoyed this one, not only because it's a useful thing but makes you remind you how you can play with bash (and Linux) as a Lego.
Apart from the original post the comments are neat too :)
Long live to the community.

Actually both solutions are the same

Aog2000a's picture
Submitted by Aog2000a (not verified) on Sun, 02/14/2010 - 08:43.

$ ls -l /dev/fd
lrwxrwxrwx 1 root root 13 2010-02-12 14:33 /dev/fd -> /proc/self/fd

/dev/fd is just a symlink to /proc/self/fd

tty detection in one line

Anonymous's picture
Submitted by Anonymous (not verified) on Sat, 02/13/2010 - 07:19.

tty -s && echo "Yes, we are on a tty! zomg Ponies!" || echo "Nope, we're not on a tty and it's cool."

I use something like this to detect whether I'm on a tty. Not useful for pipe detection, but hey.

L8N buglet in your first solution

Santi's picture
Submitted by Santi (not verified) on Sat, 02/13/2010 - 06:40.

The stat command (or tty) will localise its output and fail unless the local is a suitable en one, so you need to prefix it with something like: LC_ALL=C. Bad enough, but typical in shell programming... :(

/dev/pts is good only for remote shells or shells in X11 windows

Anonymous's picture
Submitted by Anonymous (not verified) on Sat, 02/13/2010 - 05:19.

> if [[ "$stdin" =~ ^/dev/pts/[0-9] ]]; then
> echo Terminal
> else
> echo Pipe: $stdin
> fi

The above will not work for shell sessions on (local) virtual consoles.

HI

Olivia Spensor's picture
Submitted by Olivia Spensor (not verified) on Sat, 02/13/2010 - 01:49.

Well It is not so simple as it's seems to be.I think before reading this post many people must have been unaware from this so you have helped them by providing this quite cool info to them.

"So we use ls to get the file it's linked to"

Jeff Pohlmeyer's picture
Submitted by Jeff Pohlmeyer (not verified) on Thu, 02/11/2010 - 20:22.

I agree the "tty" command might be the better solution here, but with regard to the general situation of following a symbolic link:

> stdin="$(ls -l /dev/fd/0)"
> stdin="${stdin/*-> /}"

That looks ugly to me.

how about:

stdin="$(readlink -f /dev/fd/0)"

BTW, this also seems to work:

case "$(stat -L -c %t /dev/fd/0)" in
0)
  echo "pipe" 
  ;;
88)
  echo "stdin"
  ;;
*)
  echo "unknown"
  ;;
esac

- Jeff

Readlink

Mitch Frazier's picture
Submitted by Mitch Frazier on Thu, 02/11/2010 - 20:31.

Agreed, readlink is better.

Mitch Frazier is an Associate Editor for Linux Journal.

This reminds me of perl (tmtowdi) ...

Derek's picture
Submitted by Derek (not verified) on Thu, 02/11/2010 - 19:33.

This post and its comments remind me of that perl saying which I guess applies to the shell as well - there's more than one way to do it (TMTOWTDI) ...

regards

tty gets it done

Ronald Vazquez's picture
Submitted by Ronald Vazquez (not verified) on Thu, 02/11/2010 - 14:15.

Just like Jim Helm, I use tty to test for this. A quick and dirty function like:

am_I_on_a_terminal() {
        if [[ $(tty -s ; echo ${?}) == 0 ]] ; then
                ANSWER=1
            else
                ANSWER=0
        fi
        printf "%d" "${ANSWER}"
}

if [[ $(am_I_on_a_terminal) == 1 ]] ; then
        printf "%s\n" "I am on a terminal"
   else
        printf "%s\n" "I must be runnig from cron"
fi

exit 0

Can accomplish the task.

RV

Check $- to know if the shell is interactive

Yannick Le Saint's picture
Submitted by Yannick Le Saint (not verified) on Thu, 02/11/2010 - 10:46.

Depending on what you want to do, you can check if the character "i" is present in the special bash variable $-

if echo "$-" | grep -q i; then
echo "The shell is interactive"
else
echo "Non-interactive shell (closed stdin, file, pipe, ...)"
fi

two words

Jim Helm's picture
Submitted by Jim Helm (not verified) on Thu, 02/11/2010 - 00:56.

man tty

Thanks

Mitch Frazier's picture
Submitted by Mitch Frazier on Thu, 02/11/2010 - 09:40.

Another good way. The tty command returns "not a tty" when the input is coming from a pipe.

Mitch Frazier is an Associate Editor for Linux Journal.

Shell test

Luchostein's picture
Submitted by Luchostein (not verified) on Wed, 02/10/2010 - 14:00.

Did you try test -t /proc/self/fd/0 (or just [ -t /proc/self/fd/0 ])? We could define:

function isTTY() {
  local path="${1:-/proc/self/fd/0}"
  [ -t "$path" ]
}

test -t

Mitch Frazier's picture
Submitted by Mitch Frazier on Wed, 02/10/2010 - 14:21.

The -t option (which I just learned about from the comment below) tests a file-descriptor, not a file. So you can't do what you're suggesting, checking a path, you would need to determine the file-descriptor. In the case of stdin, you just use "0":

function isTTY() {
  local fd="${1:-0}"
  [ -t "$fd" ]
}

Mitch Frazier is an Associate Editor for Linux Journal.

What's wrong with -t?

Jack Repenning's picture
Submitted by Jack Repenning (not verified) on Wed, 02/10/2010 - 13:46.

Why wasn't the conditional expression "if [ -t 0 ] ; ..." (which is stat-based) sufficient?

> if [ -t 0 ] ; then echo terminal; else echo not; fi
terminal

> if [ -t 0 ] ; then echo terminal; else echo not; fi < /dev/null
not

> echo hi | if [ -t 0 ] ; then echo terminal; else echo not; fi
not

-t refined

Jaime Fernández's picture
Submitted by Jaime Fernández (not verified) on Wed, 02/10/2010 - 14:33.

According to this reference:
http://tldp.org/LDP/abs/html/intandnonint.html
it proposes:

if [[ -t "$fd" || -S /dev/stdin ]]
then
echo interactive
else
echo non-interactive
fi

so that it's valid even when you are connected via ssh.

Nothing

Mitch Frazier's picture
Submitted by Mitch Frazier on Wed, 02/10/2010 - 13:50.

Nothing's wrong with that, I just wasn't aware of it. Like I said it seemed like it ought to be simple and it would have been had I known about that.

Mitch Frazier is an Associate Editor for Linux Journal.

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions