Nirbheek Chauhan wrote:

> On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein <> wrote:
>> Nirbheek Chauhan wrote:
> [snip]
>>> commands that die:
>>> everything that is implemented as a function (, eclasses, etc)
> [snip]
>> Technically the rule is that eclasses shouldn't die. At least that's the
>> latest version of the rules that I remember.
> eclasses shouldn't die or functions inside eclasses shouldn't die? I
> meant the latter:
> s/(
The only technical reason not to allow an --or-die (or the equivalent)
switch for everything is the issues with subshell die, for which I sent
some script to test but didn't hear back about, but more cogently that old
GNU heads think xargs is necessary as GNU find didn't implement -exec
correctly (according to POSIX) until a couple of years ago.

In BASH, one would use the equivalent loop (which will cope with any
while read -rd '' f; do foo --or-die "$f"; done < <(find .. -print0)

I usually show newbs this:
while read -rd ''; do arr+=("$REPLY"); done < <(find .. -print0)
..since it shows a bit more about read and gives the other usual

This is compatible with the old broken GNU find as well as BSD, but -print0
is not required by POSIX.

I'm sure I've used that in a function somewhere amongst one of the patches I
filed with someone or the other. TBH a professional BASH scripter would
sneer (I can think of several) at needing to wrap it in a function: it's
like not knowing how to read a file line-by-line in POSIX sh.

Put it this way: if you actually need the filenames, or some other
information elsewhere in the script[1], chances are that the loop has more
meat to it.

I suppose you could pass directories and params for a find command/API
function, eg:
findE --or-die foo dirA/b dirC/d ! \( -type -l -o -name '*~' \)
..or the like, showing --or-die first for consistency but it could of course
come anywhere.

[1] /msg greybot faq disappear

Reply via email to