test command differences between IRIX and Linux

test command differences between IRIX and Linux

Post by Jim Britai » Sat, 29 Jan 2005 21:26:50



I've been living fat dumb and happy, using Bourne Shell, and under
IRIX  for the past 10 years or so.

Now, I'm having to migrate shell scripts to Fedora Linux, and have run
into a problem.

In several places I have used the test command to test for readable
file existence in a directory, and if  readable files are there,
continue processing, else stop, reporting the empty directory  to the
operator.

sample code:
[ -r [1-9]* ] || echo "No files in the upload directory"
[ -r * ] || echo "No files in transfer directory"
[ -r [1-9]* ] && cp [1-9]* /$ARTICLES

Under IRIX, this works properly.  Under Bash/Linux coreutils test
command, it bombs out with completely unwanted extra help, without
providing a result.

How would I test one or more readable files in a directory under Bash,
using the standard test operator.  I can work with having to backslash
the internal brackets, but not the extra *from a command that is
supposed to return a boolean result.

Right now, I'm a little too pissed off to see the simple solution, or
workaround to how I think the world should be.  Naturally, this is
crunch time.

Jim

 
 
 

test command differences between IRIX and Linux

Post by Kevin Rodger » Sun, 30 Jan 2005 00:24:26


 > I've been living fat dumb and happy, using Bourne Shell, and under
 > IRIX  for the past 10 years or so.
 >
 > Now, I'm having to migrate shell scripts to Fedora Linux, and have run
 > into a problem.
 >
 > In several places I have used the test command to test for readable
 > file existence in a directory, and if  readable files are there,
 > continue processing, else stop, reporting the empty directory  to the
 > operator.
 >
 > sample code:
 > [ -r [1-9]* ] || echo "No files in the upload directory"
 > [ -r * ] || echo "No files in transfer directory"
 > [ -r [1-9]* ] && cp [1-9]* /$ARTICLES
 >
 > Under IRIX, this works properly.  Under Bash/Linux coreutils test
 > command, it bombs out with completely unwanted extra help, without
 > providing a result.
 >
 > How would I test one or more readable files in a directory under Bash,
 > using the standard test operator.  I can work with having to backslash
 > the internal brackets, but not the extra *from a command that is
 > supposed to return a boolean result.

The [ -r FILE ] test command only accepts a single file, so presumably
the problem occurs when the wildcard expands to more than 1 file.  (When
there are no files, the file name pattern should be passed verbatim and
the test should quietly fail.)

To simply test for the presence of any files, you could do something
like:

`ls * > /dev/null 2>&1` || echo "No files in the upload directory"

Or to actually verify that they're all readable before copying them:

`sed -n '1p;q' [1-9]* > /dev/null 2>&1` && cp [1-9]* /$ARTICLES

--
Kevin Rodgers

 
 
 

test command differences between IRIX and Linux

Post by Dan Merce » Sun, 30 Jan 2005 01:02:55


:
: I've been living fat dumb and happy, using Bourne Shell, and under
: IRIX  for the past 10 years or so.
:
: Now, I'm having to migrate shell scripts to Fedora Linux, and have run
: into a problem.
:
: In several places I have used the test command to test for readable
: file existence in a directory, and if  readable files are there,
: continue processing, else stop, reporting the empty directory  to the
: operator.
:
: sample code:
: [ -r [1-9]* ] || echo "No files in the upload directory"
: [ -r * ] || echo "No files in transfer directory"
: [ -r [1-9]* ] && cp [1-9]* /$ARTICLES
:
: Under IRIX, this works properly.  Under Bash/Linux coreutils test
: command, it bombs out with completely unwanted extra help, without
: providing a result.

The portable way:

    { for file in *;do [ -r $file ]  && break;done; } || echo "No files in transfer directory"

Modern shells may *on getting to many args to test -[aefrwx]

Dan Mercer

:
: How would I test one or more readable files in a directory under Bash,
: using the standard test operator.  I can work with having to backslash
: the internal brackets, but not the extra *from a command that is
: supposed to return a boolean result.
:
: Right now, I'm a little too pissed off to see the simple solution, or
: workaround to how I think the world should be.  Naturally, this is
: crunch time.
:
:
:
: Jim
: