On 1/23/19 6:23 PM, Colin Watson wrote:
> On Wed, Jan 23, 2019 at 06:09:39PM +0100, Alex Mestiashvili wrote:
>> On 1/23/19 5:31 PM, Colin Watson wrote:
>>> On Wed, Jan 23, 2019 at 05:23:10PM +0100, Alex Mestiashvili wrote:
>>>> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
>>>>> I agree that it would be better to drop this "feature" of Perl.
>>>>> It is probably never used, and probably useless (I would rather
>>>>> use the features from the shell if I need a pipe).
>>>>
>>>> Perl's open is well documented. Quoting the perlipc:
>>>>
>>>> "it's much more efficient to process the file one line or record at a
>>>> time because then you don't have to read the whole thing into memory at
>>>> once."
>>>
>>> This is a red herring. Prepending a pipe to a perl command doesn't
>>> require reading the whole thing into memory.
>>
>> Well, this is not never used and is not useless. I just provided a quote
>> pointing to a use case. Deciding if that is useful or not is up to you.
>
> Ah, I see. I think it would have been clearer what you meant with a bit
> more context, so here it is for others:
>
> If one can be sure that a particular program is a Perl script
> expecting filenames in @ARGV, the clever programmer can write
> something like this:
>
> % program f1 "cmd1|" - f2 "cmd2|" f3 < tmpfile
>
> and no matter which sort of shell it's called from, the Perl
> program will read from the file f1, the process cmd1, standard
> input (tmpfile in this case), the f2 file, the cmd2 command,
> and finally the f3 file. Pretty nifty, eh?
>
> You might notice that you could use backticks for much the same
> effect as opening a pipe for reading:
>
> print grep { !/^(tcp|udp)/ } `netstat -an 2>&1`;
> die "bad netstatus ($?)" if $?;
>
> While this is true on the surface, it's much more efficient to
> process the file one line or record at a time because then you
> don't have to read the whole thing into memory at once. It
> also gives you finer control of the whole process, letting you
> kill off the child process early if you'd like.
>
> (In this case, my argument is with the documentation not pointing out in
> this particular spot what the problems are with this approach.)
>
Indeed, my answer was kind of misleading without looking into the man page.
Thanks for correcting.
