Re: More bash POSIX-compliance bugs

[Chet Ramey]

> 1) time is no longer allowed to be a reserved word.  For example:

Not true; the POSIX description of time explicitly allows it to be a reserved
word.  But:

> $ set -o posix
> $ alias !='echo hi;'
> $ alias time='echi hi;'
> $ ! true                # ! is reserved word, not alias
> $ echo $?
> 1
> $ time true             # BUG: time should be an alias, and echo hi
> 
> real    0m0.000s
> user    0m0.000s
> sys     0m0.000s
> $ set +o posix
> $ ! true                # outside of posix mode, bash documents that
> hi                      # aliases take precedence over reserved words
> $ echo $?
> 0
> $ time true             # BUG: again, time should be an alias
> 
> real    0m0.000s
> user    0m0.000s
> sys     0m0.000s

I can't  reproduce this.

caleb.INS.CWRU.Edu(2)$ echo $BASH_VERSION
3.00.16(4)-release
caleb.INS.CWRU.Edu(2)$ set -o posix
caleb.INS.CWRU.Edu(2)$ alias time='echo hi;'
caleb.INS.CWRU.Edu(2)$ alias !='echo hi;'
caleb.INS.CWRU.Edu(2)$ ! true
caleb.INS.CWRU.Edu(2)$ echo $?
1
caleb.INS.CWRU.Edu(2)$ time true

real    0m0.001s
user    0m0.000s
sys     0m0.000s
caleb.INS.CWRU.Edu(2)$ set +o posix
caleb.INS.CWRU.Edu(2)$ ! true
hi
caleb.INS.CWRU.Edu(2)$ echo $?  
0
caleb.INS.CWRU.Edu(2)$ time true
hi

> (Likewise, source is not documented as a reserved word, but since time is
> a POSIX-required utiltiy while source is not, I am okay with source
> remaining a reserved word.)

Source is not a reserved word.

> 2) The wording of bash-3.0/POSIX is misleading on item 4.  Rather than
> stating "Reserved words may not be aliased", you should state something
> like "An aliased reserved word does not undergo alias expansion if it is
> in the context of a reserved word".

OK, the wording could be clearer.

> 3) Items 18 and 19 of bash-3.0/POSIX are wrong.  Reread the description of
> cd (http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html), the
> interpretation on it
> (http://www.opengroup.org/austin/interps/uploads/40/6230/AI-037.txt), and
> pending corrections to the interpretation
> (https://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=8042).
>  Item 18 is wrong because there is nothing that states that the use of
> CDPATH turns on -P handling.  And item 19 is wrong because when CDPATH
> without . fails to find a directory in step 5, step 6 reverts to using
> $PWD (the current directory).  The following example is required to behave
> the same in POSIX mode as it currently does for normal bash mode:

I have to look at 18.  That change was made back in 1998, and the standard
does not appear to require that any longer.

I disagree that cd should default to `.' if using CDPATH.  If no directory
is found in $CDPATH, the process should stop and cd should fail.  Existing
implementations work this way.

> 4) POSIX requires that times be a special built-in.  For example:

You are correct.  Fixed.

> 5) POSIX requires that newgrp be provided as a regular shell built-in, as
> well as a standalone utility.

I disagree.  Although most of the `regular' builtins have to be
implemented within the shell, there is no POSIX requirement to do so. 
In fact, POSIX requires that every one implemented as a shell builtin
also be implemented as a separate utility.  Would you say that bash is
non-compliant if it failed to implement `true' and `false' as
builtins? 

The only requirement is the change to command search order.

> POSIX states that "A common implementation
> of newgrp is that the current shell uses exec to overlay itself with
> newgrp, which in turn overlays itself with a new shell after changing
> group. On some implementations, however, this may not occur and newgrp may
> be invoked as a subprocess."  It is the action of overlaying the current
> shell with newgrp which was the rationale for providing newgrp as a
> regular built-in, even if you choose to implement the built-in by simply
> deferring to the standalone utility rather than changing groups within
> bash before starting the new shell environment.

Sure, that's true, but there's no requirement to do so.

> On cygwin, where no one
> has yet ported a newgrp utility, bash currently fails to be
> POSIX-compliant because of the missing newgrp builtin:
> $ newgrp
> bash: newgrp: command not found

This means that cygwin is non-compliant, not that bash is not.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                                Live...Laugh...Love
Chet Ramey, ITS, CWRU    chet@case.edu    http://tiswww.tis.cwru.edu/~chet/