[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why two separate option namespaces?

From: Chet Ramey
Subject: Re: Why two separate option namespaces?
Date: Mon, 27 Feb 2017 09:32:38 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

On 2/27/17 1:08 AM, Martijn Dekker wrote:
> It is not clear to me why bash has two separate namespaces for
> long-named shell options, handled by two separate commands.

This has come up before.

When I added `shopt' in bash-2.0 (1996), I was primarily interested in
adding a unified interface to replace the set of special shell variables
that modified behavior just by being set, not set to any particular
value.  At the time, there were already some bash-specfic additions to
`set -o' (braceexpand/histexpand/posix), but I wasn't interested in
adding twenty more. I was also interested in adding some functionality
that wasn't available with set (`shopt -q') and making the syntax more
consistent with other builtins (no more `set +o' to disable an option).

Since the initial shopt implementation, I have added set -o options to
correspond to existing single-letter options (-E/-T for the debugger), that
Posix requires (nolog) or options that we hoped Posix would adopt as
standard (history/pipefail).  Other new functionality goes into shopt.

> Since there currently are no naming conflicts between the two
> namespaces, would there be any disadvantage to simply merging them and
> allowing all options to be manipulated using either set or shopt?

shopt already does this. You can manipulate all of the `set -o' options
with `shopt -o'.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]