Re^2: Writing unix-style filters

Shell expansion means having all the filenames on one big line, which invalidates most of the methods suggested above and can be a real PITA if filenames contain spaces (which is likely, as opposed to newlines). Moreover, there can be a limit on the size of the command line for a command (echo in this case) and ls is able to list contents of directories as well as expanded wildcards.

I think that your suggestion is more effective when the shell expansion is used directly on the command line of my_script.pl, like this:

my_script.pl *.txt
[download]

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

Comment on Re^2: Writing unix-style filters Select or Download Code

Replies are listed 'Best First'.
Passing list long enough for shell expansion to fail, but not for "find \| xargs" (was: Re: Writing unix-style filters) by parv (Parson) on Apr 11, 2007 at 11:32 UTC
O' darn it! Use "find ... -print0 \| xargs -0 ..." construct already! In particular (slightly formatted) ... find -- walk a file hierarchy . . . -print0 This primary always evaluates to true. It prints the pathname of the current file to standard output, followed by an ASCII NUL character (character code 0). xargs -- construct argument list(s) and execute utility . . . -0 Change xargs to expect NUL (``\0'') characters as separators, instead of spaces and newlines. This is expected to be used in concert with the -print0 function in find(1). Above construct may still fail, on behalf of xargs (see the bottom portion, just after options, of above linked man page), say, if there are "many enough" files. A search on Google Groups produced "maximum command line length <tcsh>".	[reply]
Re: Passing list long enough for shell expansion to fail, but not for "find \| xargs" (was: Re: Writing unix-style filters) by polettix (Vicar) on Apr 11, 2007 at 14:47 UTC
IIRC, there are versions of xargs that call the program multiple times with "chunks" of input if a single command line is too big. Whether this is good for you depends entirely on the application you're writing. In this case, anyway, I don't fully get the rationale to use `find ... \| xargs ...` when one can make `my_script.pl` read filenames directly from standard input. Moreover, setting `$/ = "\x00"` should do the trick to tandem with `find -print0`. Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply] [d/l] [select]

Replies are listed 'Best First'.
Passing list long enough for shell expansion to fail, but not for "find \| xargs" (was: Re: Writing unix-style filters) by parv (Parson) on Apr 11, 2007 at 11:32 UTC
O' darn it! Use "find ... -print0 \| xargs -0 ..." construct already! In particular (slightly formatted) ... find -- walk a file hierarchy . . . -print0 This primary always evaluates to true. It prints the pathname of the current file to standard output, followed by an ASCII NUL character (character code 0). xargs -- construct argument list(s) and execute utility . . . -0 Change xargs to expect NUL (``\0'') characters as separators, instead of spaces and newlines. This is expected to be used in concert with the -print0 function in find(1). Above construct may still fail, on behalf of xargs (see the bottom portion, just after options, of above linked man page), say, if there are "many enough" files. A search on Google Groups produced "maximum command line length <tcsh>".	[reply]
Re: Passing list long enough for shell expansion to fail, but not for "find \| xargs" (was: Re: Writing unix-style filters) by polettix (Vicar) on Apr 11, 2007 at 14:47 UTC
IIRC, there are versions of xargs that call the program multiple times with "chunks" of input if a single command line is too big. Whether this is good for you depends entirely on the application you're writing. In this case, anyway, I don't fully get the rationale to use `find ... \| xargs ...` when one can make `my_script.pl` read filenames directly from standard input. Moreover, setting `$/ = "\x00"` should do the trick to tandem with `find -print0`. Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply] [d/l] [select]