Re: real LSB compliance

[andrew@pimlott.ne.mediaone.net (Andrew Pimlott)]

On Mon, Jul 02, 2001 at 08:24:03PM -0400, Theodore Tso wrote:
> Umm... where does it say that it's OK to use bashisms?

    GNU exceptions to certain standards exist, and in such
    instances, the GNU method is preferred.

(http://www.linuxbase.org/spec/gLSB/gLSB/stdshell.html) seems to say
that.  After reading chapter 15 for the third time, I think I see
what it's really trying to say, but it's very confusing.  It (like
other sections that I have spot-read) looks like it was written by
someone who was not sure exactly what he was trying to communicate,
and who doesn't speak English natively.  Also, 

> In the init
> functions section it states that the *distribution* *provided*
> *aliases* may take advantage of bash extensions, the init.d functions
> provided by LSB-compliant applications should only depend on POSIX.2
> /bin/sh features.

the fact that this is discussed in multiple sections doesn't speak
well for the unity of the whole document.  As this case shows, these
deficiencies make it difficult to review and discuss the standard.

I know you're pressed for time, but I think a thorough proofing
would serve you well.

[ Was going to end here, but I feel guilty about not saying anything
constructive. ]

Chapter 15, "Introduction" should simply say, "The shell is
POSIX-1003.2 with the following exceptions".  A word indicating that
the reason is to accomodate the established behavior of GNU Bash is
fine.

"Standard Shell Exception: pathname of $0" is wrong, as far as I can
tell.  I created the following program,

    #include <stdio.h>
    int main(int argc, char **argv) { printf("%s\n", argv[0]); }

compiled it as "argv0", and put it in my path.  When I run "sh -c
argv0", it prints argv0.  Perhaps the author was trying to get at

  2. When a subshell is created to execute a shell script with execute
     permission, but without a leading `#!', Bash sets `$0' to the full
     pathname of the script as found by searching `$PATH', rather than
     the command as typed by the user.

(from the Bash documentation)?  At any rate, he is confusing $0 in
the shell and argv[0].  Also, the example code snippets are
gibberish, and the second one uses a command "realpath" that does
not appear to be specified in the LSB.

"Standard Shell Exception: sourcing non-executable files" is also
wrong.  bash will find an unreadable file in the PATH, but will fail
when trying to run it.  Also, the "executable and not readable" case
is irrelevant.  It should say something like, "If there is a
unreadable file in the PATH, the behavior is undefined".  It should
not require non-standard behavior.  (The Bash docs say something
about this right below the above excerpt, but they appear to be
inaccurate.)

My experiments were done on Debian "testing".

Andrew