bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test binary


From: Bob Proulx
Subject: Re: test binary
Date: Fri, 22 Jul 2005 11:50:06 -0600
User-agent: Mutt/1.5.9i

Brian answered your question but did not CC you on the reply so I
doubt you saw the followup.  Therefore I am forwarding it to you.

Bob

Brian Dessent wrote:
> Kenneth J Vojtech wrote:
> 
> > In zLinux for o/s390 (SuSe v 8 64 bit) is a binary 'test' that we use to
> > test for the existence of files.  One of our tests uses a wildcard to check
> 
> You are probably using the bash builtin command 'test' here and not the
> binary /bin/test that is a part of coreutils.  Use the command "type
> test" to see if this is the case.  That does not change the nature of
> your problem, though.
> 
> > for any *.hdr files in a certain directory.  When there is more than one
> > *.hdr file in this directory, the test fails with an exit 2, so we are not
> > processing any files.  Is there an option that will allow the test command
> > to end with exit 0 if multiple files are found?  Or is this a bug?
> 
> This is how 'test -e' is designed to work, that is, to take a single
> filename to test for existence.  When you use a wildcard, the shell
> first expands that into multiple arguments before invoking the command,
> which has no idea that a wildcard was ever involved.  All it knows is
> that where it expected a single thing it got more than one, e.g. "test
> -e 123.hdr 456.hdr", which is not valid syntax.
> 
> I suggest that you use something like the following to see if one or
> more files matching a wildcard are present:
> 
> test x`find . -maxdepth 1 -name \*.hdr -printf yes -quit" = xyes
> 
> This invokes find to search the directory '.' for files matching *.hdr. 
> Because we want find to do the searching and not the shell, the *
> wildcard must be quoted so that the shell doesn't expand it as above. 
> -maxdepth 1 causes find not to recurse into subdirectories.  When it
> finds the first file matching that pattern it will print "yes" and exit
> without further work.  If no such file is found it will print nothing,
> which is why both arguments to '=' are prefixed with 'x'.  Otherwise,
> test would be called as "test = yes" on a non-match which is invalid
> syntax -- the left hand side argument is missing.  You could skip the
> -printf and test the output against the empty string, but then if one of
> the found files had a space in its name you would end up invoking test
> with invalid syntax.  You could play quoting games to get around that
> but I find using -printf to be simpler.  YMMV.
> 
> Brian
> 
> 
> _______________________________________________
> Bug-coreutils mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-coreutils
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]