set and shopt are both shell builtins that control various options. I often forget which options are set by which command, and occasionally which option sets/unsets (set +o/-o, shopt -s/-u). Why are there two different commands that seemingly do the same thing (and have different arguments to do so)? Is there any easy way/mnemonic to remember which options go with which command?

  • 6
    Try looking at the second line of help set and help shopt to verify that even their authors think they do the same thing. – l0b0 Feb 22 '12 at 16:28
  • 1
    "Change the value of shell attributes" vs "Change the setting of each shell option". – Kevin Feb 22 '12 at 16:30
  • 1
    In Bash 4.1.5(1)-release it says "Set or unset values of shell options and positional parameters." and "Set and unset shell options.", respectively. – l0b0 Feb 22 '12 at 16:33
up vote 34 down vote accepted

As far as I know, the set -o options are the ones that are inherited from other Bourne-style shells (mostly ksh), and the shopt options are the ones that are specific to bash. There's no logic that I know of.

  • 1
    Any documentation which shows shopt is inherited ? – Felipe Alvarez Jul 3 '15 at 1:13
  • 4
    Well, there are set -o options like posix/physical/interactive-comments that are not in ksh, and shopt ones that are in other shells including ksh for some like login_shell/nullglob. Like you say, there's no logic. It was probably the idea at the start (that SHELLOPTS would be the standard ones, and BASHOPTS the bash specific ones), but that got lost along the way, and now it just ends up being annoying and a UI design fiasco. – Stéphane Chazelas Jan 25 at 13:05

The difference is in the changed environment variable used by bash. Setting with the set command results in $SHELLOPTS. Setting with the shopt command results in $BASHOPTS.

  • 4
    Ugh! That is even more confusing. My brain wants to associate shopt with $ SHELLOPTS rather than $ BASHOPTS. – Bruno Bronosky Mar 22 '16 at 16:17

Easy but lost in history. The set command was originally used to modify the command line environment of the original unix shells /bin/sh. Then as various Unix versions evolved, and new shell flavors was added, people realized that they needed to be able to change more (environment) things in order to keep shell scripting compatible. At that time Bash got very popular and the additional shell options was needed, introducing shopt.

You can actually see these compatibility attempts in the shopt command.

$ shopt
autocd          off
cdable_vars     off
cdspell         off
checkhash       off
checkjobs       off
checkwinsize    off
cmdhist         on
compat31        off
compat32        off
compat40        off
compat41        off
compat42        off
complete_fullquote      on
direxpand       off
dirspell        off
dotglob         off
execfail        off
expand_aliases  on
extdebug        off
extglob         off
extquote        on
failglob        off
force_fignore   on
globstar        off
globasciiranges off
gnu_errfmt      off
histappend      on
histreedit      off
histverify      off
hostcomplete    on
huponexit       off
interactive_comments    on
lastpipe        off
lithist         off
login_shell     on
mailwarn        off
no_empty_cmd_completion off
nocaseglob      on
nocasematch     off
nullglob        off
progcomp        on
promptvars      on
restricted_shell        off
shift_verbose   off
sourcepath      on
xpg_echo        off

But not in the set command.

$ set -o
allexport       off
braceexpand     on
emacs           on
errexit         off
errtrace        off
functrace       off
hashall         on
histexpand      on
history         on
igncr           off
ignoreeof       off
interactive-comments    on
keyword         off
monitor         on
noclobber       off
noexec          off
noglob          off
nolog           off
notify          off
nounset         off
onecmd          off
physical        off
pipefail        off
posix           off
privileged      off
verbose         off
vi              off
xtrace          off
  • 2
    set as a way to set options wasn't in the original Unix shells, it was introduced by the Bourne shell in the late 70s. set -o name itself was added later by the Korn shell, specified but optional in POSIX, still not supported by "modern" versions of the Bourne shell like the /bin/sh of Solaris 10. – Stéphane Chazelas Aug 23 '16 at 14:00

It looks like "set" options are inherited by subshells and shopts are not.

  • Nice catch. I wonder whether this is an intentional choice or a side-effect. – Kevin Jan 5 '13 at 19:09
  • 1
    @user29778 At least under bash 4.1.5(1) the options set with set are not inherited by subshells.Both set and shopt options are not inherited by subshells. – Martin May 7 '13 at 22:13
  • Can you point to the documentation that describes the inheritance characteristics of both set and shopt ? – Felipe Alvarez Jul 3 '15 at 1:12
  • 5
    Both set -o and shopt options are inherited by subshells ((...), $(...), pipeline components). Whether they are inherited by other bash invocations depends on whether SHELLOPTS or BASHOPTS are in the environment or not. – Stéphane Chazelas Aug 23 '16 at 13:47

From the book "Linux Shell Scripting with Bash", p 63:

Historically, the set command was used to turn options on and off. As the number of options grew, set became more difficult to use because options are represented by single letter codes. As a result, Bash provides the shopt (shell option) command to turn options on and off by name instead of a letter. You can set certain options only by letter. Others are available only under the shopt command. This makes finding and setting a particular option a confusing task.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.