> 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 [EMAIL PROTECTED] http://tiswww.tis.cwru.edu/~chet/ _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
