[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More bash POSIX-compliance bugs

From: Eric Blake
Subject: Re: More bash POSIX-compliance bugs
Date: Wed, 23 Feb 2005 06:24:12 -0700
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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.
$ 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             address@hidden
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]