217

I think I understand the differences between an interactive, a login and a batch shell. See the following links for more help:

My question is, how can I test with a command/condition if I am on an interactive, a login or a batch shell?

I am looking for a command or condition (that returns true or false) and that I could also place in an if statement. For example:

if [[ condition ]]
   echo "This is a login shell"
fi
1
  • 4
    There is yet another question: Are STDIN and/or STDOUT connected to a tty (terminal) or a pipe (file or process)? This is a related but distinct test as described in some of the below comments. Oct 10, 2014 at 18:04

11 Answers 11

259

I'm assuming a bash shell, or similar, since there is no shell listed in the tags.

To check if you are in an interactive shell:

[[ $- == *i* ]] && echo 'Interactive' || echo 'Not interactive'

To check if you are in a login shell:

shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'

By "batch", I assume you mean "not interactive", so the check for an interactive shell should suffice.

13
  • 28
    For zsh users, checking for a login shell can be done with: if [[ -o login ]] ...
    – chb
    Jun 27, 2013 at 5:05
  • 1
    If you want to know if a "user" ran your program versus "cron". [[ TERM=="dumb" ]] && echo "Running in cron. Dec 3, 2013 at 17:49
  • 13
    @ErikAronesty Not all dumb terminals are cron sessions.
    – Chris Down
    Dec 4, 2013 at 22:11
  • 6
    Also for zsh users, to check for interactive sessions: [[ -o interactive ]] Aug 10, 2015 at 16:50
  • 4
    “I'm assuming a bash shell, or similar, since there is no shell listed in the tags.” – The logic of this statement is truly beautiful! :) Dec 14, 2015 at 8:44
55

In any Bourne-style shell, the i option indicates whether the shell is interactive:

case $- in
  *i*) echo "This shell is interactive";;
  *) echo "This is a script";;
esac

There's no portable and fully reliable way to test for a login shell. Ksh and zsh add l to $-. Bash sets the login_shell option, which you can query with shopt -q login_shell. Portably, test whether $0 starts with a -: shells normally know that they're login shells because the caller added a - prefix to argument zero (normally the name or path of the executable). This fails to detect shell-specific ways of invoking a login shell (e.g. ash -l).

4
  • (...) because the caller – I think there's something missing in this fragment. Jul 20, 2015 at 12:22
  • It would be ideal if $0 always starts with a - no matter how it was started. But there is at least one exception: This is not always true with bash even if it is supposed to be a login shell. Try it in your box: invoke bash --login, then $0 still reads bash. Oct 16, 2015 at 20:35
  • 1
    @WirawanPurwanto I'm not sure I understand your comment. Isn't that what I wrote in my last sentence? Oct 18, 2015 at 19:19
  • @Gilles: You are correct. Sorry I missed your last sentence. Oct 20, 2015 at 17:58
27

fish shell

Here's the answer for fish in case any other users stumble upon this page.

if status --is-interactive
    # fish is interactive - that is, connected to a keyboard.
    # do stuff...
end

if status --is-login
    # fish is a login shell - that is, should perform login tasks such  as  setting  up PATH
    # do stuff...
end

echo "darn, I really wanted to have to use globs or at least a case statement"

fish docs ref

2
  • 5
    -1 for unnecessary editorializing. Aug 20, 2015 at 17:22
  • 13
    If anyone wonders at @NickBastin's comment, he had a fair point so I made an edit. The original amount of snarkiness has now been cut in half.
    – ohspite
    Aug 21, 2015 at 3:56
21

csh / tcsh

For csh and tcsh I have the following in my .cshrc file:

if($?prompt) then               # Only interactive shells set $prompt
    ...
endif

Specifically for tcsh, the variable loginsh is set for a login shell:

if($?loginsh) then              # A login shell..
    ...
endif

(tcsh also has a variable shlvl which is set to the number of nested shells, where the login shell has a value of 1.)

3
  • 2
    PS1 does not work to test for an interactive shell. It's almost always set in an interactive, but you can unset it. It's very often set in a noninteractive shell, because many systems ship with export PS in /etc/profile. Dec 14, 2011 at 11:35
  • @Gilles Thank you for the correction and edit Dec 14, 2011 at 15:26
  • This is Gold : tcsh also has a variable shlvl which is set to the number of nested shells, where the login shell has a value of 1.
    – Israr
    Oct 28, 2019 at 23:01
20

Another way is to check the result of tty

if [ "`tty`" != "not a tty" ]; then
9
  • 15
    ... or use [ -t 0 ] to test if STDIN is a tty. You can also use 1 (STDOUT) or 2 (STDERR) depending on your needs.
    – derobert
    Dec 13, 2011 at 23:17
  • 1
    @derobert - thanks for showing me something new Dec 14, 2011 at 3:12
  • 14
    This is a different test. It is possible to have a noninteractive shell whose input is a terminal (anytime you run a script in a terminal!), and it is possible (albeit rare) to have an interactive shell taking input not from a terminal. Dec 14, 2011 at 11:34
  • 1
    @Gilles if the shell was interactive, and closed leaving a child disown and alive, tty worked best to know it is not interactive anymore, while $- did not change; I am still puzzled about what is the best approach. Jul 25, 2014 at 6:14
  • 8
    @AquariusPower Then what you want to test is not for an interactive shell, but whether standard input is a terminal. Use [ -t 0 ]. P.S. In my previous comment, I wrote that “there's a strong correlation” — I forgot “apart from the extremely common case of a script started with #!/bin/sh or the like”, which is non-interactive but can be connected to a terminal. Jul 25, 2014 at 7:55
17

for Zsh

# Checking Interactive v.s. Non-Interactive
[[ -o interactive ]] && echo "Interactive" || echo "Non-Interactive"
#
# Checking Login v.s. Non-Login
[[ -o login ]] && echo "Login" || echo "Non-Login"

Ref: 2.1.1: What is a login shell? Simple tests

15

UNIX/Linux has a command to check if you are on a terminal.

if tty -s
then
echo Terminal
else
echo Not on a terminal
fi
1
  • 1
    This works in dash also.
    – Ken Sharp
    Nov 30, 2017 at 12:27
14

You can check to see if stdin is a terminal:

if [ -t 0 ]
then
    echo "Hit enter"
    read ans
fi
5

i is not the correct option to look for. -i is to force an otherwise non-interactive shell to become interactive. The correct auto-enabled option is -s, but Bash unfortunately does not handle this correctly.

You need to check whether $- contains s (this is granted to be auto-activated) or whether it contains i (this is not granted to be auto-activated but officially only coupled to the -i command line option of the shell).

12
  • 1
    s would be if the shell reads commands from stdin, not whether it's interactive. An interactive shell does not necessarily read commands from stdin (try zsh -i < /dev/null, though zsh seems to be the exception here). And a shell may be reading commands from stdin and not be interactive (like sh < file or echo 'echo "$1"' | sh -s foo bar). Aug 18, 2015 at 13:59
  • 2
    What I wanted to point out is that the original Bourne Shell does not have 'i' in $-, even when it is intended to be interactive.
    – schily
    Aug 18, 2015 at 14:07
  • 1
    OK, but on U&L, "shell" tend to refer to modern shells. The Bourne shell is generally considered a relique and your own variant is not mainstream enough to expect people to know what you're talking about unless you make it explicit. The question mentioned [[...]] which implies ksh/bash/zsh. You've got a point as a history note that checking for i in $- won't work in the Bourne shell. But then checking for s won't work there reliably either. You'd want to also check for [ -t 0 ] or i; even then that'd be fooled in corner cases like echo 'exec < /dev/tty; that-check' | sh' Aug 18, 2015 at 14:24
  • Solaris up to Solaris 10 come with the original Bourne Shell and even sill includes aprox. 10 bugs known to be in the shell since SVr4. So adding a hint on the Bourne Shell is not hat deviously as you might belive. zsh on the other side is not sufficient compatible, it e.g. fails when you try to run "configure" with zsh, so beware to set up /bin/sh to point to zsh. BTW: my Bourne Shell sets -i by default in case it decides to be interactive.
    – schily
    Aug 18, 2015 at 14:30
  • 3
    I notice POSIX doesn't seem to require $- contain i (which it seems to require s), I'll raise the question on the austin-group ML. Aug 18, 2015 at 15:09
3

To check whether a script runs in an interactive or non-interactive shell, I check in my scripts for the presence of a prompt stored in the $PS1 variable:

if [ -z $PS1 ] # no prompt?
### if [ -v PS1 ]   # On Bash 4.2+ ...
then
  # non-interactive
  ...
else
  # interactive
  ...
fi

This I learned here: https://www.tldp.org/LDP/abs/html/intandnonint.html

0

Curiously, scripts launched off the desktop in MacOS have the same environment as those started by hand. (They have their stdin as a teletype tty, they have their login_shell shopt unset and their "$-" as ehxB)

If my preferred way of bringing a script to the desktop is to create a symlink from ~/Desktop to the script, I can only guess that it was launched with a click by checking if "$0" is an absolute path (i.e. starts with a slash).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .