[32409] in Perl-Users-Digest
Perl-Users Digest, Issue: 3676 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 24 11:09:28 2012
Date: Tue, 24 Apr 2012 08:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 24 Apr 2012 Volume: 11 Number: 3676
Today's topics:
Re: A Design Pattern Question for Functional Programers <tzz@lifelogs.com>
Re: First Commercial Perl Program <xhoster@gmail.com>
Re: First Commercial Perl Program <ben@morrow.me.uk>
hello <soniababy@compgroups.net/>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Optionally avoid AutoLoader <ben@morrow.me.uk>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Optionally avoid AutoLoader <ben@morrow.me.uk>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Perl on a Mac <hacker@ace158.com>
Re: Perl on a Mac <jurgenex@hotmail.com>
Tied hash: Differentiating between assignment of single <bew_ba@gmx.net>
Re: Using symbolic references to invoke package methods <rweikusat@mssgmbh.com>
Re: Why does this code works without cat ? <whynot@pozharski.name>
Re: Why does this code works without cat ? <ben@morrow.me.uk>
Re: Why does this code works without cat ? (Tim McDaniel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 24 Apr 2012 09:44:04 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <87wr551byz.fsf@lifelogs.com>
On Fri, 20 Apr 2012 13:55:05 -0700 (PDT) ccc31807 <cartercc@gmail.com> wrote:
c> On Apr 20, 7:59 am, Jürgen Exner <jurge...@hotmail.com> wrote:
>> Do you mind explaining how you got the idea that Perl is a functional
>> programming language?
>> After you do I may even click on that link which you dumped into this
>> NG.
c> 'Higher Order Perl' by Mark Jason Dominus.
You can program Perl with FP idioms and enjoy it, but Perl is definitely
not a FP language. It doesn't have proper closures, for instance.
Ted
------------------------------
Date: Mon, 23 Apr 2012 19:36:53 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: First Commercial Perl Program
Message-Id: <4f9611e1$0$6432$ed362ca5@nr5-q3a.newsreader.com>
On 04/23/2012 01:33 PM, tbb!/fbr! wrote:
> I need to reread through this entire thread again, because there is some
> learning here for me.
>
> I'm working on another project now. It's a project where I read a line from
> one file (the file has multiple lines) and then check to see if a certain
> field from a second file matches. I already know how to do this with a nested
> foreach reading in a line from the first file, and then a foreach (for) to
> compare to all lines in the second file. That verbal explanation is how I
> am doing it, and after much googling, it looks like everyone else does it that
> way too. However, the datasets are HUGE (first file is 500m, the compare file
> is 1tb). Is there a more efficient way to do this?
If the second file is sorted on the column needed to do the look up, you
can do a binary search into it.
If the record length is not constant, you can still do a binary search
where you divide by offset rather than record, you just have be sure to
re-align the the line boundaries after seeking into the middle of a
line. If you are using ASCII or some other simple character set, this
is almost trivial, if you are using some other character set, it might
not be.
Xho
------------------------------
Date: Tue, 24 Apr 2012 11:44:59 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: First Commercial Perl Program
Message-Id: <bqci69-h641.ln1@anubis.morrow.me.uk>
Quoth "tbb!/fbr!" <ronaldljohnson@gmail.com>:
> On Monday, April 16, 2012 5:43:11 PM UTC-7, Ben Morrow wrote:
> > Quoth Jim Gibson <jimsgibson@gmail.com>:
> > > In article
> > > <7095990.3.1334609061053.JavaMail.geo-discussion-forums@pbcva6>,
> > > tbb!/fbr! <ronaldljohnson@gmail.com> wrote:
> > > >
> > > > $nbits[$count]=@bits[rand @bits];
> > > That should be:
> > >
> > > $nbits[$count] = $bits[rand @bits];
> >
> > ...and if you had been using 'warnings', perl would have told you so.
>
> interesting enough, i always code under strict and warnings, and perl 5.10
> on my Centos box doesn't complain with the way I've written it (does someone
> know why? as I understand it's a scalar, but again, no warnings messages
> pop up with: $nbits[$count]=@bits[rand @bits]; as opposed to:
> $nbits[$count] = $bits[rand @bits];
...you're right. This is because perl can't tell that 'rand @bits' is
supposed to be a scalar expression.
> I'm working on another project now. It's a project where I read a
> line from one file (the file has multiple lines) and then check to
> see if a certain field from a second file matches. I already know
> how to do this with a nested foreach reading in a line from the
> first file, and then a foreach (for) to compare to all lines in the
> second file. That verbal explanation is how I am doing it, and after
> much googling, it looks like everyone else does it that way too.
Well, no; the normal way of doing that would be to read the whole of the
second file into a hash, keyed by the field you are looking up on. Then
you only need one layer of loop, reading from the first file, and you
can look up records in the second directly.
> However, the datasets are HUGE (first file is 500m, the compare file
> is 1tb).
...so, that's not a good option here :). I believe Tim has already
suggested a database: that's the right answer. It's effectively an
on-disk version of the hash I just suggested. However, there's no need
to go as far as a full-blown SQL database: I would do this using
Berkeley DB. You want to use the newer version, using BerkeleyDB::Hash,
rather than the old version using DB_File, since the ability to handle
huge files didn't exist in the old version.
The alternative, if BDB can't handle your dataset or if this is still
too slow, is to split the second file into pieces. You can then read
each piece into a hash (not all at the same time, obviously), and check
the first file against that hash. If you've got multiple machines
available you can split the work between them like this: there's
probably not much point running multiple processes on a single machine,
unless it's got lots of cores and *really* good IO bandwidth.
Ben
------------------------------
Date: Mon, 23 Apr 2012 20:57:42 -0500
From: soniababy <soniababy@compgroups.net/>
Subject: hello
Message-Id: <z6ednYaQ_pYLlQvSnZ2dnUVZ_vednZ2d@giganews.com>
hi
------------------------------
Date: Tue, 24 Apr 2012 03:06:28 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <61563589-f7c8-4688-a509-9071afa171f7@a5g2000vbl.googlegroups.com>
On Apr 23, 10:30=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> You do, though :). The debugger is showing you the first ten lines of
> that logical file, which are all empty. The #line declaration means the
> actual code starts much further down.
Yes, I know, but the debugger doesn't show it, unless I *navigate* to
it (as I explained).
> Try this:
>
> =A0 =A0 - open ClearCase/Wrapper/MGi.pm in your editor,
> =A0 =A0 - find the 'describe' function in the __END__ section,
Yes, it is line 2871, as in the #line directive.
Or if you prefer, 2874, the first line of runnable code (an
assignment).
> =A0 =A0 - note the line number where it starts,
> =A0 =A0 - run the debugger, and type
> =A0 =A0 =A0 =A0 f describe.al
> =A0 =A0 =A0 =A0 l <line number in MGi.pm where &describe starts>
> =A0 =A0 =A0 =A0 l
DB<4> l 2871
DB<5> l 2874
DB<6>
> If you've loaded all the .als, I would expect you could also just use
> =A0 =A0 l ClearCase::Wrapper::MGi::describe
> which should take you to the right file and line directly.
Interesting: *that* works...
DB<6> l ClearCase::Wrapper::MGi::describe
Switching to file 'blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into
blib/lib/auto/ClearCase/Wrapper/MGi/describe.al)'.
2871 sub describe {
2872: use strict;
2873: use warnings;
2874: my $desc =3D ClearCase::Argv->new(@ARGV);
2875: $desc->optset(qw(CC WRAPPER));
2876: $desc->parseCC(qw(g|graphical local l|long s|short
2877 fmt=3Ds alabel=3Ds aattr=3Ds ahlink=3Ds ihlink=3Ds
2878 cview version=3Ds ancestor
2879 predecessor pname type=3Ds cact));
2880: $desc->parseWRAPPER(qw(parents|par9999=3Di family=3Di));
> Any benefit in what? The AutoLoader? I would say not. If you want to do
> delay-loading, there are simpler and less magical ways of doing it.
No, I meant a benefit of preloading all the .al files to restore
debuggability.
With the above note, there is one, indeed.
So far, I couldn't see any.
The point is you typically know where you want to put a breakpoint but
have no clue how you exactly reach this point. That's what you hope
the debugger will tell!
Thanks!
For somebody who doesn't use the debugger, you manage to help me
who use it every day... I feel humble.
Marc
------------------------------
Date: Tue, 24 Apr 2012 11:55:28 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <0edi69-h641.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Apr 23, 10:30 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> Yes, it is line 2871, as in the #line directive.
> Or if you prefer, 2874, the first line of runnable code (an
> assignment).
>
> > - note the line number where it starts,
> > - run the debugger, and type
> > f describe.al
> > l <line number in MGi.pm where &describe starts>
> > l
>
> DB<4> l 2871
>
> DB<5> l 2874
>
> DB<6>
Given the 'Switching to...' below, I deduce that you were in the wrong
file. Perhaps 'f describe.al' picked up ClearCase/Wrapper/describe.al
instead of .../MGi/describe.al, or something? You ought to be able to
choose the right file by being more specific, so maybe 'f
MGi/describe.al'.
> > If you've loaded all the .als, I would expect you could also just use
>
> > l ClearCase::Wrapper::MGi::describe
>
> > which should take you to the right file and line directly.
>
> Interesting: *that* works...
>
> DB<6> l ClearCase::Wrapper::MGi::describe
> Switching to file 'blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into
> blib/lib/auto/ClearCase/Wrapper/MGi/describe.al)'.
Ben
------------------------------
Date: Tue, 24 Apr 2012 04:11:02 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <cac6abf0-b09c-43bf-9c7d-984c8009c18a@b14g2000vbz.googlegroups.com>
On Apr 24, 11:55=A0am, Ben Morrow <b...@morrow.me.uk> wrote:
> Given the 'Switching to...' below, I deduce that you were in the wrong
> file. Perhaps 'f describe.al' picked up ClearCase/Wrapper/describe.al
> instead of .../MGi/describe.al, or something?
It doesn't seem so:
DB<3> f describe.al
Choosing /home/emagiro/perl/lib/auto/ClearCase/Wrapper/MGi/describe.al
matching `describe.al':
1 # NOTE: Derived from blib/lib/ClearCase/Wrapper/MGi.pm.
2 # Changes made here will be lost when autosplit is run again.
3 # See AutoSplit.pm.
4 package ClearCase::Wrapper::MGi;
5
6 #line 2871 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/
lib/auto/ClearCase/Wrapper/MGi/describe.al)"
Referencing the symbol seems to tie things up in a way that wasn't
done before...
Marc
------------------------------
Date: Tue, 24 Apr 2012 12:58:37 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <d4hi69-co41.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Apr 24, 11:55 am, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > Given the 'Switching to...' below, I deduce that you were in the wrong
> > file. Perhaps 'f describe.al' picked up ClearCase/Wrapper/describe.al
> > instead of .../MGi/describe.al, or something?
>
> It doesn't seem so:
Oh, I *see*: it's more subtle than I thought.
> DB<3> f describe.al
> Choosing /home/emagiro/perl/lib/auto/ClearCase/Wrapper/MGi/describe.al
> matching `describe.al':
> 1 # NOTE: Derived from blib/lib/ClearCase/Wrapper/MGi.pm.
> 2 # Changes made here will be lost when autosplit is run again.
> 3 # See AutoSplit.pm.
> 4 package ClearCase::Wrapper::MGi;
> 5
> 6 #line 2871 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/
> lib/auto/ClearCase/Wrapper/MGi/describe.al)"
This (logical) file, which is called
/home/emagiro/perl/lib/auto/ClearCase/Wrapper/MGi/describe.al
, ends here. The next line of code is at line 2871 of a *different*
logical file, called
blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/lib/auto/
ClearCase/Wrapper/MGi/describe.al)
(all on one line, and yes, that's a filename with brackets and spaces
in. Perl doesn't care.). It's a little irritating that the debugger has
picked up the real .al rather than the file which contains the useful
code, but there we go.
'f' takes a regex, so try 'f autosplit.*describe.al' followed by 'l
2871'.
> Referencing the symbol seems to tie things up in a way that wasn't
> done before...
The sub knows which logical file it was compiled from, so the debugger
can find it no matter what it's called.
Ben
------------------------------
Date: Tue, 24 Apr 2012 07:39:26 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <176e2d38-e88c-42dd-be2f-c253faaed6e4@z3g2000vbk.googlegroups.com>
On Apr 24, 12:58=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> 'f' takes a regex, so try 'f autosplit.*describe.al' followed by 'l
> 2871'.
Bingo. Now everything matches.
Thanks!
Marc
------------------------------
Date: Tue, 24 Apr 2012 00:09:44 +0200
From: Hacker <hacker@ace158.com>
Subject: Re: Perl on a Mac
Message-Id: <2012042400094497806-hacker@ace158com>
On 2012-04-22 11:18:42 +0000, Jürgen Exner said:
> Torsten Jørgensen <info@stconinc.com> wrote:
>> On 2012-04-22 03:51:59 +0000, Jürgen Exner said:
>>
>>> Torsten Jørgensen <info@stconinc.com> wrote:
>>>> Does it understand #!/usr/bin/perl.
>>>
>>> No, it doesn't. It doesn't on any OS because the shebang line is a
>>> function of the shell, not of Perl. Perl doesn't care about the shebang
>>> line(*).
>>
>> I know, I meant the shell...
>
> Ok.
> Sorry, I can only read what you are writing, not what you are thinking.
Piss off.
>
>>>> Can the Terminal run shell scripts.
>>>
>>> Why not?
>>
>> Except that it comes out with -bash: seek.pl: command not found
>> when I try to run this:
>>
>> #!/usr/bin/perl
>> print "Hello World";
>
> Then I would guess there is no executable program named perl at
> /usr/bin. Maybe it is not installed? Maybe it is in a different
> location? Maybe access rights are incorrect?
>
>>> *: actually there are hacks for some OSs where Perl will parse arguments
>>> from the shebang line because the command interpreter on those OSs does
>>> not recognize the shebang line.
>>
>> But OSX Lion does...
>
> That's fine. I was merely mentioning that on certain OSs there are
> exceptions to the standard behaviour of Perl.
>
>> And by the way, keep your inuendo to yourself, it is insulting.
>
> -v, please?
>
> jue
--
Get your widget out of my way.
------------------------------
Date: Mon, 23 Apr 2012 16:25:12 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl on a Mac
Message-Id: <b5pbp75p9ltpabk8k73uop8r3a6lgenpai@4ax.com>
Hacker <hacker@ace158.com> wrote:
>On 2012-04-22 11:18:42 +0000, Jürgen Exner said:
>> Torsten Jørgensen <info@stconinc.com> wrote:
>> Sorry, I can only read what you are writing, not what you are thinking.
>
>Piss off.
Thank you for confirming that "Torsten Jørgensen" had to change his ID
after only 3 postings. That must be close to a new record.
jue
------------------------------
Date: Tue, 24 Apr 2012 07:41:51 -0700 (PDT)
From: bernd <bew_ba@gmx.net>
Subject: Tied hash: Differentiating between assignment of single value and entire hash
Message-Id: <eec77a28-97ef-4e33-a836-09b09b48d9ec@35g2000yqq.googlegroups.com>
Hello folks,
I want to use Perl's tie-mechanism to configure an object
"automatically" by changing the/a hash associated with the object (in
this particular project the object will be a Tk-widget, but this is
not relevant since I am looking for a generic solution to the problem
described).
An example should illustrate the process:
#!/usr/bin/perl
package AssignTest;
use Tie::Hash;
use base qw( Tie::StdHash );
sub TIEHASH { $class = shift; $hash = {}; bless $hash, $class }
sub STORE { $self = shift; ( $key, $value ) = @_; print "$value" }
sub CLEAR { $self = shift; print "CLEAR was called!\n"; %{$_[0]} =
() }
package main;
$myobject = tie %tiedhash, 'AssignTest';
%tiedhash = ( a => "Entire ", b => "hash ", c => "assigned!\n");
print "\n-----------\n";
$tiedhash{a} = "Single ";
$tiedhash{b} = "values ";
$tiedhash{c} = "assigned!\n";
On running this script I get the following output:
CLEAR was called!
Entire hash assigned!
-----------
Single values assigned!
From the code and the output it is clear that, if the assignment takes
place in one step by assigning to the entire hash, first CLEAR is
called and then, for each key-value pair on the RHS, STORE is invoked
to actually insert the data into the hash. When one assigns a single
value to a key, STORE is called for each such an assignment, but
CLEAR, of course, not.
If the key-value-pairs used would be meaningful parameters, I could
easily configure $myobject (and trigger possible subsequent events) by
just assigning to the hash.
In my use case the additional requirement is that the object's
internal code is capable of recognizing whether the assignment was
done by assigning to the entire hash or to a single key (in the Tk-
application mentioned above EACH assignment, regardless which of the
both statement types are used, should trigger the appearance of the
freshly configured widget on the screen).
From the invocation of the CLEAR-method the object "knows" when an
assignment to the entire hash was started, but how can it detect when
this assignment is complete ("complete" in the sense that all calls to
STORE associated with the hash assignment are done)? Because what
follows upon the CLEAR is this sequence of calls to STORE. One or more
single value assignments following the assignment to the entire hash
will trigger STORE as well, and, at least my limited insight into the
process gives me no clue on how one could differentiate between calls
to STORE triggered by the assignment to the entire hash and single
value assignments resp.
If the object's code would be aware of the number of key-value-pairs
on the RHS of the hash assignment, then this job would be easily done
(by letting STORE count how often it was called after a CLEAR, but
AFAIK, the object is not aware of this figure).
Any ideas?
Greetz
Bernd
P.S.: Yes, I know about "use strict". :->>
------------------------------
Date: Tue, 24 Apr 2012 15:09:52 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Using symbolic references to invoke package methods - good or bad practice?
Message-Id: <87d36xmdan.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>>> I understood perfectly: the map runs one loop, which builds a temporary
>>> list, and the for runs another which consumes it. I see the temporary
>>> storage required as more of a 'problem' than the two loops:
>>>
>>> the two loops perform the same steps as one would have, they just do
>>> them in a different order.
>>
>> They don't. That was what I was writing about. The additional steps
>> are the operations required to perform the second loop. This implies
>> that using map in this way has twice the looping overhead of a loop
>> which does the transformation 'inline'.
>
> Oh, I see; yes, I suppose that's true, but if you've got to the point of
> worrying about the overhead of the for or map loop itself you shouldn't
> be writing in Perl any more. If you need that level of efficiency, you
> need to do it in C.
Once upon a time the past, there was a guy called Rasumus Lehrdorf who
had a homepage. He tried to pep it up a little by adding various CGI
scripts written in Perl to it but somehow, he couldn't get his Perl
code to perform adequately. So, he then set off and wrote a simple HTML
preprocessor in C which he christened the Personal HomePage tools
and published them on the net (and the rest - as they say - is history
...).
I use Perl serious system programming tasks and because of this, I
absolutely do care about the performance of the Perl code I write: I'm
fine with burning cycles in exchange for some tangible benefit, eg,
aggressively partition code into subroutines in order to make it
easier to maintain _intermittently_ (I'm not living inside some huge
body of code written by no-one-knows-who where I wander around in
order to explore it so that I can occasionally make minor changes
without breaking something. The typical situation is rather that I
need to add a new, not entirely trivial feature to something I haven't
seen for 20 months and preferably quickly). I'm not at all keen on
burning cycles just because I can do so easily.
In this particular case, using a somewhat silly simple example,
------------
#!/usr/bin/perl
use Benchmark;
sub wmap {
my @out;
push(@out, $_) for map { $_ + 1; } @_;
return @out;
}
sub nmap {
my @out;
push(@out, $_ + 1) for @_;
return @out;
}
timethese(-10,
{
wmap => sub { wmap(1 .. 5); },
nmap => sub { nmap(1 .. 5); }});
-------------
the variant using map needs to execute four more ops per input element
and the other, the actual counts (perl -MO=Concise,-exec) being 13 and
9, respectively, and the corresponding quotient appears also in the
measured execution speed: The subroutine which has about 1.44... times
more elementary operation runs at about 1/(1.4) of the speed of the
other.
------------------------------
Date: Tue, 24 Apr 2012 10:07:38 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjpck9q.4hi.whynot@orphan.zombinet>
with <fm6g69-l9m.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
> Quoth Eric Pozharski <whynot@pozharski.name>:
>> And zsh wins!
> Define 'wins'. If you mean 'produces a confusing and unexpected result
> as a consequence of trying to be too clever', then yes, I agree.
If that would be addressed to some weak mind, then such mind would spill
something along the lines "OH YOU *ARE* SO CONFUSED!!ONEONE". But I
don't think you're confused. You're trolling, read below.
*SKIP* [[ that's irrelevant already ]]
> foo 3>&2 2>&1 >&3 3>&- | bar
Wait a second. If that thread would have anything like a goal-post,
that would clearly constitute goal-post moving. All that in skipped had
nothing to do with redirecting *output*. We were talking redirecting
input.
cat /etc/passwd /etc/group | wc
wc </etc/passwd </etc/group
wc /etc/passwd /etc/group
That should prduce same result, shouldn't it?
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Tue, 24 Apr 2012 11:48:49 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Why does this code works without cat ?
Message-Id: <h1di69-h641.ln1@anubis.morrow.me.uk>
Quoth Eric Pozharski <whynot@pozharski.name>:
>
> cat /etc/passwd /etc/group | wc
> wc </etc/passwd </etc/group
> wc /etc/passwd /etc/group
>
> That should prduce same result, shouldn't it?
No, it shouldn't. If the final redirection involving fd 0 is
'</etc/group' then fd 0 should end up attached to /etc/group, not to a
pipe from some random process that might happen to produce the data in
/etc/group at some point.
Ben
------------------------------
Date: Tue, 24 Apr 2012 14:20:42 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Why does this code works without cat ?
Message-Id: <jn6crp$3ed$1@reader1.panix.com>
In article <slrnjpck9q.4hi.whynot@orphan.zombinet>,
Eric Pozharski <whynot@pozharski.name> wrote:
>with <fm6g69-l9m.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
>> foo 3>&2 2>&1 >&3 3>&- | bar
>
>Wait a second. If that thread would have anything like a goal-post,
>that would clearly constitute goal-post moving. All that in skipped
>had nothing to do with redirecting *output*. We were talking
>redirecting input.
I'm sorry. I had not realized that we're not allow to discuss
redirecting output. Thank you for clarifying.
> cat /etc/passwd /etc/group | wc
> wc </etc/passwd </etc/group
> wc /etc/passwd /etc/group
>
>That should prduce same result, shouldn't it?
Leaving aside whether the model of redirection should have automatic
catting (zsh, you say) or just overriding (sh, bash), "wc" when given
file names produces one line of output per file and each line includes
the filename, and if it has more than one filename argument, it adds a
line of totals.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3676
***************************************
