[32410] in Perl-Users-Digest
Perl-Users Digest, Issue: 3677 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 25 16:09:25 2012
Date: Wed, 25 Apr 2012 13:09:07 -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 Wed, 25 Apr 2012 Volume: 11 Number: 3677
Today's topics:
Re: A Design Pattern Question for Functional Programers (Randal L. Schwartz)
Re: A Design Pattern Question for Functional Programers <tzz@lifelogs.com>
delete object <nospam.gravitalsun@hotmail.com.nospam>
Re: delete object <willem@toad.stack.nl>
Re: delete object (Tim McDaniel)
Re: delete object <ben@morrow.me.uk>
Re: delete object (Tim McDaniel)
Re: delete object <ben@morrow.me.uk>
Re: delete object <rweikusat@mssgmbh.com>
Re: delete object <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: delete object <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: delete object <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: delete object (Tim McDaniel)
Re: delete object <nospam.gravitalsun.antispam@hotmail.com.nospam>
Re: Perl on a Mac - again <hjp-usenet2@hjp.at>
Re: record every backtick on STDOUT or some log file <rweikusat@mssgmbh.com>
Re: record every backtick on STDOUT or some log file <chris-usenet@roaima.co.uk>
Re: Why does this code works without cat ? <whynot@pozharski.name>
Re: Why does this code works without cat ? <whynot@pozharski.name>
Re: Why does this code works without cat ? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 24 Apr 2012 08:05:09 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <8662cp187u.fsf@red.stonehenge.com>
>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> You can program Perl with FP idioms and enjoy it, but Perl is definitely
Ted> not a FP language. It doesn't have proper closures, for instance.
OK, I'm curious. What's a "proper closure", compared to Perl? Perl
certainly has more-proper closures than Python does. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Tue, 24 Apr 2012 12:43:11 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: A Design Pattern Question for Functional Programers
Message-Id: <87mx6113og.fsf@lifelogs.com>
On Tue, 24 Apr 2012 08:05:09 -0700 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> You can program Perl with FP idioms and enjoy it, but Perl is definitely
Ted> not a FP language. It doesn't have proper closures, for instance.
RLS> OK, I'm curious. What's a "proper closure", compared to Perl? Perl
RLS> certainly has more-proper closures than Python does. :)
Never mind Python, even Java claims it has closures. Compared to them,
Perl is a FP jewel.
IMO, the main non-FP trait in Perl is that it's an imperative language
by design and lots of its built-in functions have side effects,
especially on $_. That's not a bad thing, just not what you'd expect in
an FP environment. Also, I think proper FP languages require good
language support for passing, manipulating, and introspecting functions.
Perl doesn't really have that at the top level IMHO.
Beyond what's in perlfaq7 on closures... Perl has closure support, but
not enough to make it pleasant. The way $_ is handled (you have to say
"my $_"), for instance, is weird because $_ is the most stateful
variable in Perl and should IMO be automatically closed over. But that
would break a lot of code :) Also you can't be specific about which
variables you want to include in the closure, it's all lexicals, period.
Ted
------------------------------
Date: Wed, 25 Apr 2012 18:00:15 +0300
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: delete object
Message-Id: <jn93hf$1b8$1@news.ntua.gr>
I have create a class witht some properties and methods
I create a new object and do some stuff
At the end I call a custom method called $obj->Close();
the Close is like this
sub Close
{
my $self = shift;
my $class = ref $self || $self;
$class = __PACKAGE__ if $class eq '';
ref $self || die
.....
$self = {};
undef $self;
}
Unfortunately after calling the Close the
use Data::Dumper; print Dumper($obj);
at my main program is still full of data . What I have to do inside the
module , so when I call the Close the $obj to be empty ?
------------------------------
Date: Wed, 25 Apr 2012 15:22:31 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: delete object
Message-Id: <slrnjpg5ln.17eh.willem@toad.stack.nl>
George Mpouras wrote:
) I have create a class witht some properties and methods
) I create a new object and do some stuff
) At the end I call a custom method called $obj->Close();
) the Close is like this
)
) sub Close
) {
) my $self = shift;
) my $class = ref $self || $self;
) $class = __PACKAGE__ if $class eq '';
) ref $self || die
) .....
) $self = {};
) undef $self;
) }
)
) Unfortunately after calling the Close the
) use Data::Dumper; print Dumper($obj);
) at my main program is still full of data . What I have to do inside the
) module , so when I call the Close the $obj to be empty ?
This should work:
%$self = ();
But *why* do you want the $obj to be empty? There is no need to do that.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Wed, 25 Apr 2012 15:43:48 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: delete object
Message-Id: <jn963k$fuh$1@reader1.panix.com>
In article <jn93hf$1b8$1@news.ntua.gr>,
George Mpouras <nospam.gravitalsun@hotmail.com.nospam> wrote:
>I have create a class witht some properties and methods
>I create a new object and do some stuff
>At the end I call a custom method called $obj->Close();
>the Close is like this
>
>sub Close
>{
>my $self = shift;
>my $class = ref $self || $self;
> $class = __PACKAGE__ if $class eq '';
>ref $self || die
>.....
>$self = {};
>undef $self;
>}
Almost everybody finds it helpful to indent their code inside {...}.
>Unfortunately after calling the Close the
>use Data::Dumper; print Dumper($obj);
>at my main program is still full of data . What I have to do inside
>the module , so when I call the Close the $obj to be empty ?
I want to echo Willem's comment that
%$self = ();
should work.
The reason why:
{...} in a value context produces a reference to a hash table. When
you assign references like "$b = Frog->new()", $b points to the hash
table in memory. If you later do "$c = $b", $c and $b point to the
same area. If you later do "$b = {}", then $b points to a different
(empty) hash table, but $c still points to the old one.
But for a different thing: if you manipulate what $b or $c point to,
then using $b and $c see the effect.
$c = $b;
$b->{'trireme'} = 3;
then
$c->{'trireme'}
evaluates to 3 also.
That is why
$self = {};
undef $self;
do nothing to $obj. They make $self point to a new empty hash table,
or make it undef, which does not change $obj.
That is why
%$self = ();
should work. That does not change $self. It changes what $self
points to. Since $obj points to the same thing, it also see the
changes.
I also wonder a little bit why you worry about this. When Perl sees
that an object has no more references to it, then it knows that it is
impossible for that object to ever be used again, and it cleans up the
space when it thinks it's convenient. That is usually good enough.
Certainly the other way, making the programmer clean up old objects,
has been demonstrated again and again to be a lot of trouble and hard
to do correctly in all cases. In almost all cases, you just want Perl
to do the cleanup reliably for you ... unless there is some other
reason.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 25 Apr 2012 17:30:43 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: delete object
Message-Id: <jell69-8jk1.ln1@anubis.morrow.me.uk>
Quoth "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>:
> I have create a class witht some properties and methods
> I create a new object and do some stuff
> At the end I call a custom method called $obj->Close();
> the Close is like this
>
> sub Close
> {
> my $self = shift;
> my $class = ref $self || $self;
> $class = __PACKAGE__ if $class eq '';
> ref $self || die
> .....
> $self = {};
What on *Earth* are you doing here? Do you know aht any of this is
supposed to do?
> undef $self;
> }
>
> Unfortunately after calling the Close the
> use Data::Dumper; print Dumper($obj);
> at my main program is still full of data . What I have to do inside the
> module , so when I call the Close the $obj to be empty ?
Don't do it like that. Instead, write a DESTROY method (if you need one)
and then just
undef $obj;
when you want to destroy it. Most of the time you don't need to: you can
just let it go out of scope.
Ben
------------------------------
Date: Wed, 25 Apr 2012 16:52:39 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: delete object
Message-Id: <jn9a4n$r7g$1@reader1.panix.com>
In article <jell69-8jk1.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>Instead, write a DESTROY method (if you need one)
To expand on that: my understanding is that a DESTROY method is very
rarely needed -- for example, if there's an external connection that
must be closed cleanly. If all you are worried about is internal
storage, like the contents of a hash table, then I don't know of a
reason to have a DESTROY method: I think it will be called only when
there are no more references to the object, so as long as $obj still
has a reference to the object, it won't get called.
>and then just
>
> undef $obj;
>
>when you want to destroy it.
Note that that's in the caller, getting rid of the more persistent
reference to the data.
>Most of the time you don't need to: you can just let it go out of
>scope.
That's a short form of what I wrote.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 25 Apr 2012 19:01:15 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: delete object
Message-Id: <boql69-iul1.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <jell69-8jk1.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >Instead, write a DESTROY method (if you need one)
>
> To expand on that: my understanding is that a DESTROY method is very
> rarely needed -- for example, if there's an external connection that
> must be closed cleanly. If all you are worried about is internal
> storage, like the contents of a hash table, then I don't know of a
> reason to have a DESTROY method: I think it will be called only when
> there are no more references to the object, so as long as $obj still
> has a reference to the object, it won't get called.
You also need DESTROY when the object has internal circular references,
since they won't be collected until the cycle is explicitly broken.
Nowadays you can often avoid this by using weakrefs, though it's not
always easy to pick the right ref to weaken. (This is a consequence of
Perl using reference counts rather than a proper garbage collector.)
Ben
------------------------------
Date: Wed, 25 Apr 2012 19:37:01 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: delete object
Message-Id: <87r4vb7j5e.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth tmcd@panix.com:
>> In article <jell69-8jk1.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >Instead, write a DESTROY method (if you need one)
>>
>> To expand on that: my understanding is that a DESTROY method is very
>> rarely needed -- for example, if there's an external connection that
>> must be closed cleanly. If all you are worried about is internal
>> storage, like the contents of a hash table, then I don't know of a
>> reason to have a DESTROY method: I think it will be called only when
>> there are no more references to the object, so as long as $obj still
>> has a reference to the object, it won't get called.
>
> You also need DESTROY when the object has internal circular references,
> since they won't be collected until the cycle is explicitly broken.
Provided that 'an object' has the only reference to some self-referential
structure, the DESTROY method can be used to 'break the circle' so
that the affected objects are destroyed, too. But that's rare enough
to be considerde coincedence.
> Nowadays you can often avoid this by using weakrefs, though it's not
> always easy to pick the right ref to weaken. (This is a consequence of
> Perl using reference counts rather than a proper garbage collector.)
As a consequence of the Perl using proper garbage collection, instead
of something designed in an academic ivory tower in order to design
academic ivory tower problems which rarely occur in practice, it is
usable for for something other than academic ivory navel-gazing, since
this usually involves dealing with all kinds of 'external objects'
beyond the reach of the garbage ivory academics collector and this
'dealing with' requires programmer control over both initialization
and finalization, even if this 'external object' is something as
mundane as a file (fans of 'proper garbage collection' usually
maintain that it is much properer when it solely deals with memory
while all other resources are to be managed with explicit code). There
also other, nice side effects, eg, the memory requirements of Perl
compared 'something proper' (such as Java) are really frugal because
memory can be reused as soon as it became unused, not as soon as there
really is no other choice. This is, of course, not really feature
because it doesn't help Oracle selling high-end minicomputers ...
and so on.
Is there any kind of Kool-Aid on this planet you didn't drink?
[just wondering ...]
------------------------------
Date: Wed, 25 Apr 2012 22:02:33 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: delete object
Message-Id: <jn9hoe$1q4i$1@news.ntua.gr>
This should work:
%$self = ();
But *why* do you want the $obj to be empty? There is no need to do that.
it works partially . $obj is still a blessed object;
There is a need for this. What I am doing at the main script is complex and
objects are looking at each other status.
What I decide to do is
sub Close {
...
%{$self} = ();
return {};
}
and at the calling script
$obj = $obj->Close;
------------------------------
Date: Wed, 25 Apr 2012 22:05:50 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: delete object
Message-Id: <jn9hug$1qp5$1@news.ntua.gr>
Ο "Ben Morrow" έγραψε στο μήνυμα
news:jell69-8jk1.ln1@anubis.morrow.me.uk...
What on *Earth* are you doing here? Do you know aht any of this is
supposed to do?
Let me think, log(x**7)**(1/2) - 3 maybe ?
------------------------------
Date: Wed, 25 Apr 2012 22:15:05 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: delete object
Message-Id: <jn9ifr$1sm2$1@news.ntua.gr>
That is why
$self = {};
undef $self;
do nothing to $obj. They make $self point to a new empty hash table,
or make it undef, which does not change $obj.
That is why
%$self = ();
should work. That does not change $self. It changes what $self
points to. Since $obj points to the same thing, it also see the
changes.
Very explanatory, thanks Tim.
------------------------------
Date: Wed, 25 Apr 2012 19:16:13 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: delete object
Message-Id: <jn9iht$bmj$1@reader1.panix.com>
In article <jn9hoe$1q4i$1@news.ntua.gr>,
George Mpouras <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>This should work:
>
> %$self = ();
>
>But *why* do you want the $obj to be empty? There is no need to do that.
>
>it works partially . $obj is still a blessed object;
>There is a need for this. What I am doing at the main script is complex and
>objects are looking at each other status.
>What I decide to do is
>
>sub Close {
>...
>%{$self} = ();
>return {};
>}
>
>and at the calling script
>$obj = $obj->Close;
By "looking at each other's status", do you mean that other objects
have references to the same object? If not, and if you're willing to
change the caller, maybe you should be able to do
undef $obj;
and forget about doing anything else.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 25 Apr 2012 22:28:04 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: delete object
Message-Id: <jn9j89$1v7s$1@news.ntua.gr>
"Tim McDaniel" news:jn9iht$bmj$1@reader1.panix.com...
In article <jn9hoe$1q4i$1@news.ntua.gr>,
George Mpouras <nospam.gravitalsun.antispam@hotmail.com.nospam> wrote:
>This should work:
>
> %$self = ();
>
>But *why* do you want the $obj to be empty? There is no need to do that.
>
>it works partially . $obj is still a blessed object;
>There is a need for this. What I am doing at the main script is complex and
>objects are looking at each other status.
>What I decide to do is
>
>sub Close {
>...
>%{$self} = ();
>return {};
>}
>
>and at the calling script
>$obj = $obj->Close;
By "looking at each other's status", do you mean that other objects
have references to the same object? If not, and if you're willing to
change the caller, maybe you should be able to do
undef $obj;
and forget about doing anything else.
There are no cross references , only simple read properties between objects.
Yes undef $obj is enough after all. but I would like also to free some
memory !
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 25 Apr 2012 08:28:55 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl on a Mac - again
Message-Id: <slrnjpf6d7.8q2.hjp-usenet2@hrunkner.hjp.at>
On 2012-04-22 18:47, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
>> On Sun, 22 Apr 2012 17:27:38 +0000, Tim McDaniel wrote:
>>
>> > A bad practice that I've seen decryed. If you have a script that
>> > depends on some feature of the original Bourne shell, or strict POSIX
>> > compatibility, it's really nasty to have /bin/sh be something else.
>
> Relatively few systems use a true Bourne shell any more, since it isn't
> freely available. About the closest is ash, which has test(1) built in.
>
>> All serious bourne like shells emulate a POSIX sh if called as sh.
>
> Not to the extent of not providing test as a builtin:
Quoting from IEEE Std 1003.1™-2008:
| An implementation may choose to make any utility a built-in
POSIX doesn't require test to be built-in, but it certainly allows it.
So ash is POSIX compatible in this regard.
> Debian and all (I think) of the BSDs use ash as /bin/sh, which was
> explicitly written to be a POSIX /bin/sh with minimal extensions.
> Solaris appears to use a derivatve of the original Bourne shell, with
> job control but without kshish POSIX features like $().
A /bin/sh which is missing POSIX features is worse than one which has
some extensions.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Tue, 24 Apr 2012 21:31:22 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: record every backtick on STDOUT or some log file
Message-Id: <87sjfslvmt.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <87sjfutboj.fsf@sapphire.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>tmcd@panix.com (Tim McDaniel) writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>>>Perl supports fork.
>>>
>>> Quite so, but doing so reliably and well takes some effort, as shown
>>> by "man perlipc".
>>
>>perlipc essentially only mentions fork as part of a daemonization
>>procedure.
>
> perlipc in 5.8.8 mentions safe implementations of pipe open (which has
> a fork implicitly behind the scenes) and backtick, defining "safe" as
> "you can do it without the shell getting its grubby fingerprints on
> the arguments".
That's obviously not relevant in the context of 'executing system
calls which change the state of a process without affecting the state
of "the process which caused that"'. Invoking the safely shell with
input data from untrusted sources "takes some effort" but that's
besides the point.
[...]
> And I certainly don't want to re-implement
> system('rm', '-rf', $dir) or die ...
> in Perl.
That's not particularly difficult and I've probably done so a couple
of times: If I can get by writing a shell scripts, I'll write a shell
script.
------------------------------
Date: Wed, 25 Apr 2012 09:17:49 +0100
From: Chris Davies <chris-usenet@roaima.co.uk>
Subject: Re: record every backtick on STDOUT or some log file
Message-Id: <diok69xaek.ln2@news.roaima.co.uk>
perlnewbie <muthuganesh.s@gmail.com> wrote:
> example: `cd $v` should be recorded as 'cd /var/tmp', same as executed
> by OS
You are aware that `cd $v` (for any value of $v) is a meaningless
operation on a UNIX/Linux type system?
Chris
------------------------------
Date: Wed, 25 Apr 2012 10:46:16 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjpfau8.d1a.whynot@orphan.zombinet>
with <h1di69-h641.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
> 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.
The only reason for this could be POSIX. Any reference, please?
I admit, concatenating multiple input redirections makes zsh cooler.
OTOH, the only mention of multiple 'word's for bash I've found is that
'word' is subject to expansion and if that expansion resulsts in multiple
'word's then bash explicitly fails. OTOOH, zsh clearly explains MULTIOS
effects (being it on or off).
I think that bash people has considered what to do with multiple
confronting redirections. And found that it would be too hard to worth
a try. And in order to *hide* that purely ad hoc decision they didn't
mention that in docs. What makes bash lame.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Wed, 25 Apr 2012 10:52:47 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjpfbaf.d1a.whynot@orphan.zombinet>
with <jn6crp$3ed$1@reader1.panix.com> Tim McDaniel wrote:
> 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.
You understand difference between redirecting *one* input stream and
redirecting *two* output streams, don't you?
*CUT* [[ 'wc' is meta-syntactic, just like above ]]
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Wed, 25 Apr 2012 14:29:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Why does this code works without cat ?
Message-Id: <1qal69-cbj1.ln1@anubis.morrow.me.uk>
Quoth Eric Pozharski <whynot@pozharski.name>:
> with <h1di69-h641.ln1@anubis.morrow.me.uk> Ben Morrow wrote:
> > 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.
>
> The only reason for this could be POSIX. Any reference, please?
Well, if you insist:
| If more than one redirection operator is specified with a command, the
| order of evaluation is from beginning to end.
|
| A failure to open or create a file shall cause a redirection to fail.
|
| 2.7.1 Redirecting Input
|
| Input redirection shall cause the file whose name results from the
| expansion of word to be opened for reading on the designated file
| descriptor, or standard input if the file descriptor is not specified.
> I admit, concatenating multiple input redirections makes zsh cooler.
> OTOH, the only mention of multiple 'word's for bash I've found is that
> 'word' is subject to expansion and if that expansion resulsts in multiple
> 'word's then bash explicitly fails. OTOOH, zsh clearly explains MULTIOS
> effects (being it on or off).
>
> I think that bash people has considered what to do with multiple
> confronting redirections. And found that it would be too hard to worth
> a try. And in order to *hide* that purely ad hoc decision they didn't
> mention that in docs. What makes bash lame.
I can't parse either of those paragraphs. In any case, this has nothing
whatever to do with bash: this is the way shish shells have behaved
since the Bourne shell.
Ben
------------------------------
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 3677
***************************************
