----- Original Message -----
From: "Bob Proulx" <[email protected]>
Laurent TARRISSE wrote:
Just let me explain... we had to reuse unix scripts, primarily
written for HP UX
>uname -a
HP-UX ppbmo B.11.23 U ia64 3204054692 unlimited-user license
Some of our scripts, who did function perfectly on HP-UX for several
years, encountered problems once moved on Linux platform.
One reason is due to dirname : on HP UX I can give several arguments
to dirname, and as you say, on Linux I cannot. That's all. ;)
On HP-UX if you give several option arguments to dirname then the
HP-UX dirname would handle the first argument and then return an
error due to the extra arguments. See this example:
$ /usr/bin/dirname /one/two/three /four/five /six/seven
/one/two
$ echo $?
1
$ /usr/bin/dirname /one/two/three
/one/two
$ echo $?
0
It is an error on HP-UX dirname to supply extra arguments too. But
your scripts must be ignoring the error. GNU dirname is simply
reporting the error more loudly. :-)
Yes, my script doesn't care about the return code.
I use the dirname to extract the path from a given file, and then
do a 'cd' command to that path :
MY_PATH=`dirname $1`
cd $MY_PATH
As you say, HP-UX dirname returns 1, but neveetheless outputs the path
of the first argument, and it's just what I expected him to do ! :))
What is your script expecting to happen with the extra arguments?
Surely that would also be a bug in your script since those extra
arguments are not getting processed.
No because my script is less or more something equal to the FTP 'put' or
'mput' commands : you give it a file name as an argument, this file name can
contain a wildcard, so it can actually match several files of the
filesystem.
The 'bug' appeared on Linux, because dirname doesn't output the path when
several arguments are passed to it. :))
Bob
