-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Chet Ramey on 2/22/2005 1:44 PM: >>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:
OK, I agree that POSIX 2004, on the page for time http://www.opengroup.org/onlinepubs/009695399/utilities/time.html, states in the non-normative Rationale: "In the KornShell, time is a shell reserved word that can be used to time an entire pipeline, rather than just a simple command. The POSIX definition has been worded to allow this implementation." However, it is also specific in the Description that time's behavior is only defined when applied to the sole command within a grouping command. And in XCU 2.4 Reserved Words, time is not listed, not even as an optional reserved word. Furthermore, in XRAT C.2.4, it states "The list of unspecified reserved words is from the KornShell, so conforming applications cannot use them in places a reserved word would be recognized. This list contained time in early proposals, but it was removed when the time utility was selected for the Shell and Utilities volume". In short, I see no normative statement allowing time to still be a reserved word. Should we file an interpretation request with POSIX to see whether time should be allowed as a reserved word in XCU 2.4? > > I can't reproduce this. The difference between my example and yours in `set +o posix' is due to bash 2.05b vs. 3.0. However, both environments had the same bug in `set - -o posix', if you assume that time is not allowed to be a reserved word... > > 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 ...then right here, if time is not a reserved word, it should have echoed hi, rather than timing true. > > Source is not a reserved word. Oops, misread my notes when composing the email; I was looking at discepencies between bash and POSIX on two lists - regular built-ins and special builtins. I should have said that source is the only special builtin not listed by POSIX XCU 2.14, but that I was okay with it because source is not a POSIX-specified utility, and because it is a synonym to the special builtin `.'. > > 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. I disagree that failing to find a path when CDPATH is fatal - there are existing implementations that follow POSIX, so bash should too. $ echo $BASH_VERSION 3.00.16(1)-release $ cd /tmp $ mkdir -p a/aa $ ln -s a b $ set +o posix $ CDPATH=a cd b # bash in non-POSIX mode supports implicit '.' $ cd - $ set -o posix $ CDPATH=a cd b # bash in POSIX mode is non-compliant bash: cd: b: No such file or directory $ zsh % CDPATH=a cd b # zsh in zsh mode supports implicit '.' % emulate sh % CDPATH=a cd b # zsh in POSIX mode supports implicit '.' >>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? OK, I concede your interpretation is valid. POSIX XCU 1.13 only states that "Regular Built-In Utilties are frequently provided in built-in form", but that section does not require them to be provided that way; only that those utilities always be successfully found without having to search PATH. Further requirements on some of those utilities, such as cd setting PWD and changing the current directory in the calling context, are most easily implemented as a built-in; but you are right that newgrp is allowed the behavior of always being a subprocess, so that it does not have to be a builtin if the subprocess can still meet all the individual requirements on the utility. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHIP784KuGfSFAYARAp03AJ4rIS8Gnn3NJmasGyZlLL9OkVdIbwCfTxV0 QFEV8ftk88tIJr5KbjbxJDY= =4Qhi -----END PGP SIGNATURE----- _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
