2017-02-27 16:18:46 -0500, Chet Ramey:
> On 2/27/17 11:50 AM, Martijn Dekker wrote:
>
> > 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 polit
On 2/27/17 11:50 AM, Martijn Dekker wrote:
> 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?
Heh. Let's just
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 bas
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 re
Sounds like a useful proposal with little (no?) downsides..!
Peter
On 27/02/2560 13:08, 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.
>
> It might make sense if 'set -o' is for POSIX options o
It is not clear to me why bash has two separate namespaces for
long-named shell options, handled by two separate commands.
It might make sense if 'set -o' is for POSIX options only and 'shopt'
for bash-specific options, but that doesn't apply. I can't figure out a
consistent basis for a distinctio
