adding support for standard extensions to the shell language

[Richard Hansen]

Hi all,

Like many others, I have long wanted to add new features to the shell
language such as arrays, local variables (bugs 465 and 767), and
additional parameter expansions. I recognize the perils in doing so:
They run the risk of breaking compatibility with existing scripts, not
every shell has implemented or wants to implement these features, and
those that have might have subtle but important incompatibilities.

With that in mind, I want to figure out a way to make forward progress.

I'd like to know what you think about the following proposal:

* For features that break backward compatibility with Issue 7, or for
backward-compatible features where toggling on or off makes sense,
reserve the posix_* prefix in the 'set' option namespace. For
example, 'set -o posix_local' could enable support for local
variables inside functions (in a to-be-specified manner). The
default would always be the backward-compatible setting. Testing
whether an implementation supports a particular feature can be done
by attempting to turn the feature on; if unsupported, 'set' will
return non-zero.

* For features that do not break backward compatibility with Issue 7
and that do not need to be toggled on or off, provide a way to test
whether the shell implements the feature. For example, 'set -o
posix_arrays' could return zero if arrays are supported and
non-zero otherwise (but the command would not change any state; if
arrays are supported, a plain 'set +o' or 'set -o' would either not
show posix_arrays or always show posix_arrays as enabled).

With the above mechanisms in place, we could add a non-normative future
directions section for each feature we want to add. A section would
graduate to normative (but still optional) once the kinks have been
ironed out and some existing shells have implemented the feature.

We could add meta-features to turn on a collection of independent
features that have graduated to normative, e.g., 'set -o posix_issue8'.

Thoughts?

Thanks,
Richard

[Jilles Tjoelker]

Post by Richard Hansen
Like many others, I have long wanted to add new features to the shell
language such as arrays, local variables (bugs 465 and 767), and
They run the risk of breaking compatibility with existing scripts, not
every shell has implemented or wants to implement these features, and
those that have might have subtle but important incompatibilities.
With that in mind, I want to figure out a way to make forward progress.
* For features that break backward compatibility with Issue 7, or for
backward-compatible features where toggling on or off makes sense,
reserve the posix_* prefix in the 'set' option namespace. For
example, 'set -o posix_local' could enable support for local
variables inside functions (in a to-be-specified manner). The
default would always be the backward-compatible setting. Testing
whether an implementation supports a particular feature can be done
by attempting to turn the feature on; if unsupported, 'set' will
return non-zero.

Since 'set' acts when it is executed, plainly using it as the first
non-comment line of a script does not precede parsing the rest of the
script in all cases (-n, dot scripts in ksh). Therefore, the new
features cannot change the parsing incompatibly (the parsing additions
would always be enabled).

In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o
option is a utility syntax error per XCU 2.8.1 which causes the shell to
abort. I think that prepending 'command' should leave the shell running
but mksh aborts anyway, forcing a slow subshell to test for features.

If changing the parser is desired, a parser directive based on keywords
and/or operator characters would be necessary instead. Such a directive
would not allow testing for features without using . or eval, however.

Post by Richard Hansen
* For features that do not break backward compatibility with Issue 7
and that do not need to be toggled on or off, provide a way to test
whether the shell implements the feature. For example, 'set -o
posix_arrays' could return zero if arrays are supported and
non-zero otherwise (but the command would not change any state; if
arrays are supported, a plain 'set +o' or 'set -o' would either not
show posix_arrays or always show posix_arrays as enabled).

Hmm, so in that example 'set +o posix_arrays' in a shell that supports
arrays would be an error?

Post by Richard Hansen
With the above mechanisms in place, we could add a non-normative future
directions section for each feature we want to add. A section would
graduate to normative (but still optional) once the kinks have been
ironed out and some existing shells have implemented the feature.
We could add meta-features to turn on a collection of independent
features that have graduated to normative, e.g., 'set -o posix_issue8'.
Thoughts?

Directives like this would allow a theoretically proper upgrade path, as
is already offered for C code (though it is not used very often in
practice).

I'm not sure that most shell script writers will add the necessary
directives.

[Richard Hansen]

Post by Jilles Tjoelker

Post by Richard Hansen
* For features that break backward compatibility with Issue 7, or for
backward-compatible features where toggling on or off makes sense,
reserve the posix_* prefix in the 'set' option namespace. For
example, 'set -o posix_local' could enable support for local
variables inside functions (in a to-be-specified manner). The
default would always be the backward-compatible setting. Testing
whether an implementation supports a particular feature can be done
by attempting to turn the feature on; if unsupported, 'set' will
return non-zero.

Since 'set' acts when it is executed, plainly using it as the first
non-comment line of a script does not precede parsing the rest of the
script in all cases (-n, dot scripts in ksh).

True.

Post by Jilles Tjoelker
Therefore, the new
features cannot change the parsing incompatibly (the parsing additions
would always be enabled).

I'm not sure I understand. Even if a feature changes tokenization and
parsing, can't you disable the feature before executing legacy code?

Post by Jilles Tjoelker
In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o
option is a utility syntax error per XCU 2.8.1 which causes the shell to
abort.

Doh, you're right. As I read it, it would be a bug for an
implementation to *not* abort when given an unknown shell option.

Post by Jilles Tjoelker
I think that prepending 'command' should leave the shell running

This might be a suitable workaround for the above problem.

So to enable the local variable feature you'd do:

command set -o posix_local

Post by Jilles Tjoelker
but mksh aborts anyway, forcing a slow subshell to test for features.

I'm not sure how much this matters. This is an ordinary bug, right? It
should be fixed (if it hasn't already) regardless of whether this scheme
is employed. By the time a posix_* feature is specified and implemented
widely enough for a script author to want to use it, I would expect the
buggy mksh to be ancient history.

Post by Jilles Tjoelker
If changing the parser is desired, a parser directive based on keywords
and/or operator characters would be necessary instead. Such a directive
would not allow testing for features without using . or eval, however.

Post by Richard Hansen
* For features that do not break backward compatibility with Issue 7
and that do not need to be toggled on or off, provide a way to test
whether the shell implements the feature. For example, 'set -o
posix_arrays' could return zero if arrays are supported and
non-zero otherwise (but the command would not change any state; if
arrays are supported, a plain 'set +o' or 'set -o' would either not
show posix_arrays or always show posix_arrays as enabled).

Hmm, so in that example 'set +o posix_arrays' in a shell that supports
arrays would be an error?

A good question, though I don't think it matters much. I think my
preference would be to issue an error -- it's a feature that can't be
turned off.

Post by Jilles Tjoelker
I'm not sure that most shell script writers will add the necessary
directives.

For features that can't be turned off (e.g., posix_arrays) this wouldn't
matter. For features that aren't backward compatible (e.g.,
posix_local), the default would be disabled, thus requiring the script
writer to add the directive to use the feature.

Thank you for your comments,
Richard

[Shware Systems]

IMO this is better added as a 'feature exists' operator of "[[" that

complements the 'file exists' operator. What identifiers would be

valid then is arbitrary, as specific to that operator, so no name

space prefix reservations required.



-----Original Message-----

From: Jilles Tjoelker <jilles-***@public.gmane.org>

To: Richard Hansen <rhansen-A08e6c8yq/***@public.gmane.org>

Cc: austin-group-l <austin-group-l-7882/***@public.gmane.org>

Sent: Wed, Oct 8, 2014 5:30 pm

Subject: Re: adding support for standard extensions to the shell

language

Post by Richard Hansen
Like many others, I have long wanted to add new features to the shell
language such as arrays, local variables (bugs 465 and 767), and
They run the risk of breaking compatibility with existing scripts, not
every shell has implemented or wants to implement these features, and
those that have might have subtle but important incompatibilities.
With that in mind, I want to figure out a way to make forward

progress.

Post by Richard Hansen
* For features that break backward compatibility with Issue 7, or

for

Post by Richard Hansen
backward-compatible features where toggling on or off makes sense,
reserve the posix_* prefix in the 'set' option namespace. For
example, 'set -o posix_local' could enable support for local
variables inside functions (in a to-be-specified manner). The
default would always be the backward-compatible setting. Testing
whether an implementation supports a particular feature can be

done

Post by Richard Hansen
by attempting to turn the feature on; if unsupported, 'set' will
return non-zero.

Since 'set' acts when it is executed, plainly using it as the first

non-comment line of a script does not precede parsing the rest of the

script in all cases (-n, dot scripts in ksh). Therefore, the new

features cannot change the parsing incompatibly (the parsing additions

would always be enabled).



In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o

option is a utility syntax error per XCU 2.8.1 which causes the shell to

abort. I think that prepending 'command' should leave the shell running

but mksh aborts anyway, forcing a slow subshell to test for features.



If changing the parser is desired, a parser directive based on keywords

and/or operator characters would be necessary instead. Such a directive

would not allow testing for features without using . or eval, however.

Post by Richard Hansen
* For features that do not break backward compatibility with Issue 7
and that do not need to be toggled on or off, provide a way to

test

Post by Richard Hansen
whether the shell implements the feature. For example, 'set -o
posix_arrays' could return zero if arrays are supported and
non-zero otherwise (but the command would not change any state; if
arrays are supported, a plain 'set +o' or 'set -o' would either

not

Post by Richard Hansen
show posix_arrays or always show posix_arrays as enabled).

Hmm, so in that example 'set +o posix_arrays' in a shell that supports

arrays would be an error?

Post by Richard Hansen
With the above mechanisms in place, we could add a non-normative

future

Post by Richard Hansen
directions section for each feature we want to add. A section would
graduate to normative (but still optional) once the kinks have been
ironed out and some existing shells have implemented the feature.
We could add meta-features to turn on a collection of independent
features that have graduated to normative, e.g., 'set -o

posix_issue8'.

Post by Richard Hansen
Thoughts?

Directives like this would allow a theoretically proper upgrade path, as

is already offered for C code (though it is not used very often in

practice).



I'm not sure that most shell script writers will add the necessary

directives.



--

Jilles Tjoelker

[Dan Douglas]

Post by Jilles Tjoelker
In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o
option is a utility syntax error per XCU 2.8.1 which causes the shell to
abort. I think that prepending 'command' should leave the shell running
but mksh aborts anyway, forcing a slow subshell to test for features.

This is an issue I've been meaning to file a defect on or at least ask about
for a long time. I asked the maintainer over a year ago why the command
builtin fails to suppress fatal errors in special builtins, when it is clearly
documented in the ksh88 manual and implemented by every shell I have to test
with except for mksh. However after quite some searching neither of us were
able to find any language that unambiguously requires the command builtin to
have that feature. Hence, it wasn't fixed.

If this is true and not just my usual failure of interpreting the spec, then I
strongly think it needs to be addressed. The consequences are rather annoying
such as the small TOCTOU that must occur when the dot builtin may fail at
sourcing a file, or the possibility of calling shift when there are no
positional parameters -- either situation (and plenty more) that may force the
shell to exit in a way that can't be handled by the script.

[Geoff Clare]

Post by Dan Douglas

Post by Jilles Tjoelker
In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o
option is a utility syntax error per XCU 2.8.1 which causes the shell to
abort. I think that prepending 'command' should leave the shell running
but mksh aborts anyway, forcing a slow subshell to test for features.

This is an issue I've been meaning to file a defect on or at least ask about
for a long time. I asked the maintainer over a year ago why the command
builtin fails to suppress fatal errors in special builtins, when it is clearly
documented in the ksh88 manual and implemented by every shell I have to test
with except for mksh. However after quite some searching neither of us were
able to find any language that unambiguously requires the command builtin to
have that feature.

The 2nd paragraph of the DESCRIPTION section for "command" begins:

If the command_name is the same as the name of one of the special
built-in utilities, the special properties in the enumerated list
at the beginning of Section 2.14 (on page 2356) shall not occur.

Item 1 in the list it refers to begins:

A syntax error in a special built-in utility may cause a shell
executing that utility to abort, while a syntax error in a regular
built-in utility shall not cause a shell executing that utility to
abort.

Putting these two things together, the standard clearly requires
that in cases where a special built-in utility would abort the shell
due to a syntax error "in the utility" (i.e. in the use of the
utility but not in the shell language), prefixing with "command"
prevents the shell from aborting, and "set -o unknown_option" is
such a case.

[Dan Douglas]

Post by Geoff Clare

Post by Dan Douglas

Post by Jilles Tjoelker
In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o
option is a utility syntax error per XCU 2.8.1 which causes the shell to
abort. I think that prepending 'command' should leave the shell running
but mksh aborts anyway, forcing a slow subshell to test for features.

This is an issue I've been meaning to file a defect on or at least ask about
for a long time. I asked the maintainer over a year ago why the command
builtin fails to suppress fatal errors in special builtins, when it is clearly
documented in the ksh88 manual and implemented by every shell I have to test
with except for mksh. However after quite some searching neither of us were
able to find any language that unambiguously requires the command builtin to
have that feature.

If the command_name is the same as the name of one of the special
built-in utilities, the special properties in the enumerated list
at the beginning of Section 2.14 (on page 2356) shall not occur.
A syntax error in a special built-in utility may cause a shell
executing that utility to abort, while a syntax error in a regular
built-in utility shall not cause a shell executing that utility to
abort.
Putting these two things together, the standard clearly requires
that in cases where a special built-in utility would abort the shell
due to a syntax error "in the utility" (i.e. in the use of the
utility but not in the shell language), prefixing with "command"
prevents the shell from aborting, and "set -o unknown_option" is
such a case.

I'm pretty sure the "syntax error" terminology was in fact the biggest
source of confusion. My guess would have been that means either an
error during argument parsing or command evaluation issue prior to
invoking the builtin, when in fact it's nearly the opposite (any error
encountered by the command causing it to abort). Thank you for the
explanation.

[Mike Frysinger]

Post by Geoff Clare

Post by Dan Douglas

Post by Jilles Tjoelker
In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o
option is a utility syntax error per XCU 2.8.1 which causes the shell to
abort. I think that prepending 'command' should leave the shell running
but mksh aborts anyway, forcing a slow subshell to test for features.

This is an issue I've been meaning to file a defect on or at least ask about
for a long time. I asked the maintainer over a year ago why the command
builtin fails to suppress fatal errors in special builtins, when it is clearly
documented in the ksh88 manual and implemented by every shell I have to test
with except for mksh. However after quite some searching neither of us were
able to find any language that unambiguously requires the command builtin to
have that feature.

If the command_name is the same as the name of one of the special
built-in utilities, the special properties in the enumerated list
at the beginning of Section 2.14 (on page 2356) shall not occur.
A syntax error in a special built-in utility may cause a shell
executing that utility to abort, while a syntax error in a regular
built-in utility shall not cause a shell executing that utility to
abort.
Putting these two things together, the standard clearly requires
that in cases where a special built-in utility would abort the shell
due to a syntax error "in the utility" (i.e. in the use of the
utility but not in the shell language), prefixing with "command"
prevents the shell from aborting, and "set -o unknown_option" is
such a case.

that section says "may cause", not "shall cause", so the standard does not make
it a hard requirement. it says the shells are permitted to abort, if that is
the behavior they actually want.
-mike

[Geoff Clare]

Post by Mike Frysinger

Post by Geoff Clare

Post by Dan Douglas

Post by Jilles Tjoelker
In most shells (e.g. bash in POSIX mode, ksh93), an unknown set -o
option is a utility syntax error per XCU 2.8.1 which causes the shell to
abort. I think that prepending 'command' should leave the shell running
but mksh aborts anyway, forcing a slow subshell to test for features.

This is an issue I've been meaning to file a defect on or at least ask about
for a long time. I asked the maintainer over a year ago why the command
builtin fails to suppress fatal errors in special builtins, when it is clearly
documented in the ksh88 manual and implemented by every shell I have to test
with except for mksh. However after quite some searching neither of us were
able to find any language that unambiguously requires the command builtin to
have that feature.

If the command_name is the same as the name of one of the special
built-in utilities, the special properties in the enumerated list
at the beginning of Section 2.14 (on page 2356) shall not occur.
A syntax error in a special built-in utility may cause a shell
executing that utility to abort, while a syntax error in a regular
built-in utility shall not cause a shell executing that utility to
abort.
Putting these two things together, the standard clearly requires
that in cases where a special built-in utility would abort the shell
due to a syntax error "in the utility" (i.e. in the use of the
utility but not in the shell language), prefixing with "command"
prevents the shell from aborting, and "set -o unknown_option" is
such a case.

that section says "may cause", not "shall cause", so the standard does not make
it a hard requirement. it says the shells are permitted to abort, if that is
the behavior they actually want.

The point is that prefixing with "command" prevents the shell from
aborting if the shell is one that would have aborted without "command".

[Richard Hansen]

Post by Richard Hansen
* For features that break backward compatibility with Issue 7, or for
backward-compatible features where toggling on or off makes sense,
reserve the posix_* prefix in the 'set' option namespace. For
example, 'set -o posix_local' could enable support for local
variables inside functions (in a to-be-specified manner). The
default would always be the backward-compatible setting. Testing
whether an implementation supports a particular feature can be done
by attempting to turn the feature on; if unsupported, 'set' will
return non-zero.
* For features that do not break backward compatibility with Issue 7
and that do not need to be toggled on or off, provide a way to test
whether the shell implements the feature. For example, 'set -o
posix_arrays' could return zero if arrays are supported and
non-zero otherwise (but the command would not change any state; if
arrays are supported, a plain 'set +o' or 'set -o' would either not
show posix_arrays or always show posix_arrays as enabled).

This was discussed a bit during today's teleconference. I've tried to

Post by Richard Hansen
Use [[ with a new operator to test if a backwards-compatible feature
is present.

I'm not opposed to this as long as it doesn't break legacy (Issue 7)
scripts. However, between this and 'set -o posix_foo' I prefer the
latter ('set' is about controlling the behavior of the shell; '[[' is
more for testing external inputs).

Post by Richard Hansen
Use getconf to test whether a feature is present.

Agreed; I think this is better than both 'set -o posix_foo' and '[['
when testing if a non-togglable feature is present. (Togglable
features would still be enabled/disabled via 'set'.)

Post by Richard Hansen
Some (conformant?) shells have backwards-incompatible extensions
like 'local' already "turned on" by default, so we don't necessarily
want the standard to say that a backwards-incompatible extension
must be disabled by default. If we did, currently conformant
implementations would be required to significantly change their
default behavior, and that would break existing scripts.

If such shells are considered conformant, then I agree -- we should
allow shells to enable a feature by default as an extension.

Even if such shells are not considered conformant, we may want to
allow shells to enable a feature by default so long as there is a
mechanism for strictly conforming scripts to reliably disable such
extensions.

Post by Richard Hansen
Allowing shells to enable a feature by default will break some
scripts, but disabling it by default will break other scripts.

True. However, I'm not too worried about this because it is already a
problem today:

* A script that relies on an extension might break when run on a
conformant shell that does not implement the extension.

* A strictly conforming script that conflicts with an extension
(e.g., defines and tries to invoke a function named local) will
break when run on a shell that implements that extension. (XBD
2.1.1 says that there should be a way to invoke a shell without
any backward-incompatible extensions such as 'local', but I don't
think it's practical to expect scripts to be executed this way.)

I think this situation will actually improve if this proposal is
implemented: Rather than hope that the script doesn't conflict with
an extension that may or may not exist, script authors could disable
an enabled-by-default feature via 'set +o posix_foo'.

To avoid the need to dynamically discover which features are
implemented and enabled, we could add a required 'posix_issue8'
metafeature that, when enabled, ensures that all backward-incompatible
features (standard and otherwise) are automatically turned off, except
for maybe a standard list of standard features that we want enabled by
default because they are considered to be low risk. If a feature is
subsequently toggled, 'possix_issue8' would be automatically turned
off.

Post by Richard Hansen
A big part of the problem is that there is no reserved namespace for
utility names in the shell command language. C has standard,
implementation, and user reserved namespaces; the shell does not.
At this point, it is hard to set up namespaces that won't conflict
with what is already existing practice.

True. Perhaps we could add a feature (named something like
'posix_reservednamespaces') that, when turned on, restricts parts of
the variable, function, and command namespaces. This feature could be
automatically turned on when enabling another feature that would place
something in the reserved namespace.

Post by Richard Hansen
While a bear for implementers, I think one possibility is extending
set with an -o settings for version compatibility. e.g.
set -o backcompat_V6
that would limit that invocation of the shell to the features of a
particular version. Existing scripts would then need to add such a
statement to their top but otherwise not require changes.

This would cause currently conformant scripts to no longer be
conformant, and it breaks backwards compatibility.

Post by Richard Hansen
Does the shell go back to some default mode for each sourced file,
subshell, function invocation, ...?

I would say no. If a script needs to source a legacy dot script, it
would have to temporarily enable/disable features appropriately. For
example, we could add a required 'posix_issue7' metafeature so that
'set -o posix_issue7' disables all backward-incompatible features to
get Issue 7-ish behavior, and use it like so:

set -o posix_issue8
backup=$(set +o)
set -o posix_issue7
. foo.sh
eval "${backup}"

However, your question raises an interesting issue. Consider this
code:

command set -o posix_local
foo() { local blah; blah=asdf; printf %s\\n "${blah}"; }
command set +o posix_local
foo

What should happen here? The 'posix_local' feature is disabled when
the function is invoked, but it was enabled when the function was
defined.

I think the specification for the 'posix_local' feature should specify
that when a function is defined, the state of the 'posix_local'
feature (enabled or disabled) is saved as part of the definition of
the function. Whenever a function is called, the state of the
'posix_local' feature is temporarily bound to the saved value
(temporarily enabled/disabled in a dynamic binding). Any change to
the state of 'posix_local' at invocation and during execution of the
function are reverted when the function returns.

This is *much* more complex than an always-on feature. The added
complexity could kill this whole idea. We could add it to a 'Future
Directions' section anyway and see how implementations react; maybe
the response will be positive despite the complexity. The
alternatives are to break backward compatibility or do without the
feature, neither of which is pleasant. And the feature would be
optional (at first anyway), so lightweight implementations could
choose to not implement it.

Zsh does something similar to this but with significant design flaws
(in my opinion).

Post by Richard Hansen
Solaris has multiple variants of the standard utilities, including
sh. Applications can select the desired variant by setting PATH
appropriately. What about this as an alternative?

This might work, but I have concerns:

* Shell code shows up in lots of places. Controlling which shell is
invoked in each case seems like a monumental task.

* Each invocation of the shell either has a feature or it doesn't --
it's not possible to mix and match code of various vintages (e.g.,
source a legacy dot script from a script targeting Issue 8).

-Richard

[Richard Hansen]

Post by Richard Hansen

Post by Richard Hansen
* For features that break backward compatibility with Issue 7, or for
backward-compatible features where toggling on or off makes sense,
reserve the posix_* prefix in the 'set' option namespace. For
example, 'set -o posix_local' could enable support for local
variables inside functions (in a to-be-specified manner). The
default would always be the backward-compatible setting. Testing
whether an implementation supports a particular feature can be done
by attempting to turn the feature on; if unsupported, 'set' will
return non-zero.
* For features that do not break backward compatibility with Issue 7
and that do not need to be toggled on or off, provide a way to test
whether the shell implements the feature. For example, 'set -o
posix_arrays' could return zero if arrays are supported and
non-zero otherwise (but the command would not change any state; if
arrays are supported, a plain 'set +o' or 'set -o' would either not
show posix_arrays or always show posix_arrays as enabled).

This was discussed a bit during today's teleconference. I've tried to

Post by Richard Hansen
Use [[ with a new operator to test if a backwards-compatible feature
is present.

I'm not opposed to this as long as it doesn't break legacy (Issue 7)
scripts. However, between this and 'set -o posix_foo' I prefer the
latter ('set' is about controlling the behavior of the shell; '[[' is
more for testing external inputs).

Post by Richard Hansen
Use getconf to test whether a feature is present.

Agreed; I think this is better than both 'set -o posix_foo' and '[['
when testing if a non-togglable feature is present. (Togglable
features would still be enabled/disabled via 'set'.)

Related to testing whether a feature is implemented, we would need to
provide the ability to test whether a togglable feature is currently
enabled or not. POSIX provides the $- special parameter to test if a
single-letter option is enabled, but there is no standard equivalent for
long options. Bash, ksh93, and Zsh all have [[ -o <name> ]] for this
purpose, so standardizing [[ -o <name> ]] may be the best route.

If we go this route, how should [[ -o <name> ]] behave if the named
option does not exist? Bash and ksh93 quietly return false but Zsh aborts.

Adding [[ to the standard could theoretically break existing scripts,
though it's unlikely. We could add a mandatory posix_test_v2 togglable
feature to enable [[...

-Richard

[Richard Hansen]

Post by Richard Hansen
Adding [[ to the standard could theoretically break existing scripts,
though it's unlikely. We could add a mandatory posix_test_v2 togglable
feature to enable [[...

Ignore this -- I forgot that XCU 2.4 already includes [[.

-Richard

[Richard Hansen]

Post by Richard Hansen
* For features that break backward compatibility with Issue 7, or for
backward-compatible features where toggling on or off makes sense,
reserve the posix_* prefix in the 'set' option namespace.

I forgot that Zsh already has several options named posix*, so this
might not be the best namespace to reserve. Zsh ignores case and
underscores, so _posix_* is equivalent to posix*. Maybe posix.*?

-Richard