AW: Problem Bug in shell builtin" test -f" or "test -e"

[Kess Peter]

Hello,

many thanks for your quick answer.
I can see also that it's a bug in the scripts.

So we have to change them.

I have never get such a detailled and answer from sco if i had a support
quuestion in the past time.
So keep up your very good working.

Thx again and bye from Germany

Regards
Peter Kess



-----Ursprungliche Nachricht-----
Von: Bob Proulx [mailto:address@hidden
Gesendet: Donnerstag, 9. Oktober 2003 07:17
An: Kess Peter
Cc: address@hidden
Betreff: Re: Problem Bug in shell builtin" test -f" or "test -e"


Kess Peter wrote:
> i have a customer where i migrate a large database from unixware to
> linux( suse open enterprise 8) but it also happens in Suse 7.3
Professional.
> Our customer uses "test -f" whithin thousands of scripts.
>
> But if i use "test -f    " with no additional parameter it comes back with
> exit status 0.
> And I think this is not ok.

First, thanks for reporting your problem.  It is always appreciated
when people report bugs.  That is the only way to get them fixed.  But
in this case I don't think what you are seeing is a bug.

I see your point because when I look at classic old commercial systems
I can see the same behavior.  But I the problem is that those old
systems are not standards conforming.  At some point in the future
when they do become standards conformant then this will also be their
behavior as well.  Best to write scripts which can handle either case.

> Here are some shell examples:
>
> pknblx:/tmp # test -f
> pknblx:/tmp # echo $?
> 0
> ##################################
> pknblx:/tmp # test -f ANYFILE
> pknblx:/tmp # echo $?
> 1

Agreed.

> The same command on Sco Unixware 7.1.1:
> # test -f
> UX:test: FEHLER: Argument erwartet
> # echo $?
> 1

Please read the standards documentation here, specifically the
following section.

  http://www.unix-systems.org/single_unix_specification_v2/xcu/test.html

    The algorithm for determining the precedence of the operators and
    the return value that will be generated is based on the number of
    arguments presented to test. (However, when using the [...] form,
    the right-bracket final argument will not be counted in this
    algorithm.)

    In the following list, $1, $2, $3 and $4 represent the arguments
    presented to test.

    0 arguments:
        Exit false (1).
    1 argument:
        Exit true (0) if $1 is not null; otherwise, exit false.
    2 arguments:
        * If $1 is "!", exit true if $2 is null, false if $2 is not null.

        * If $1 is a unary primary, exit true if the unary test is
          true, false if the unary test is false.

        * Otherwise, produce unspecified results.

    [...and so on for other numbers of arguments...]

My reading of this says that 'test -f', which has only one argument
("-f") and that argument is not null, is required to exit 0.

> I have made a workaround with a shellscript "test" but I think this is not
> performant.

But surely test is a built-in to the shell.  Therefore you cannot
create a shell script 'test' and have it be called since the built-in
routine of the /bin/sh shell will be the actual one which will be called.

Also surely any actual use of 'test -f' with no further arguments when
used as a test for a file is a bug in the script?  Isn't it a bug in
both cases?  But just that in the case of a standard conformant
implementation you don't see this bug?

The design of the wording of the standard is meant to handle this next
case.  Assume that $1 in the next case is "-f" and you can see how in
the older shells this would cause a script bug to appear.

  #!/bin/sh
  if test $1
  then
    echo argument is not null
  else
    echo argument is null
  fi

That case in the older shells is prone to problems if the parameter
looks like an option to test or if it is missing entirely.  In the
older systems this is a bug in the code of the shell script.  But the
intention of scripts using that style of programming is actually to
test that the variable is of non-zero length.  (Of course a better
paradigm is to use 'test -n "$1"' in that case but so it is.)  The
standard was worded to make the above case, which was quite often seen
in scripts, more robust when various inputs would otherwise expose
bugs in scripts.  So while that used to be a script bug in the old
days it is now no longer a script bug because the shell is supposed to
handle that differently in a standards conformant shell.

Just to clarify things a little bit.  /usr/bin/test is a utility
included in coreutils package.  But 'test' is normally a built-in
routine of the shell.  Assuming you are using /bin/sh linked to
/bin/bash as your shell then the test you are actually seeing in your
script is really the 'test' that is part of the bash shell.  The
/usr/bin/test standalone has almost identical behavior but not quite.

  type test
  test is a shell builtin

  test --version
  [...no output...]

  /usr/bin/test --version
  test (GNU sh-utils) 2.0.11

This mailing list is devoted to the standalone program and not the
shell version.  Confusing I know.  But that is okay since I think the
answer is the same regardless.

Hope that helps.

Bob