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 _______________________________________________ Bug-sh-utils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-sh-utils
