[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-11-30 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


The following issue has a resolution that has been APPLIED. 
== 
https://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Applied
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text:See
https://austingroupbugs.net/view.php?id=375#c6040 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2022-11-30 16:44 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: olof
2011-11-15 17:26 dwheeler   Note Added: 0001011  
2011-11-15 19:25 ajosey File Added: Extendingshellconditionals.pdf  
 
2011-11-15 19:27 ajosey File Added: Extendingshellconditionals.txt  
 
2011-11-15 19:30 ajosey Note Added: 0001013  
2011-11-23 23:49 dwheeler   File Added:
Extendingshellconditionals-2011-11-23.pdf
2011-11-23 23:50 dwheeler   File Added:
Extendingshellconditionals-2011-11-23.odt
2011-11-23 23:50 dwheeler   File Added:
Extendingshellconditionals-2011-11-23.txt

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-11-14 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text:See
https://austingroupbugs.net/view.php?id=375#c6040 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2022-11-14 16:06 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: olof
2011-11-15 17:26 dwheeler   Note Added: 0001011  
2011-11-15 19:25 ajosey File Added: Extendingshellconditionals.pdf  
 
2011-11-15 19:27 ajosey File Added: Extendingshellconditionals.txt  
 
2011-11-15 19:30 ajosey Note Added: 0001013  
2011-11-23 23:49 dwheeler   File Added:
Extendingshellconditionals-2011-11-23.pdf
2011-11-23 23:50 dwheeler   File Added:
Extendingshellconditionals-2011-11-23.odt
2011-11-23 23:50 dwheeler   File Added:
Extendingshellconditionals-2011-11-23.txt
2011-11-23 23:57 dwh

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-11-09 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2022-11-09 09:44 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0006040) geoffclare (manager) - 2022-11-09 09:44
 https://austingroupbugs.net/view.php?id=375#c6040 
-- 
There seems to be support for adding < and > to test/[ but mixed views on
==, so here are some suggested changes, adapted from
Extendingshellconditionals-2013-12-09.odt, to implement option 2 from
https://austingroupbugs.net/view.php?id=375#c5972 with < and > also added ...

After D2.1 page 3206 line 108874 section test,
add:pathname1 -ef
pathname2True if pathname1 and pathname2
resolve to existing directory entries for the same file; otherwise,
false.
After D2.1 page 3207 line 108889 section test,
add:pathname1 -nt
pathname2True if pathname1 resolves to an
existing file and pathname2 cannot be resolved, or if both resolve
to existing files and pathname1 is newer than pathname2
according to their last data modification timestamps; otherwise,
false.pathname1 -ot
pathname2True if pathname2 resolves to an
existing file and pathname1 cannot be resolved, or if both resolve
to existing files and pathname1 is older than pathname2
according to their last data modification timestamps; otherwise,
false.
After D2.1 page 3207 line 108925 section test, add:s1
> s2True if s1 collates after s2 in
the current locale; otherwise, false.s1 <
s2True if s1 collates before s2 in the
current locale; otherwise, false.
On D2.1 page 3208 line 108934 section test, change:if a
pathname argument isto:if a
pathname, pathname1, or pathname2 argument
is
After D2.1 page 3209 line 108974 section test,
add:LC_COLLATEDetermine the locale for the behavior
of the > and < string comparison
operators.
After D2.1 page 3210 line 108999 section test, add a new first paragraph to
APPLICATION USAGE:Since '>' and '<' are operators in the shell
language, applications need to quote them when passing them as arguments to
test from a shell.
On D2.1 page 2212 line 109090 section test, append to the
paragraph:A later proposal to add [[ ]] in Issue 8 was
also rejected because existing implementations of it were found to be
error-prone in a similar way to historical versions of test, and
there was also too much variation in behavior between shells that support
it.
On D2.1 page 2212 line 109092 section test, change:the
error-prone historical -o flag of
test.to:the error-prone historical
-a and -o operators of test.
On D2.1 page 2213 line 109126 section test, delete:str =
pattern, str != pattern,
On D2.1 page 2213 line 10912? section test, change:They were
not carried forward into the test utility when the conditional
command was removed from the shell because they have not been included in
the test utility built into historical implementations of the
sh utility.to:They were not carried forward
into the test utility when the conditional command was removed from
the shell because they had not been included in the test utility
built into historical implementations of the sh utility. However,
they were later added to this standard once support for them became
widespread. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue

Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-10-31 Thread Robert Elz via austin-group-l at The Open Group
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 Thread Stephane Chazelas via austin-group-l at The Open Group
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 Thread Stephane Chazelas via austin-group-l at The Open Group
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

2022-10-31 Thread Scott Lurndal via austin-group-l at The Open Group
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

2022-10-31 Thread Tapani Tarvainen via austin-group-l at The Open Group
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

2022-10-31 Thread Roger Marquis via austin-group-l at The Open Group

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

2022-10-31 Thread Scott Lurndal via austin-group-l at The Open Group
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



[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-10-26 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2022-10-26 14:16 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0006014) steffen (reporter) - 2022-10-26 14:16
 https://austingroupbugs.net/view.php?id=375#c6014 
-- 
While rewriting the conditional expression of my MUA i stumbled over [[..]]
of which i thought there was an open issue .. and found this.

Now i read stephane's "MO, [[...]] has no benefit other than cosmetic over
[" (#5973), but nonetheless i want to note that _if_ [[ is about to be
standardized, then wording should be applied to make ambiguities much less
likely than they are for [.  The standard has a tremendous amount of
warnings and notes about [ and the syntax ambiguities it has, and the
initial four (?) in-order tests that should be used to avoid them.

To my surprise i found yesterday that [[..]] is quite ambiguous, whereas i
thought it is not:

  #?0|kent:tmp$ if [[ -n == && true ]]; then echo au; fi
  au

That is ok

  #?0|kent:tmp$ if [[ -n == ] && true ]]; then echo au; fi
  -bash: syntax error near unexpected token `-n'
  #?0|kent:tmp$ if [[ -n == ']' && true ]]; then echo au; fi
  -bash: syntax error in conditional expression

But that is not in my opinion.

  #?0|kent:tmp$ if [[ '-n' == ']' && true ]]; then echo au; fi
  -bash: syntax error near unexpected token `'-n''
  #?2|kent:tmp$ if [[ x'-n' == x']' && true ]]; then echo au; fi

With escaping it works, but _I_ thought [[..]] is designed so escaping
ambiguities is not necessary!

I think the standard should note something around "if first argument is an
unary operator, and second argument is a binary operator, lookahead shall
be performed to see if the (a) argument list is exhausted, (b) an AND/OR
list follows, or (c) a group is closed, in order to reduce ambiguities from
the language as much as possible". 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669   

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-10-14 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2022-10-14 15:12 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0005991) chet_ramey (reporter) - 2022-10-14 15:12
 https://austingroupbugs.net/view.php?id=375#c5991 
-- 
I'm not in favor of one proposal over the other -- bash isn't going to
change what it does today -- but if I had to choose I would choose a
variant of option 2: change test/[ to add -nt, -ot, -ef (spec including
what happens when files don't exist or otherwise error on stat(2)); add <
and > (specifying whether or not they depend on the locale); and add == as
a synonym for =.

Omit any pattern matching or regexp matching; leave those for some later
specification of `[['. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: olof
2011-11-15 17:26 dwheeler   Note Added: 0001011  
2011-11-

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-09-22 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2022-09-22 20:30 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0005973) stephane (reporter) - 2022-09-22 20:30
 https://www.austingroupbugs.net/view.php?id=375#c5973 
-- 
IMO, this bug should be split into

- one to add support for -nt, -ot, -ef, <, >, ==, =~ (the latter so far
only implemented in zsh and yash AFAIK) to test/[, that can be addressed
now.
- one to implement [[...]]

IMO, [[...]] has no benefit other than cosmetic over [/test and adds only
complications as it comes with its own specific language whose syntax
varies from shell to shell. -ef, -nt, -ot are useful (care to be taken of
the cases where files are not stat()able though). <, > as well given that
expr is unusable (and IMO should be deprecated) and awk's awk --
'BEGIN{exit(!(ARGV[1]"" < ""ARGV[2]))}' a bit cumbersome (though not that
much when wrapping that in a function). 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber 

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2022-09-22 Thread Austin Group Bug Tracker via austin-group-l at The Open Group


A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2022-09-22 16:18 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0005972) geoffclare (manager) - 2022-09-22 16:18
 https://austingroupbugs.net/view.php?id=375#c5972 
-- 
This bug was reviewed in the September 22, 2022 teleconference. Given the
difficulties identified with the matching operations performed by == and =~
in [[ ... ]] there would seem to be two options for progressing this bug:

1. Keep [[ ... ]] but without =~ and with == "neutered" such that it can
only be used portably for fixed-string comparisons.

2. Omit [[ ... ]] altogether but perhaps add -nt, -ot, and -ef to test/[
instead.

We would welcome feedback on whether option 1 is an acceptable compromise
or is too limiting. We need to resolve this bug by no later than 2022-11-13
if it is to make it into draft 3. After that, only option 2 will be
possible (because draft 3 will be "feature complete"). 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 

Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2017-05-19 Thread Roger Marquis

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



[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2017-05-19 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2017-05-19 21:44 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003700) shware_systems (reporter) - 2017-05-19 21:44
 http://austingroupbugs.net/view.php?id=375#c3700 
-- 
The proposal extends the ksh93 usage, not breaks it... Attention to being
backwards compatible is part of the discussion. The main reason I see it's
preferable to using [/test, security wise, is that it's built-in and can't
be overridden, not due to any security specific features above what test
provides. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: olof
2011-11-15 17:26 dwheeler   Note Added: 0001011  
2011-11-15 19:25 ajosey File Added: Extendingshellconditionals.pdf  
 
2011-11-15 19:27 ajosey File Added: Extendingshellconditionals.txt  

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2017-05-19 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2017-05-19 21:20 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003698) mirabilos (reporter) - 2017-05-19 21:20
 http://austingroupbugs.net/view.php?id=375#c3698 
-- 
Hello dwheeler,

please DO NOT add [[ to POSIX in a way that invalidates all existing
scripts using it.

This means:

PLEASE *DO NOT* ADD [[ TO POSIX!


The *ksh world has been using [[ in scripts since forever and told people
to use it exclusively for secure shell scripting, so basically *every*
script uses it. If POSIX is going to invade on existing territory like
that, it’s like a declaration of war.


Some notes on =~ (which mksh does not implement at this time): I’ve read
attempts to put a RE grammar onto the RHS.
I don’t think this is the correct way because we also need to be able to
put the RE/extglob into a variable, in order to make it possible to specify
them dynamically:
x='b*r'; [[ bar = $x ]] # returns true

As for quoting… incidentally, I figured this out when adding the BSD
[[:<:]] and [[:>:]] to mksh (while adding character classes in the first
place):
[[ 'a foo b' = *[[:\<:]]foo[[:\>:]]* ]] # returns true

Combining the two from above:
x='[[:<:]]foo[[:>:]]'; [[ 'a foo b' = *$x* ]] # returns true 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-10-10 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-10-10 11:35 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003405) shware_systems (reporter) - 2016-10-10 11:35
 http://austingroupbugs.net/view.php?id=375#c3405 
-- 
Re: 3392
Yes, you're right; as stated it's a bit wonky. I was looking at it as that
applied to escaping or single-quoted sequences inside double or
single-quotes, like "foo'|'bar" or 'foo"|"bar' would match 'foo|bar', with
quote removal still effective on the ERE as a WORD token before processing
internal quoting like that according to the proposed text. The 'After quote
removal, ' preamble is missing, though, and the caveat \' and \" are needed
for them to be treated as the ERE ordinary chars they usually are. I'd
expect 
 to return true.

Re: 3393
I am not saying portable scripts are limited to the POSIX locale. I am
saying a script that limits what characters of the blank class it uses as
token separators to the 2, TAB and SPC, of the POSIX and C locales are
portable whatever locale is in effect, as those 2 are required to be in all
locale's blank charclass. A script author that knows on a particular system
a locale includes a  code point in its blank charclass can
use it to separate tokens also, but that script is not guaranteed portable. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 000

Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-23 Thread Chet Ramey
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/



[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-23 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-23 13:05 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003393) chet_ramey (reporter) - 2016-09-23 13:05
 http://austingroupbugs.net/view.php?id=375#c3393 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3388

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. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issu

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-23 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-23 06:59 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003392) stephane (reporter) - 2016-09-23 06:59
 http://austingroupbugs.net/view.php?id=375#c3392 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3391

Mark, you're missing the point I'm trying to make since the
beginning. What you're describing (about quoting of RE
operators) is the zsh/bash31 behaviour, not the one of
bash32+/ksh93 or what this proposal specifies. Quoting the
proposal:

> string =~ regex
> true if string matches the extended regular expression (ERE)
> regex as defined in section 9.4; otherwise false.  Characters
> that are quoted in regex (using , single-quote, or
> double-quote) shall not be treated as an ERE special character,
> but shall instead be treated as an ERE ordinary character and
> thus only match themselves.

See also appendix B

So [[ $a =~ "foo|bar" ]] and s='foo|bar'; [[ $a =~ "$s" ]] is
testing whether $a contains "foo|bar" (as if by calling
regcomp("foo\\|bar")), [[ $a =~ foo|bar ]] is not allowed and
re='foo|bar'; [[ $a =~ $re ]] is matching $a against the foo|bar
ERE (regcomp("foo|bar")).

With  bash-4.3:


$ ltrace -e regcomp bash -c '[[ a =~ "a|b" ]]'
bash->regcomp(0x7013f3b0, "a\\|b", 1)  
  = 0
+++ exited (status 1) +++
$ ltrace -e regcomp bash -c '[[ a =~ a|b ]]'
bash->regcomp(0x7fff33a64d50, "a|b", 1)
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp bash -c 're="a|b"; [[ a =~ "$re" ]]'
bash->regcomp(0x7fffba6ec710, "a\\|b", 1)  
  = 0
+++ exited (status 1) +++
$ ltrace -e regcomp bash -c 're="a|b"; [[ a =~ $re ]]'
bash->regcomp(0x7ffe497b2700, "a|b", 1)
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp bash -c '[[ a =~ ["a|b"] ]]'
bash->regcomp(0x7ffe32decc20, "[a|b]", 1)  
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp bash -c '[[ a =~ "[a|b]" ]]'
bash->regcomp(0x7ffea326a1e0, "\\[a\\|b]", 1)  
  = 0
+++ exited (status 1) +++


With zsh-5.1.1


$ ltrace -e regcomp zsh -c '[[ a =~ "a|b" ]]'
regex.so->regcomp(0x7ffc3aaa2ac0, "a|b", 1)
  = 0
+++ exited (status 0) +++
$ ltrace -e regcomp zsh -c '[[ a =~ a|b ]]'
zsh:1: parse error near `|'
+++ exited (status 1) +++
 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-22 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-23 04:17 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003391) shware_systems (reporter) - 2016-09-23 04:17
 http://austingroupbugs.net/view.php?id=375#c3391 
-- 
"foo|bar" after quote removal effectively gets passed to regcomp() as the C
string foo|bar\0. A shell can use an internal workalike function that
includes the effect of regexec()/free() too. That is what is expected to
handle the extended_reg_exp production, not the code that handles shell
operators. The result is then the same for
re="foo|bar"
[[ $str =~ $re ]] 
or even =~ `printf %s%s%s foo '|' bar`.

The concerns you have apply if the ERE was an argument to [[ as a utility,
as then the simple_command production governs interpretation, but as a
keyword pair with its own productions those constraints don't hold.

The locale's charmap determines the bit patterns of each code point. So the
shell is dependant on them for determining whether a byte is a defined char
and which class it is. Hardcoding a reliance on the C locale's charmap may
fail, as a result, if the charmap of a locale says the TAB code point is
represented by 0xFF instead. 

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.

This does not limit scripts to using only the POSIX locale, but it is a
subset of the locales scripts that don't care about portability might use. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake

Re: [1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-22 Thread Chet Ramey
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/



[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-22 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-22 08:59 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003390) stephane (reporter) - 2016-09-22 08:59
 http://austingroupbugs.net/view.php?id=375#c3390 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3388
> This proposal, as a white paper, is a case where the behaviors are being
> merged to be future compatible more than backwards. This is also why test
is
> being deprecated and marked LEGACY. Both it and the [[ extensions are
broken
> one way or the other, so this proposal is taking what isn't broken and
giving
> it a firmer logical model by adding it to the grammar with extensibility
> provisions. The caveat about what the standard says being reliable only
in
> the C locale and locales using nationalized ASCII applies here too, for
now;
> future Enhancement Reqs. against the V8 drafts that define additional
> required locales will address remaining localization concerns.

With -a, -o, (, ) and an argument-less -t removed, "test"/"[" is no longer
broken.

What I'm saying is that the two requirements that the =~ argument must be a
WORD and that quoting ERE operators remove their special meaning are
incompatible (or at least make for a not useful operator).

If you need to make it a WORD, then for instance, you can't do

[[ $string =~ foo|bar ]]

and if you do

[[ $string =~ "foo|bar" ]]

Then you're disabling that "|" ERE operator. You'd need:

re="foo|bar"
[[ $string =~ $re ]]

to make it work.

Then, you might as well specify the bash31/zsh behaviour where

[[ $string =~ "foo|bar" ]]

does test whether $string contain foo or bar as opposed to containing
"foo|bar"

> It is known this may break any current script using [[ as an extension.
The
> changes to fix those scripts are expected to be minimal; as proposed,
for
> EREs, enclosing the entire WORD in double quotes will suffice in most
cases,
> only needing \", \` and \$ internally to disable substitutions
processing. If
> tilde expansion is enabled and desired something like "head"~"tail" is
> required. The onus is already on script authors, if they don't enclose a
WORD
> in quotes, to escape any character that implicitly delimits the token.
New
> scripts are expected to do version checking that they're running on V8
or
> later to avoid conflicts of interpretation with older shells. It should
not
> break any conforming scripts that were only using test with operators
other
> than -a or -o.

tildes are not expanded in "head"~"tail", only at the beginning of a word
and when not quoted (though rules are different in assignments).

> 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) 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue 

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-22 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-22 08:42 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003389) stephane (reporter) - 2016-09-22 08:42
 http://austingroupbugs.net/view.php?id=375#c3389 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3387
> - *not* quote the ERE operators (.*?+[]{}()|$^) if we want them
> to retain their special ERE significance. You'll notice that
> several of those (()|) can't be in WORD
[...]
> - to remove the special meaning of those ERE operators, we can
> use double quotes, single quotes, backslash or $'...' but not
> when they're inside [...].

Actually, I hadn't realised ksh93's was so broken so the above
is incorrect. In ksh93, quotes other than backslash only escape
the ERE operators that also are wildcard operators (?*[]()|&),
not ^$.+, as in [[ a =~ "." ]] returns true (so does r=.; [[ a =
"$r" ]]).

And [[ "\\" =~ ["?"] ]] (or any of the other glob operators in
place of ?) returns true like in old versions of bash for RE
operators.

It looks like internally ksh93 replaces [[ x =~ y ]] with [[ x =
~(E)y ]]. [[ a = ~(E)"." ]] also returns true, while [[ a = "?"
]] returns false. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 j

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-21 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-21 22:44 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003388) shware_systems (reporter) - 2016-09-21 22:44
 http://austingroupbugs.net/view.php?id=375#c3388 
-- 
This proposal, as a white paper, is a case where the behaviors are being
merged to be future compatible more than backwards. This is also why test
is being deprecated and marked LEGACY. Both it and the [[ extensions are
broken one way or the other, so this proposal is taking what isn't broken
and giving it a firmer logical model by adding it to the grammar with
extensibility provisions. The caveat about what the standard says being
reliable only in the C locale and locales using nationalized ASCII applies
here too, for now; future Enhancement Reqs. against the V8 drafts that
define additional required locales will address remaining localization
concerns. 

It is known this may break any current script using [[ as an extension. The
changes to fix those scripts are expected to be minimal; as proposed, for
EREs, enclosing the entire WORD in double quotes will suffice in most
cases, only needing \", \` and \$ internally to disable substitutions
processing. If tilde expansion is enabled and desired something like
"head"~"tail" is required. The onus is already on script authors, if they
don't enclose a WORD in quotes, to escape any character that implicitly
delimits the token. New scripts are expected to do version checking that
they're running on V8 or later to avoid conflicts of interpretation with
older shells. It should not break any conforming scripts that were only
using test with operators other than -a or -o.

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. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired A

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-21 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-21 10:20 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003387) stephane (reporter) - 2016-09-21 10:20
 http://austingroupbugs.net/view.php?id=375#c3387 
-- 
Let me rephrase. [[ =~ ]] in ksh93 and bash32+ is a bit broken by design,
but to use it properly in both (which seems to be the intent of this
proposal: to specify an operator compatible with both), it seems we need
(for the argument after =~) to:

- quote &, <, >, blanks (locale-dependant (*)) and unmatched ) and some
unmatched ] at least or we'd get errors in bash or ksh93
- *not* quote the ERE operators (.*?+[]{}()|$^) if we want them to retain
their special ERE significance. You'll notice that several of those (()|)
can't be in WORD
- quote `, ~, $ and quotes to remove their special meaning as shell tokens
(but not inside [...] for some)
- to remove the special meaning of those ERE operators, we can use double
quotes, single quotes, backslash or $'...' but not when they're inside
[...].
- other characters can be quoted as well but not with backslash as that
could introduce ERE extensions like \<, \>, \b, \w in ksh93.
- for parts of the arguments that are the result of an unquoted expansion
other than ~ expansion, \ (in the content of the expansion) removes the
special meaning of ERE operators and may introduce new ones.


Examples:

  a=''  bash -c '[[ $a =~ <.*> ]]' gives an error
  a='foo' ksh93 -c '[[ $a =~ \<.*\> ]]' returns true (\<, \> taken as word
boundaries)

You need to use:

  a='' shell -c '[[ $a =~ "<".*">" ]]' so it works in both shells or
  a='' shell -c 're="<.*>"; [[ $a =~ $re ]]' which also works in zsh
and bash31

Other example:

  a='blah' shell -c '[[ $a =~ [xy)] ]]' gives an error in both ksh and
bash
  a='\' shell -c '[[ $a =~ [xy\)] ]]' doesn't give an error but matches in
ksh (not in bash). and [[ $a =~ [xy")"] ]] also matches on backslash in
ksh93, bash used to have a similar bug.

  a='blah' shell -c 're="[xy)]"; [[ $a =~ $re ]]' works in all shells (zsh,
bash31 included)

(*) as already discussed, since blank recognition is locale dependant, you
get behaviours like:

$ LC_CTYPE=fr_FR.ISO8859-15@euro bash -c '[[ $a =~ tête-à-tête ]]'
bash: -c: line 0: syntax error in conditional expression
bash: -c: line 0: syntax error near `tête-à-tête'
bash: -c: line 0: `[[ $a =~ tête-à-tête ]]'

as that à UTF-8 character is 0xc3 0xa0 and 0xa0 happens to be a blank in
ISO8859-15 locales on Solaris.

So in effect you may need to quote every character that is not in the
portable character set in case they may be a blank in the user's locale. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-21 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-21 07:35 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003386) shware_systems (reporter) - 2016-09-21 07:35
 http://austingroupbugs.net/view.php?id=375#c3386 
-- 
Re: 3384
Ok, I oversimplified a bit on 1. It is the result of the WORD, after
substitutions and quote removal, but minus field splitting, globbing, and I
was thinking tilde expansions, that is meant to be reparsed as an
extended_reg_exp. It is left to the script author to figure out how much
the input needs to be quoted so the result has blanks and other
meta-characters EREs don't consider special appearing where required after
the quote removal. I still think an additional token type isn't required
for expressing this in the grammar. Possibly a Note 11 if this is cleaner
than adding to Note 10, but the overall context is more similar to the
pattern production than the context of ASSIGNMENT_WORD, that I see. 

If tilde expansion is included then 2. should return true, otherwise no. I
can see limiting tilde expansion to those operators that expect a filepath
string as the WORD result, and non-special otherwise. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-20 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-20 21:03 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003385) stephane (reporter) - 2016-09-20 21:03
 http://austingroupbugs.net/view.php?id=375#c3385 
-- 
Re http://austingroupbugs.net/view.php?id=375#c3384
> Both bash and ksh93 have taken some liberties with the standard inside
[[...]] as that construct was not specified by the standard

Amongst those liberties:

a='+(a)'; [[ a = $a ]]

currently returns true in both bash and ksh even though the current
proposal would mandate it to return false. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: olof
2011-11-15 17:26 dwheeler   Note Added: 0001011  
2011-11-15 19:25 ajosey File Added: Extendingshellconditionals.pdf  
 
2011-11-15 19:27 ajosey File Added: Ex

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-20 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-20 20:34 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003384) stephane (reporter) - 2016-09-20 20:34
 http://austingroupbugs.net/view.php?id=375#c3384 
-- 
Re: http://austingroupbugs.net/view.php?id=375#c3383

1- about grammar

That doesn't work. For instance the space character is not special in EREs,
yet

[[ $a =~ a b ]]

doesn't work obviously.

The behaviour for the a\ b ERE is unspecified. We may need to acknowledged
somehow that backslash is overloaded as a quoting operator in the shell and
as an escaping operator for EREs.

For instance, is re='a\b'; [[ a =~ $re ]] meant to be treated the same as
[[ a =~ a\b ]] (it's not in bash). And re='a"."b'; [[ a =~ $re ]] vs [[ a
=~ a"."b ]]

See also:

$ bash -c '[[ a =~ & ]]'
bash: -c: line 0: syntax error in conditional expression: unexpected token
`&'
bash: -c: line 0: syntax error near `&'
bash: -c: line 0: `[[ a =~ & ]]'

(same for #, < , >)

IMO, the original [[ =~ ]] implementation (in bash31) which is also the one
of zsh, where shell quoting doesn't make any difference in terms of RE
matching is a lot cleaner and easier to specify (applications just do [[
$var =~ '(..|X)&' ]], make sure the argument to =~ is a normal *shell*
WORD.

Or we could just give up on specifying [[...]] altogether (my preference as
it's broken by design except in zsh IMO as its =/== operator is not an
equality operator and it has hardly any benefit over the "[" command) and
add the =~ operator to "[" like in yash or zsh which would also be
straightforward to specify and unambiguous.

2- about ~

Whether ~ is a ERE operator or not is irrelevant here. The fact that it's
*not* a ERE operator (it is in ksh93 REs though as in [[ a =~ (?K:~(E)a)
]]) makes it even a justification that ~ can be safely expanded. ` is not a
ERE operator either, yet [[ Linux =~ `uname` ]] returns true on Linux with
both ksh93 and bash.

It's just that we need to clarify what expansions are or may be performed
in the argument to =~. Expanding ~ is not very useful because it's only
expanded at the start of the RE, but I can't see why it wouldn't be when
`...`, $param, $((arith)), $(cmd) are.

Also note that in bash the expansion of ~ ends up being quoted from an ERE
point of view, which makes sense as ~ is meant to expand to a path, not a
RE. As in HOME=.; [[ a/a =~ ~/a ]] returns false.

In bash, the same applies to process substitution.

[[ "<:" =~ <(:) ]] returns false (true in ksh93)

Both bash and ksh93 have taken some liberties with the standard inside
[[...]] as that construct was not specified by the standard. It's going to
be hard to come up with a specification that doesn't break either or both.
And if you want to throw zsh in the picture as well, it's going to be more
difficult... or simpler if we only specify [[ a =~ $var ]], that is leave
it unspecified unless the word after =~ is an unquoted variable and the
content of the variable contains a valid ERE. At the moment, that's the
only thing that is portable across bash31, bash32-or-above, zsh and ksh93. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-20 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-20 17:16 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003383) shware_systems (reporter) - 2016-09-20 17:16
 http://austingroupbugs.net/view.php?id=375#c3383 
-- 
The intent in the proposal is the right hand side respect the
extended_reg_exp production of the grammar in XBD 9.5, so it is already
defined. I agree adding a production clause to db_factor, or modifying Note
10, is desirable to make this cross reference clearer in the grammar. Also,
the cross reference to 9.4 in the description of =~ is missing "XBD" as
volume referent.

As the ~ is a non-special ERE character, I don't believe it should be
expanded to / for the compare, so think the ksh93 result more the intent.
For [[ / = ~ ]] as the expression, that I'd expect to return true. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09-25 18:51 gber   Note Added: 975  
2011-09-28 07:09 olof   Issue Monitored: ol

[1003.1(2008)/Issue 7 0000375]: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef

2016-09-19 Thread Austin Group Bug Tracker

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=375 
== 
Reported By:dwheeler
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   375
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Under Review
Name:   David A. Wheeler 
Organization:
User Reference:  
Section:test 
Page Number:3224-3225 
Line Number:107503-107513 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2011-02-07 18:34 UTC
Last Modified:  2016-09-19 21:46 UTC
== 
Summary:Extend test/[...] conditionals: ==, <, >, -nt, -ot,
-ef
==
Relationships   ID  Summary
--
has duplicate   762 Add "==" as synonym for "...
related to  813 Utility numeric argument syntax require...
== 

-- 
 (0003382) stephane (reporter) - 2016-09-19 21:46
 http://austingroupbugs.net/view.php?id=375#c3382 
-- 
For the =~ part, we'd need to define a new type of token for what's on the
right of =~.

For instance in [[ aacc =~ (aa|bb)c ]], currently (aa|bb)c can't be a WORD
as (, | and ) are token delimiters (note that [[ "a(a)" = *(a) ]] doesn't
return true in bash or ksh93).

See also [[ a1 =~ (a)\1 ]] that returns true in bash and false in ksh93 (\
is not like the other quoting operators). See also [[ a =~ \b ]] (or
\>...).

There's also the questions of the effect of quoting in things like [[ a =~
["$chars"] ]], should [[ : =~ ["^:#"] ]] return true like in bash or false
like in ksh93?

There's also the question of ~ expansion. Should

   HOME=/
   [[ / =~ ~ ]]

return true like in bash or false like in ksh93? 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2011-02-07 18:34 dwheeler   New Issue
2011-02-07 18:34 dwheeler   Status   New => Under Review 
2011-02-07 18:34 dwheeler   Assigned To   => ajosey  
2011-02-07 18:34 dwheeler   Name  => David A. Wheeler
2011-02-07 18:34 dwheeler   Section   => test
2011-02-07 18:34 dwheeler   Page Number   => 3224-3225   
2011-02-07 18:34 dwheeler   Line Number   => 107503-107513   
2011-02-07 18:49 dwheeler   Note Added: 666  
2011-02-07 20:23 Don Cragun Interp Status => --- 
2011-02-07 20:23 Don Cragun Note Added: 667  
2011-02-07 20:23 Don Cragun Severity Editorial => Objection
2011-02-07 20:23 Don Cragun Type Clarification Requested
=> Enhancement Request
2011-02-07 21:56 dwheeler   Note Added: 668  
2011-02-07 22:20 Don Cragun Description Updated  
2011-02-07 22:20 Don Cragun Desired Action Updated   
2011-02-07 22:22 Don Cragun Note Edited: 667 
2011-02-07 22:50 dwheeler   Note Added: 669  
2011-02-07 23:13 eblake Note Added: 670  
2011-03-08 03:15 dwheeler   Note Added: 688  
2011-04-24 13:16 jsonn  Note Added: 754  
2011-04-24 19:01 dwheeler   Note Added: 755  
2011-04-24 21:48 jsonn  Note Added: 756  
2011-04-25 20:45 dwheeler   Note Added: 758  
2011-04-26 09:25 markh  Note Added: 759  
2011-04-26 09:57 wpollock   Note Added: 760  
2011-04-26 10:36 jsonn  Note Added: 761  
2011-09-22 08:59 ajosey Note Added: 967  
2011-09-25 00:36 dwheeler   Note Added: 974  
2011-09