Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In another question it was suggest that I use

shopt -s extglob

To fix a problem. I get the impression that these type commands are to be used sparingly, perhaps because they can have ill effects with other scripts. Can anyone speak to this?

share|improve this question
I can't imagine it would cause any problems: the extglob syntax would produce an error if that option is off. – glenn jackman Dec 3 '12 at 2:01
Switching it on globally might break the occasional script... If you use it within a script (and the script is run, not sourced), the setting only affects that shell. – Gert van den Berg Dec 3 '12 at 6:31
up vote 1 down vote accepted

shopt only affects the behavior of the shell that that command is run in. If you put it in ~/.bashrc then, it will affect non-login interactive shells and commands run over rsh/ssh (login shells may also be affected if ~/.bashrc is sourced in ~/.profile or ~/.bash_profile).

Setting the environment variable BASHOPTS to extglob will affect all interactive or non-interactive bash shells started while that environment variable is set (unless they're called as sh).

Interactive shells are where you want to have extglob set because that's where you want to use it, so ~/.bashrc is a good place to put it to benefit from it in every interactive shell. If you want to use it in a script, just add it at the start of the script.

The only place where that could cause problem is when it is set while some code that you didn't write doesn't expect it to be set. That could be for instance scripts that you source at the prompt or in ~/.bashrc after you've set the option.

While that is true for some options, it is not for extglob as it was carefully designed (by David Korn as that comes from ksh) so as not to break backward compatibility with the Bourne shell (and explains why the syntax is so awkward).

Basically, anything using extended globs would be a syntax error in the Bourne shell or in the POSIX shell syntax. If a Bourne or POSIX script had echo @(a), it would be broken (because of the unquoted parenthesis). It wouldn't matter if all of a sudden it started to output "a" instead of an error message.

Why bash doesn't enable it by default is not clear to me, given that bash doesn't have any other alternative extended glob syntax of its own like zsh does.

EDIT. While David Korn tried hard not to break Bourne/POSIX compatibility, it looks like bash wasn't so careful and is probably why it's not enabled by default like in ksh.

In ksh (and zsh in ksh emulation), the extended globbing operators are disabled when performing globbing upon parameter or command substitution:

$ touch a
$ a='@(a)' ksh93 -c 'echo $a'

While in bash, it's not the case:

$ a='@(a)' BASHOPTS=extglob bash -c 'echo $a'
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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