Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
Date:Mon, 31 Oct 2022 19:03:53 +
From:"Stephane Chazelas via austin-group-l at The Open Group"
Message-ID: <20221031190353.ar33l2s6dwkor...@chazelas.org>
| [ is perfectly fine after we deprecate -a, -o binary operators
| and "(", ")".
Which was done ages ago.test (or its '[' synonym) is just fine now.
Wrt the current issue, I support the new operators being added to '['
that Chet Ramey mentioned in his message or note about that (those listed
in the Subject of the bug) - with the exception of == which is just a
meaningless frill that adds nothing useful at all (and isn't supported
in many test implementations, unlike the others proposed, which are).
As best I can tell there is no intent to add anything about the [[
extension that some shells have, so discussing that on this list isn't
really appropriate.
kre
ps: note that not adding == (or any other proposed test operators) doesn't
mean that any implementations that support them need remove that support,
just that applications cannot rely upon those things working everywhere.
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
2022-10-31 12:00:24 -0700, Scott Lurndal via austin-group-l at The Open Group: [...] > However, another benefit of the '[[' builtin is that it does not > do word splitting or pattern expansion. [...] "[" doesn't do word splitting of pathname expansion either, it's the shell that does if you forget to quote. For [[...]] not to do that, it needs to introduce a new language different from the usual shell one. Should we then introduce a: [ls -ld $file] construct, so we can leave $file unquoted and omit the -- there as well to list information from a file so we don't have to write ls -ld -- "$file"? And maybe a [echo foo\n$var], with again its own language to remove that old problem where echo "$var" fails for values of $var that start with - (with some implementations) or does unwanted escape expansions on the contents of $var. Note that though no word splitting is done inside [[...]] (except of course inside command substitutions within), it still does pattern matching. [[ $a = $b ]] still needs to be written [[ "$a" = "$b" ]] or at least [[ $a = "$b" ]] if you want to do byte-to-byte comparison. -- Stephane
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
2022-10-31 10:35:38 -0700, Scott Lurndal via austin-group-l at The Open Group:
[...]
> Historically, '[[' was implemented directly by the shell, while '['
> was implemented using fork(), exec("[").There is clearly a benefit
> to eliminating process creation.
[...]
AFAIK and as also suggested by
https://www.in-ulm.de/~mascheck/bourne/#system3
[ was introduced as an alias for test at the same time it was
made builtin to the shell in SysIII (1981). So process creation
was elimited long before ksh was even first released.
[[...]] AFAICT was added first to ksh88 (ksh86 didn't have it).
See also:
https://www.in-ulm.de/~mascheck/various/shells/ksh88-fixes
Showing the evolution of the micro-language that is being
interpreted inside that [[...]].
[...]
> > It is ambiguous as well as overly terse, poorly readable, duplicative
> > and unnecessarily overloaded due to the era this token was written and
> > the codebase it is modeled on i.e, Perl. Perl has been declining in
> > popularity for a couple of decades now. The main reason is readability.
> > Why is Posix considering this failed syntax model?
>
> As perl came several years after the first release of David's shell,
> I'm not sure that you can claim correctly that the [[ feature was
> modeled on Perl.
[...]
ksh88 was released quite a few months after the first release of
perl. perl's like part of ksh's syntax (in particular the other
micro-language inside of ((...)) (only specified by POSIX inside
$((...))) is largely inspired from C.
In any case, I don't see either what the popularity of perl has
to do with that.
[ is perfectly fine after we deprecate -a, -o binary operators
and "(", ")". Yes, expansions must be quoted, but that has
nothing to do with [ itself. They must be quoted in the
arguments of any command (and the POSIX spec should be improved
on that front as there are still many examples that leave
parameter expansions unquoted).
--
Stephane
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
On Mon, Oct 31, 2022 at 11:24:06AM -0700, Roger Marquis wrote:
> scott wrote:
> >Historically, '[[' was implemented directly by the shell, while '['
> >was implemented using fork(), exec("[").There is clearly a benefit
> >to eliminating process creation.
>
> Isn't that an implementation detail that can be easily changed? If so
> not sure it'd be relevant to the compatibility or syntax issues with '[['.
The current standard allows the shell to treat any command as a
builtin and execute it as such, so long as it preserves the semantics.
However, another benefit of the '[[' builtin is that it does not
do word splitting or pattern expansion.
scott
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
On Mon, Oct 31, 2022 at 11:24:06AM -0700, Roger Marquis via austin-group-l at The Open Group (austin-group-l@opengroup.org) wrote: > Korn shell does predate Perl by 4 years (according to > Wikipedia). Was the operator in question part of the initial > implementation though (David)? The [[ ... ]] construct was present already in ksh88. -- Tapani Tarvainen
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
scott wrote:
Historically, '[[' was implemented directly by the shell, while '['
was implemented using fork(), exec("[").There is clearly a benefit
to eliminating process creation.
Isn't that an implementation detail that can be easily changed? If so
not sure it'd be relevant to the compatibility or syntax issues with '[['.
As perl came several years after the first release of David's shell,
I'm not sure that you can claim correctly that the [[ feature was
modeled on Perl.
Good point, and Korn shell does predate Perl by 4 years (according to
Wikipedia). Was the operator in question part of the initial
implementation though (David)? Either way it is the type of syntax that
signifies the era and, more importantly, that most languages have been
working away from in subsequent decades for good and (I trust) obvious
reasons.
Roger
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
On Sun, Oct 30, 2022 at 02:06:48PM -0700, Roger Marquis via austin-group-l at
The Open Group wrote:
> >Now i read stephane's "MO, [[...]] has no benefit other than cosmetic over
> >[" (#5973)
>
> No benefit is key, but the cost is also an issue, cost in terms of
> compatibility.
Historically, '[[' was implemented directly by the shell, while '['
was implemented using fork(), exec("[").There is clearly a benefit
to eliminating process creation.
> >To my surprise i found yesterday that [[..]] is quite ambiguous, whereas i
> >thought it is not:
>
> It is ambiguous as well as overly terse, poorly readable, duplicative
> and unnecessarily overloaded due to the era this token was written and
> the codebase it is modeled on i.e, Perl. Perl has been declining in
> popularity for a couple of decades now. The main reason is readability.
> Why is Posix considering this failed syntax model?
As perl came several years after the first release of David's shell,
I'm not sure that you can claim correctly that the [[ feature was
modeled on Perl.
scott
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
The proposal extends the ksh93 usage, not breaks it... Doesn't the proposal extended the POSIX shell i.e., /bin/sh, normally called the Bourne shell? The reason why this is import is that /bin/sh (Bourne) is the only cross-platform shell scripting environment we have. The proposal, which many of us see as a vendor-led effort to remake the Bourne shell into something more perl-like, would be a disaster for those of us trying to write cross-platform code. IBM can do whatever it wants with ksh, RH can do whatever with bash, including applying "embrace and extend" vendor lock-in techniques pioneered by MS. Should have nothing to do with the POSIX shell. There are better ways to implement this functionality, much better ways. Just as there were better ways to implement '$()'. Let's not ruin /bin/sh the way Python 3 is ruining that language and Perl's continuing lack of readability has made it into a defacto legacy language. Roger Marquis
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
On 9/23/16 12:17 AM, Austin Group Bug Tracker wrote: > This is a separate issue from what code points are required to be in each > charclass for all locales. For a script to be portable unquoted input with > grammatical significance in terms of being token delimiters is limited to > these code points. Relying on code points a locale may add to a class means > the script can not function properly on a platform that doesn't provide > localedef or a locale with the same additions, so to me is undefined > behavior. That's an admirable guideline, but it's not part of the actual standard, so you're defining portable behavior outside the text. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef
On 9/22/16 4:59 AM, Austin Group Bug Tracker wrote: >> Last, for portable scripts blank detection is currently not > locale-dependant. >> For tokenization only the SPC and TAB code points count, as the default >> members of the blank charclass. Recognizing additional members of a > locale's >> blank charclass is undefined behavior. Adding default members from > ISO-646 is >> possible, but not likely. > > What makes you say that? IIRC both bash and yash explicitely made their > tokenisation locale dependant for POSIX compliance. (I do agree it's not > desirable though) 2.3 Token Recognition, rule 8: "If the current character is an unquoted , any token containing the previous character is delimited and the current character shall be discarded." is defined in 3.74 as "One of the characters that belong to the blank character class as defined via the LC_CTYPE category in the current locale. In the POSIX locale, a character is either a or a ." So unless you say that portable scripts are restricted to the POSIX locale, which you may be saying, blank detection during tokenization depends on the current locale. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
