Prev: Rotation of logs
Next: Processing 100 output files
From: Janis on 24 Feb 2010 05:48
On 24 Feb., 00:13, pk <p...(a)pk.invalid> wrote:
> Seebs wrote:
> > I actually did find a fascinating example of a Useful Use of Cat:
>
> > cat "$@" | <command>
>
> > This converts a plain filter which only works on standard input to a smart
> > filter which accepts standard input or a list of files.  (Assuming a
> > reasonably modern shell, say, one from the last decade or two.)
>
> That is mentioned in the "Useful Use of Cat" page, which you might be
> interested in:
>
> http://www.in-ulm.de/~mascheck/various/uuoc/
>
> where it appears as
>
> cat ${1+"$@"} | command


Quoting from the above referenced page...


>> * here documents (force as-is output, if there are character
>> sequences which are special to echo(1), and if printf(1) is
>> not available)
>>
>> cat<<EOF
>> $VARIABLE
>> EOF

Mind that this is only displaying the template in the here-document,
and it is in this form redirected to create a file.

cat <<EOF >the_template
$VARIABLE
EOF

Otherwise, if some application would do some processing of the data,
say

cat <<EOF | awk '...'
$VARIABLE
EOF

this would again be a useless use of cat since you'd instead just do

awk '...' <<EOF
$VARIABLE
EOF


>> * convert file content into arguments
>>
>> cmd `cat file`
>> for i in `cat file`; do ...+

Just note that a (non-standard) way supported by modern shells is to
avoid (potentially) superfluous processes (cat, subshell) by opening
the file directly, using the notation

cmd $(< file )

which makes a cat process useless (depending on the requirements,
of course).


>> * largefile problems (Darren Dunham in c.u.s)
>>
>> cat file | cmd
>> A workaround for commands which have been compiled without
>> largefile support but accept a pipe, e.g. compressing
utilities.

I am puzzled about this one. Why is it a problem for (some?)
compression programs to read the file from a non-pipe stdin
channel, as in

cmd <file


Janis
From: pk on 24 Feb 2010 13:25
Janis wrote:

> >> * largefile problems (Darren Dunham in c.u.s)
> >>
> >> cat file | cmd
> >> A workaround for commands which have been compiled without
> >> largefile support but accept a pipe, e.g. compressing
> utilities.
>
> I am puzzled about this one. Why is it a problem for (some?)
> compression programs to read the file from a non-pipe stdin
> channel, as in
>
> cmd <file

I suppose the "< file" trick works with at most one file; if you have many
large files, you'd need "cat file1 file2 ... fileN | command", assuming cat
supports large files, which it seems to do in all implementations (?).
From: pk on 24 Feb 2010 13:44
Janis Papanagnou wrote:

> pk wrote:
>> Janis wrote:
>>
>>> >> * largefile problems (Darren Dunham in c.u.s)
>>> >>
>>> >> cat file | cmd
>>> >> A workaround for commands which have been compiled without
>>> >> largefile support but accept a pipe, e.g. compressing
>>> utilities.
>>>
>>> I am puzzled about this one. Why is it a problem for (some?)
>>> compression programs to read the file from a non-pipe stdin
>>> channel, as in
>>>
>>> cmd <file
>>
>> I suppose the "< file" trick works with at most one file; if you have
>> many large files, you'd need "cat file1 file2 ... fileN | command",
>> assuming cat supports large files, which it seems to do in all
>> implementations (?).
>
> I thought the point of the suggestion had been _one_ large file?

Yes, I agree that in the case of a single file using "< file" would be fine
(again, assuming the shell supports opening large files!)

 | 
Pages: 1
Prev: Rotation of logs
Next: Processing 100 output files