[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why two separate option namespaces?
From: |
Martijn Dekker |
Subject: |
Re: Why two separate option namespaces? |
Date: |
Mon, 27 Feb 2017 17:50:17 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 |
Op 27-02-17 om 15:32 schreef Chet Ramey:
> 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.
But why not? What's the advantage to users in creating a separate
category of options, seemingly based on no distinction in particular?
> 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.
So basically you're saying that, for options without a single-letter
equivalent, "-o" options are those that are either POSIX or that you
think should be POSIX? But then that distinction is more political than
technical, isn't it?
>> 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'.
That changes nothing, though. From a user's perspective, there are still
two arbitrarily separated categories of long-name options and you still
have to remember which option to set in which way.
- M.