[32778] in Perl-Users-Digest
Perl-Users Digest, Issue: 4042 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Sep 24 09:09:41 2013
Date: Tue, 24 Sep 2013 06:09:04 -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 Sep 2013 Volume: 11 Number: 4042
Today's topics:
Re: mixed cmp operator for sorting <marc.girod@gmail.com>
Re: mixed cmp operator for sorting <marc.girod@gmail.com>
Re: mixed cmp operator for sorting <marc.girod@gmail.com>
Re: mixed cmp operator for sorting <glex_no-spam@qwest-spam-no.invalid>
Re: mixed cmp operator for sorting <marc.girod@gmail.com>
Re: mixed cmp operator for sorting <marc.girod@gmail.com>
Re: mixed cmp operator for sorting (Tim McDaniel)
Re: mixed cmp operator for sorting <ben@morrow.me.uk>
Re: mixed cmp operator for sorting (Tim McDaniel)
Re: mixed cmp operator for sorting <ben@morrow.me.uk>
Re: mixed cmp operator for sorting <ben@morrow.me.uk>
Re: python <gravitalsun@hotmail.foo>
Re: utilities in perl <cal@example.invalid>
Re: utilities in perl <ben@morrow.me.uk>
Re: utilities in perl <hjp-usenet3@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 23 Sep 2013 11:31:40 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: mixed cmp operator for sorting
Message-Id: <34145c20-4d5c-4bd2-9262-549eee352551@googlegroups.com>
On Sunday, 22 September 2013 23:38:35 UTC+1, Ben Morrow wrote:
> /s makes . match newline. Without it the pattern will fail to match if a
> non-digit section starts with a newline.
Indeed.
> Maybe I should write the whole thing out:
Thanks.
> I would like to be able to write
...
> I've explained before and so won't bore people by explaining again.
Thanks again.
Marc
------------------------------
Date: Mon, 23 Sep 2013 11:33:15 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: mixed cmp operator for sorting
Message-Id: <3f52d4f1-f024-4b09-8f80-a26e99a78d8f@googlegroups.com>
On Monday, 23 September 2013 02:16:29 UTC+1, Uri Guttman wrote:
> have you looked at Sort::Maker on cpan?
I couldn't find it.
Thanks.
Marc
------------------------------
Date: Mon, 23 Sep 2013 11:35:26 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: mixed cmp operator for sorting
Message-Id: <6ec0827c-1d69-49b2-a397-145a84de4e7c@googlegroups.com>
On Monday, 23 September 2013 08:30:46 UTC+1, John W. Krahn wrote:
> my @t = $a =~ /\D+|\d+/g;
> my @s = $b =~ /\D+|\d+/g;
>
> Avoids zero length strings.
Indeed, but it implies other changes in the following.
Marc
------------------------------
Date: Mon, 23 Sep 2013 14:57:23 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: mixed cmp operator for sorting
Message-Id: <52409d24$0$63197$815e3792@news.qwest.net>
On 09/23/13 13:33, Marc Girod wrote:
> On Monday, 23 September 2013 02:16:29 UTC+1, Uri Guttman wrote:
>
>> have you looked at Sort::Maker on cpan?
>
> I couldn't find it.
Seriously???
http://lmgtfy.com/?q=perl+sort%3A%3Amaker
------------------------------
Date: Mon, 23 Sep 2013 13:01:54 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: mixed cmp operator for sorting
Message-Id: <8570a124-c993-4f60-a534-bd74404be0bb@googlegroups.com>
On Sunday, 22 September 2013 22:17:34 UTC+1, Ben Morrow wrote:
> You'd have to benchmark it to see
OK. 20%.
Even getting rid of the do, thus paying only for the caller, is too expensive: 5%.
Marc
------------------------------
Date: Mon, 23 Sep 2013 13:03:59 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: mixed cmp operator for sorting
Message-Id: <391f9f77-d839-4694-a525-86e384543900@googlegroups.com>
On Monday, 23 September 2013 20:57:23 UTC+1, J. Gleixner wrote:
> Seriously???
Sorry, I meant: I had not been able to find it before you told me its exact name.
Marc
------------------------------
Date: Mon, 23 Sep 2013 23:27:47 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: mixed cmp operator for sorting
Message-Id: <l1qipj$2vr$1@reader1.panix.com>
In article <b484ha-0l5.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>I would like to be able to write
>
> my $ret = ...
> and return $ret;
>
>but I can't, because Perl does not let you refer to a variable in the
>same statement as it was declared. This restriction is entirely
>artificial (it would be easier for perl to bring $ret into scope
>immediately)
One problem I see is with "immediately" -- with order of operations.
In the C standard, as I recall, to allow for varying orders of
execution, they had to invent the concept of "sequence point" for "at
which it is guaranteed that all side effects of previous evaluations
will have been performed, and no side effects from subsequent
evaluations have yet been performed" (to quote Wikipedia).
I don't know whether Perl always evaluates left-to-right bottom-up, or
whether anything guarantees that -- other than the things that must be
LTRBU, like ||, &&, ?:, et cetera, or for things that man perlop says
are undefined (the exact time of execution of the increment/decrement
of postfix ++ or --, or the results of << overflowing an integer).
If it is well-specified, then the order of operations is known:
$res = (my $i = 23) * f($i);
would call f with 23, but in
$res = f($i) * (my $i = 23);
then the argument of $i would not be that "my $i".
I also wonder if there's a way to leverage ++, --, or << to get
unexpected behavior, or other operators. I can't think of anything.
I thought about conditionals, but "my $x = value() if 0" is already
known to be hinky.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 24 Sep 2013 04:07:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: mixed cmp operator for sorting
Message-Id: <99c7ha-c482.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <b484ha-0l5.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >I would like to be able to write
> >
> > my $ret = ...
> > and return $ret;
> >
> >but I can't, because Perl does not let you refer to a variable in the
> >same statement as it was declared. This restriction is entirely
> >artificial (it would be easier for perl to bring $ret into scope
> >immediately)
>
> One problem I see is with "immediately" -- with order of operations.
> In the C standard, as I recall, to allow for varying orders of
> execution, they had to invent the concept of "sequence point" for "at
> which it is guaranteed that all side effects of previous evaluations
> will have been performed, and no side effects from subsequent
> evaluations have yet been performed" (to quote Wikipedia).
Variable introduction happens at compile time, so evaluation order is
irrelevant. The variable should be visible to all code textually after
the my operator.
> I don't know whether Perl always evaluates left-to-right bottom-up, or
> whether anything guarantees that -- other than the things that must be
> LTRBU, like ||, &&, ?:, et cetera, or for things that man perlop says
> are undefined (the exact time of execution of the increment/decrement
> of postfix ++ or --, or the results of << overflowing an integer).
It's not documented as such, but the evaluation order is well defined by
the behaviour of the (only) implementation. That sentence in the
documentation of ++ was copied from the C standard by someone who didn't
understand the difference between specification and documentation.
Basically, operands are evaluated before their operators, = evaluates
its right operand before its left, all other binary operators (including
+= and friends, and **) evaluate their left operand first, sub calls
evaluate their arguments before finding the sub to call, and method
calls evaluate in the order 'invocant, arguments, method name'.
Statement modifiers evaluate in the same order as their full-blown
equivalents, so they also effectively evaluate right-to-left.
You can see the evaluation order with -MO=Concise,-exec, once you've got
the hang of reading the output.
> If it is well-specified, then the order of operations is known:
> $res = (my $i = 23) * f($i);
> would call f with 23, but in
> $res = f($i) * (my $i = 23);
> then the argument of $i would not be that "my $i".
Yes, both those cases are straightforward. The tricky case, which I
hadn't thought about, is
my $i = $i;
and perhaps-less-obviously-stupid constructions like
my ($i, $j) = (1, $i + 1);
where the RHS refers to the new $i, but the runtime portion of 'my'
hasn't happened yet. In my book this should fall into the same category
of 'don't do that' as 'my $x if 0', and produce a fatal error at
runtime.
> I also wonder if there's a way to leverage ++, --, or << to get
> unexpected behavior, or other operators. I can't think of anything.
> I thought about conditionals, but "my $x = value() if 0" is already
> known to be hinky.
There are cases of wrong behaviour which aren't caught by the
deprecation warning, too, such as
for (1..6) {
$_ % 3 == 1 and my $x = $_;
say $x;
$x = "!!!";
}
All of these cases, as well the cases above, could be caught at runtime
using the PADSTALE flag, which is currently only used to make sure evals
don't pick up variables which shouldn't be in scope yet. Presumably this
will happen at some point, when p5p decide 'state' has been around long
enough to finally get rid of 'my $x if 0'.
Ben
------------------------------
Date: Tue, 24 Sep 2013 04:46:54 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: mixed cmp operator for sorting
Message-Id: <l1r5fu$66$1@reader1.panix.com>
In article <99c7ha-c482.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <b484ha-0l5.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >I would like to be able to write
>> >
>> > my $ret = ...
>> > and return $ret;
>> >
>> >but I can't, because Perl does not let you refer to a variable in the
>> >same statement as it was declared. This restriction is entirely
>> >artificial (it would be easier for perl to bring $ret into scope
>> >immediately)
>>
>> One problem I see is with "immediately" -- with order of operations.
>> In the C standard, as I recall, to allow for varying orders of
>> execution, they had to invent the concept of "sequence point" for "at
>> which it is guaranteed that all side effects of previous evaluations
>> will have been performed, and no side effects from subsequent
>> evaluations have yet been performed" (to quote Wikipedia).
>
>Variable introduction happens at compile time, so evaluation order is
>irrelevant. The variable should be visible to all code textually after
>the my operator.
OK, "order of operations" more generally.
>and perhaps-less-obviously-stupid constructions like
>
> my ($i, $j) = (1, $i + 1);
Or
my ($i, $j) = ($j, $i);
?
There's an easy workaround (predeclare), and the current rule is
simply (in scope at end of statement). And I don't like "don't do
that but we don't or can't catch it" pitfalls, of which Perl has far
too many.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 24 Sep 2013 08:15:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: mixed cmp operator for sorting
Message-Id: <hpq7ha-gja2.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Sunday, 22 September 2013 22:17:34 UTC+1, Ben Morrow wrote:
>
> > You'd have to benchmark it to see
>
> OK. 20%.
> Even getting rid of the do, thus paying only for the caller, is too
> expensive: 5%.
What is 20% of what? What is 5% of what, and what makes you sure it's
too expensive? Are you benchmarking a sort sub which does actual work,
because I would be extremely surprised if the differences were visible
in that case.
Ben
------------------------------
Date: Tue, 24 Sep 2013 08:12:49 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: mixed cmp operator for sorting
Message-Id: <hkq7ha-gja2.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <99c7ha-c482.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Quoth tmcd@panix.com:
> >>
> >> One problem I see is with "immediately" -- with order of operations.
> >> In the C standard, as I recall, to allow for varying orders of
> >> execution, they had to invent the concept of "sequence point" for "at
> >> which it is guaranteed that all side effects of previous evaluations
> >> will have been performed, and no side effects from subsequent
> >> evaluations have yet been performed" (to quote Wikipedia).
> >
> >Variable introduction happens at compile time, so evaluation order is
> >irrelevant. The variable should be visible to all code textually after
> >the my operator.
>
> OK, "order of operations" more generally.
There is no order of operations as far as introducing variables is
concerned. Perl compiles code in the order it sees it in the file.
> >and perhaps-less-obviously-stupid constructions like
> >
> > my ($i, $j) = (1, $i + 1);
>
> Or
>
> my ($i, $j) = ($j, $i);
>
> ?
Yes? What would you expect that to do? (I would expect it to produce a
'variable is not available' error; if it didn't I would expect it to
leave $i and $j set to undef.)
> There's an easy workaround (predeclare),
It's not easy, it's ugly and inconvenient and involves repeating the
variable name at least once more than ought to be necessary.
> and the current rule is simply (in scope at end of statement).
My proposed rule would be simpler: a variable is in scope from the 'my'
onwards. If you try to talk to it before it's been properly created you
get a fatal error, but that shouldn't be unexpected.
> And I don't like "don't do
> that but we don't or can't catch it" pitfalls, of which Perl has far
> too many.
I didn't say it couldn't be caught. Maybe you stopped reading when I
mentioned PADSTALE, but I actually said that all the ways of accessing
variables when they haven't been properly introduced (including all
forms of the 'my $x if 0' bug) could be caught rather easily, and that I
expect some future version of perl will do just that.
Ben
------------------------------
Date: Mon, 23 Sep 2013 22:46:16 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: python
Message-Id: <l1q5qa$5iq$1@news.ntua.gr>
Στις 20/9/2013 22:04, ο/η ccc31807 έγραψε:
> On Friday, September 20, 2013 11:31:32 AM UTC-4, George Mpouras wrote:
>> I am handled a Python script to re-use a part of it.
>
> Have you tried writing a Perl script that calls the Python script?
>
> Does the Python script return data values? Perhaps it writes to an output file that you can open and munge in Perl.
>
> You can also try writing a shell script that (1) runs the Python script, (2) saves the output in a particular place, and (3) runs the Perl script that accepts the output as input.
>
> I find that Perl and Python are good at different things. Ideally, you should use the same language for the same task, just as a matter of sanity, rewriting as necessary in the language you choose. However, I don't object to having a process that uses different languages to handle different parts, and I have some processes that use Perl, ColdFusion, Visual Basic, and even Transact/SQL (Microsoft DTS) for different parts.
>
> CC.
>
there is the Inline::Python
too late now (i rewrite it to Perl) no one mention it , thanks ...
------------------------------
Date: Mon, 23 Sep 2013 20:26:44 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <L8SdnZd4WZHpm9zPnZ2dnUVZ_qydnZ2d@supernews.com>
On 09/23/2013 08:27 AM, hymie! wrote:
> In our last episode, the evil Dr. Lacto had captured our hero,
> "Peter J. Holzer" <hjp-usenet3@hjp.at>, who said:
>> On 2013-09-21 19:59, hymie! <hymie@lactose.homelinux.net> wrote:
>>> In our last episode, the evil Dr. Lacto had captured our hero,
>>> Cal Dershowitz <Cal@example.invalid>, who said:
>>>> I don't want to spend too long talking about something where I clearly
>>>> don't get it, but everyone else here does. I know this is a perl group,
>>>> so C talk is OT.
>>>>
>>>> int main(int argc, char * argv)
>>>>
>>>> Do people still think these values don't come from STDIN in this context?
>>>
>>> STDIN means that a program that is already running has asked you a
>>> question and is waiting for you to type in an answer.
>>
>> No, it doesn't mean that. Many programs reading from stdin never ask you
>> any questions.
>
> I was trying to simplify the situation for a user who, by his own
> admission, doesn't get it.
I'm glad it came up.
>
>>> It is possible, however, that one of the arguments you provide to
>>> the program is - . That is a clue to the operating system that
>>> "this argument should not read data from a pre-existing file, it should
>>> read from STDIN."
>>
>> Also wrong. It's not a clue to the operating system, it is a clue to the
>> program.
>
> My mistake.
The unix standard says that all options have to be proceeded by a hyphen.
I got this working now. Using Rexexp::Common didn't filter out the
'23th' entry when I used the syntax on page 138 of the alpaca book, but
since I really only needed a positive number, I just used elementary
expressions.
$ ./hf6.pl terminal pl
files are /home/fred/Documents/root/pages/terminal/terminal1.pl
/home/fred/Documents/root/pages/terminal/terminal2.pl
/home/fred/Documents/root/pages/terminal/terminal23th.pl
word is 1
word is 2
word is 23th
winner is 2
$ cat hf6.pl
#!/usr/bin/perl -w
use strict;
use v5.10.1;
use Cwd;
use File::Basename;
use Regexp::Common qw(number);
my ($dir,$filetype) = @ARGV;
die "needs directory and filetype\n" unless defined $filetype;
my $cwd = getcwd();
my $path = $cwd.'/'. $dir.'/';
# print "path is $path\n";
my @files = <$path*.$filetype>;
print "files are @files\n";
my @matching;
foreach my $file (@files){
my ($word) = (fileparse($file));
#print "word is $word\n";
$word =~ s/$dir//;>
> --hymie! http://lactose.homelinux.net/~hymie
hymie@lactose.homelinux.net
>
-------------------------------------------------------------------------------
>
#print "word is $word\n";
my $ext = ".".$filetype;
#print "ext is $ext\n";
$word =~ s/$ext$//g;
print "word is $word\n";
push(@matching, $word) if ($word =~ /^\d+$/ );
}
push(@matching, 0);
@matching = sort @matching;
my $winner = pop @matching;
print "winner is $winner\n";
$
Alright, I'm gonna take a look at what other posted and then roll this
into a subroutine. Thanks all for comments; they really help.
--
Cal
------------------------------
Date: Tue, 24 Sep 2013 07:54:14 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: utilities in perl
Message-Id: <mhp7ha-8da2.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
> On 2013-09-22 18:43, Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > No, the first argument (the command name) goes into $^X, the first
> > non-option argument goes into $0, and the rest of the arguments go into
> > @ARGV.
>
> That's what I get from adding parenthetical remarks just befor posting.
> You are right of course, from the POV of the perl process. $0 and @ARGV
> are handles as I described from the POV of the caller, but I didn't
> write that.
>
> > (Unless perl gets $^X from somewhere else, in which case the
> > first argument is thrown away, or you pass an -e option, in which case
> > $0 is "-e".)
> >
> > This is further confused by the kernel's (and perl's) #! processing, but
> > by the time perl gets its final argument list to process the first
> > argument is a path to perl itself.
>
> Why "further confused"? The mechanism you describe is perl's attempt to
> undo the effects of kernel's #! processing.
Hmm, we seem to be approaching this from opposite sides :). Here and
above, you seem to be considering invocation via #! to be the 'normal'
case, whereas I think of it as a useful hack that should be understood
in terms of the 'perl script args' form.
> The caller invokes execl("/usr/local/bin/script", "script", "foo",
> NULL),
> the kernel finds "#!/usr/bin/perl" in "/usr/local/bin/script" and
> invokes /usr/bin/perl with the argv ["/usr/bin/perl",
> "/usr/local/bin/script", "foo"] instead (note that the original argv[0]
> is lost in the process)
> the perl interpreter then "hides" itself by putting what it thinks was
> the original argv[0] into $0 and the original argv[1] .. argv[argc-1]
> into @ARGV.
If the caller invokes
execl("/usr/bin/perl", "perl", "/path/to/script", "foo", NULL);
then the first argument is "perl". Perl collects up and uses all the
arguments it understands (as far as the first non-option) and passes
what remains to the script as @ARGV.
If the script is invoked via #!, both the kernel and perl process that
line to get extra arguments to add to the beginning of the command line.
This process is confused by the fact that (on most but not all systems)
the kernel passes everything after the first space as a single argument,
and perl tries to reinterpret the #! line, split it on spaces, and turn
it into multiple arguments. The result is not always what you might
expect.
> >> 3) A set of three file descriptors numbered 0, 1, and 2, and typically
> >> called stdin, stdout, and stderr respectively in most programming
> >> languages. These are *file descriptors*, not strings. You can read
> >> from them (well, you should read only from stdin) with the read
> >> system call (or higher level functions like getc() in C or <> in
> >> Perl) and write to them (stdout and stderr, at least) with write (or
> >> print or printf, etc.)
> >
> > In fact, a completely arbitrary set of file descriptors, which may or
> > may not be contiguously numbered. It's entirely possible to invoke a
> > program with one of the standard fds closed, though it's not a good idea
> > since many programs misbehave.
>
> Linux enforces that at least these three file descriptors are open at
> least on setuid programs, but I don't know offhand whether that's done
> by the kernel or the startup code. And I am aware that this isn't true
> for other unixes.
IIRC some of the qmail programs made non-standard use of the first three
file descriptors, such as taking input on fd 1 or writing to fd 0. The
usual assignments as stdin/out/err are purely conventional, though those
conventions are somewhat enforced by some of the libc functions.
Ben
------------------------------
Date: Tue, 24 Sep 2013 14:19:07 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: utilities in perl
Message-Id: <slrnl430pr.rjm.hjp-usenet3@hrunkner.hjp.at>
On 2013-09-24 06:54, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
>> On 2013-09-22 18:43, Ben Morrow <ben@morrow.me.uk> wrote:
>> >
>> > No, the first argument (the command name) goes into $^X, the first
>> > non-option argument goes into $0, and the rest of the arguments go into
>> > @ARGV.
>>
>> That's what I get from adding parenthetical remarks just befor posting.
>> You are right of course, from the POV of the perl process. $0 and @ARGV
>> are handles as I described from the POV of the caller, but I didn't
>> write that.
>>
>> > (Unless perl gets $^X from somewhere else, in which case the
>> > first argument is thrown away, or you pass an -e option, in which case
>> > $0 is "-e".)
>> >
>> > This is further confused by the kernel's (and perl's) #! processing, but
>> > by the time perl gets its final argument list to process the first
>> > argument is a path to perl itself.
>>
>> Why "further confused"? The mechanism you describe is perl's attempt to
>> undo the effects of kernel's #! processing.
>
> Hmm, we seem to be approaching this from opposite sides :). Here and
> above, you seem to be considering invocation via #! to be the 'normal'
> case,
Yes. When I invoke a script, I normally invoke it as
name args
or maybe as
dir/name args
(if it isn't in the path).
I never invoke it as
interpreter name args
unless I actually want to invoke the interpreter in a special mode (e.g.
perl -d for debugging, perl -d:NYTProf for profiling).
Normally, I want to invoke the *program*, and I don't care whether it is
an exectuable which can be interpreted directly by the CPU or a script
which needs an additional interpreter.
And on the other side, as a programmer, I don't want to care about this
either. The program was invoked with certain arguments, and I want to
get at those arguments (and maybe also the program name). And I don't
want to care about whether there is an interpreter involved at run-time
and how that was invoked. If there is, it should get out of the way (and
thankfully, perl does).
[and now for something completely different]
> IIRC some of the qmail programs made non-standard use of the first three
> file descriptors, such as taking input on fd 1 or writing to fd 0.
Yes. I though about mentioning that, but decided against confusing the
issue further.
Also, if file descriptors 0 to 2 are still attached to the tty they were
originally opened on, it is very likely that all three of them are open
for both reading and writing. You shouldn't rely on that, of course, but
I've seen a few interactive programs write to fd 0 (after all fd 1 isn't
necessarily the same device ...).
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
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 4042
***************************************
