[32775] in Perl-Users-Digest
Perl-Users Digest, Issue: 4039 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 22 16:09:38 2013
Date: Sun, 22 Sep 2013 13:09:05 -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 Sun, 22 Sep 2013 Volume: 11 Number: 4039
Today's topics:
Re: automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <ben@morrow.me.uk>
mixed cmp operator for sorting <marc.girod@gmail.com>
Re: mixed cmp operator for sorting <ben@morrow.me.uk>
Re: utilities in perl <Cal@example.invalid>
Re: utilities in perl <Cal@example.invalid>
Re: utilities in perl <jurgenex@hotmail.com>
Re: utilities in perl <ben.usenet@bsb.me.uk>
Re: utilities in perl <news@todbe.com>
Re: utilities in perl <news@todbe.com>
Re: utilities in perl <Cal@example.invalid>
Re: utilities in perl <Cal@example.invalid>
Re: utilities in perl <Cal@example.invalid>
Re: utilities in perl <hjp-usenet3@hjp.at>
Re: utilities in perl <bill@todbe.com>
Re: utilities in perl <news@lawshouse.org>
Re: utilities in perl <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 22 Sep 2013 14:13:19 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <87a9j5q9sg.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 9/20/2013 7:09 AM, Rainer Weikusat wrote:
[...]
>> What's the precise logic behind something like this:
>>
>> [rw@sable]/tmp#perl -we '$c = $c + 1; ++$d;'
>> Name "main::d" used only once: possible typo at -e line 1.
>> Use of uninitialized value $c in addition (+) at -e line 1.
>>
>> "It is fine to use $c because 'the more, the merrier' but not as operand
>> in an addition whose value is assigned back to $c, however, while using
>> a single $d sure seems fishy, performing the exact same operation using
>> a traditional, syntactical shortcut on that is perfectly ok"?
>>
>
> Yes, it sorta makes "sense". The ++$d draws an lvalue exemption from
> "uninitialized value" but then perl agrees a single mention is
> fishy. However $c=$c+1 is too complex to equate to a simple preinc so
> it draws the "uninitialized" warning would be my guess.
"Code does $something" doesn't imply "$something is sensible". Wrt to
'uninitialized values' in expressions, there are basically three
choices:
- compile-time error
- runtime error
- define a meaning for that
'Define a meaning for that but then emit an optional runtime warning
except in case of the following expressions ..., ..., ...' [perfectly
arbitrary collection of stuff which ocurred in code written by the
person who designed/ implemented the warning] is IMHO just a bizarre
inconsistency, sort-of "do a little bit of everything", that is,
don't really do anything, but muddy the waters enough to hide that.
------------------------------
Date: Sun, 22 Sep 2013 19:21:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: automatic number <-> string conversions
Message-Id: <92p3ha-5j2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > Both of these (and the fact that the message is about an 'uninitialized'
> > rather than an 'undefined' value) lead me to believe that the intention
> > was to catch variables created by mistake (through typos and such)
> > rather than because of any illusions about Perl behaving like C.
>
> 'Variables created by mistake' should be caught by the '... used only
> once: possible typo at line ...' check and 'strict vars' is IMHO a
> better way to guard against that because 'systematic' typos (repeated
> identical misspellings) are not uncommon.
Well, of *course* strict is better. That's why it was invented. However,
strict requires declared variables, which in Perl means it requires
'my', which wasn't invented until Perl 5. We're talking about a feature
introduced in Perl 2 here.
> It is conceivable that the
> undef check was meant to be a supplement to the other. OTOH, I consider
> it completely probable that this was just another someone with a
> automatic "Fuck! That's a PROBLEM!" reaction, especially considering
> that 'uninitialized variables' can cause really nasty runtime problems
> in C, eg, write accesses through pointer which aren't really dangling
> because they point to something completely different than what a naive
> observer would assume.
I think that's extremely unlikely. The authors of perl at that point
were Larry and a small handful of others, all of whom understood Perl
rather well; if anyone had had the reaction you describe, the concept of
undef would probably have been removed altogether.
I do rather get the impression, though, that -w was at that time seen as
more like lint: that is, not necessarily something you'd run with all
the time. That makes false positives much less important.
Ben
------------------------------
Date: Sun, 22 Sep 2013 11:15:14 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: mixed cmp operator for sorting
Message-Id: <9ff61f8b-ea0a-4d16-83a8-7fb010d765f4@googlegroups.com>
Hi,
I often have to sort strings with embedded numbers, which gets into the problem that neither cmp nor <=> is appropriate to deal with them.
Making ad-hoc sort functions is nearly trivial, but cumbersome e.g. for one-liners.
I tried thus to write a sort function which would parse out the string parts from the numeric ones.
Here is what I came up with.
-8<---------------
package UCmp;
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(ucmp);
sub ucmp {
my $a = eval '$' . caller . '::a';
my $b = eval '$' . caller . '::b';
my @t = $a =~ /(\D*)(\d*)/g; pop @t; pop @t;
my @s = $b =~ /(\D*)(\d*)/g; pop @s; pop @s;
my $l = ((@t <= @s)? @t : @s) / 2;
my $ret;
while ($l--) {
$ret = ((shift @t) cmp (shift @s) or (shift @t or 0) <=> (shift @s or 0));
$l = 0 if $ret;
}
return ($ret or @t <=> @s);
}
1;
-8<-----------------
And a test example:
$ cat bar
#!/usr/bin/perl -w
use feature qw(say);
use UCmp;
say for sort ucmp qw(
a12b34
a2c
b23
a7
a7b
23
);
$ ./bar
23
a2c
a7
a7b
a12b34
b23
Would you care to criticize it?
Thanks,
Marc
------------------------------
Date: Sun, 22 Sep 2013 20:07:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: mixed cmp operator for sorting
Message-Id: <mor3ha-v73.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
>
> I often have to sort strings with embedded numbers, which gets into the
> problem that neither cmp nor <=> is appropriate to deal with them.
> Making ad-hoc sort functions is nearly trivial, but cumbersome e.g. for
> one-liners.
>
> I tried thus to write a sort function which would parse out the string
> parts from the numeric ones.
> Here is what I came up with.
>
> -8<---------------
> package UCmp;
>
> require Exporter;
> @ISA = qw(Exporter);
> @EXPORT = qw(ucmp);
>
> sub ucmp {
> my $a = eval '$' . caller . '::a';
> my $b = eval '$' . caller . '::b';
You would be better off prototyping ucmp ($$), which makes sort pass the
values to be sorted in @_. This is slightly slower than using $a and $b,
which is why it isn't the default, but using eval will be *much* slower,
as well as rather less safe.
If you must access your caller's variables, you should use symrefs in
preference to eval:
my ($a, $b) = do {
no strict "refs";
my $pkg = caller;
${"$pkg\::a"}, ${"$pkg\::b"};
};
> my @t = $a =~ /(\D*)(\d*)/g; pop @t; pop @t;
> my @s = $b =~ /(\D*)(\d*)/g; pop @s; pop @s;
Why the pops?
> my $l = ((@t <= @s)? @t : @s) / 2;
> my $ret;
> while ($l--) {
> $ret = ((shift @t) cmp (shift @s) or (shift @t or 0) <=> (shift @s
> or 0));
You try string comparison first; this means numerical sections will be
sorted in string order and the numerical comparison is pointless.
You need to consider what to do if the sections you are comparing are of
different types (a numeric vs a non-numeric section).
You should use || for or-as-an-expression; 'or' is for flow control.
> $l = 0 if $ret;
> }
> return ($ret or @t <=> @s);
I don't understand what $l is doing for you here. AFAICS these two
strings
a1b2z9
a1c3z9
will compare equal; is that what you want?
Ben
------------------------------
Date: Sat, 21 Sep 2013 13:18:17 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <__KdnYFEJIyaYqDPnZ2dnUVZ_qidnZ2d@supernews.com>
On 9/21/2013 12:59 PM, hymie! 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.
Ok. Does one say "data from the command line" for whatever populates
ARGV? Something specified by Unix?
>
> In your case, on the other hand, you are starting the program with a set
> of arguments already provided when the program starts. That's ARGV.
>
> 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."
ok.
--
Cal
------------------------------
Date: Sat, 21 Sep 2013 13:29:02 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <o-WdnZ_jVcIRnKPPnZ2dnUVZ_sGdnZ2d@supernews.com>
On 9/21/2013 1:18 PM, Cal Dershowitz wrote:
> On 9/21/2013 12:59 PM, hymie! 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.
>
> Ok. Does one say "data from the command line" for whatever populates
> ARGV? Something specified by Unix?
p 773 Stevens and Rago
Unix:
restrict each command line option to a single alphanumerical character
all options preceded by -
774
these become argv
--
Cal Dershowitz
------------------------------
Date: Sat, 21 Sep 2013 13:35:45 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: utilities in perl
Message-Id: <3i0s39dtfictrojmkftio82ok38sfgpej7@4ax.com>
hymie@lactose.homelinux.net (hymie!) 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?
Of course they don't come from STDIN. They are command line parameters
and have absolutely nothing to do with STDIN.
jue
------------------------------
Date: Sat, 21 Sep 2013 21:54:05 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: utilities in perl
Message-Id: <0.41bb0d8e4f5eafe4a22d.20130921215405BST.87siwx28wi.fsf@bsb.me.uk>
Cal Dershowitz <Cal@example.invalid> writes:
<snip>
> Ok. Does one say "data from the command line" for whatever populates
> ARGV? Something specified by Unix?
Yes, but it would be better just to say "the arguments for the program".
After all, that's all @ARGV stands for -- the "argument vector" so named
because C programmers use argv as the canonical name for the C
equivalent.
They do often come from a command line, but some environments don't have a
command line (for example Perl scripts running on a web server may not
have such a thing), and programs can be started in other ways (see, for
example, perldoc -f exec).
<snip>
--
Ben.
------------------------------
Date: Sat, 21 Sep 2013 19:48:26 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: utilities in perl
Message-Id: <l1llpq$q09$1@dont-email.me>
On 9/21/2013 10:13, Cal Dershowitz wrote:
> #!/usr/bin/perl -w
See what this one does (I'm using Windows 8 with tcsh here):
use strict;
use warnings;
die "Needs base filename and file ext args" if @ARGV < 2;
my $base = shift;
my $ext = shift;
print "base='$base', ext='$ext'\n";
opendir DIR, '.' or die "opendir '.': $! ($^W)";
# grep out base*.ext files
my @files = grep /^$base\d*\.$ext/, readdir DIR;
closedir DIR;
print "Matching files are (@files)\n";
__END__
------------------------------
Date: Sat, 21 Sep 2013 21:17:08 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: utilities in perl
Message-Id: <l1lr06$el9$1@dont-email.me>
On 9/21/2013 19:48, $Bill wrote:
> On 9/21/2013 10:13, Cal Dershowitz wrote:
>> #!/usr/bin/perl -w
>
> See what this one does (I'm using Windows 8 with tcsh here):
>
> use strict;
> use warnings;
>
> die "Needs base filename and file ext args" if @ARGV < 2;
>
> my $base = shift;
> my $ext = shift;
> print "base='$base', ext='$ext'\n";
>
> opendir DIR, '.' or die "opendir '.': $! ($^W)";
> # grep out base\d*.ext files
> my @files = grep /^$base\d*\.$ext/, readdir DIR;
Whoops, probably want a $ after $ext to anchor it to end of filename.
Technically, you could probably make the \d* into a .* to be more
generic and allow other than numbers, but your situation seems to
be more specific with numbers/version only.
> closedir DIR;
>
> print "Matching files are (@files)\n";
>
> __END__
------------------------------
Date: Sun, 22 Sep 2013 00:07:00 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <z-CdnUYo3vCMCqPPnZ2dnUVZ_sednZ2d@supernews.com>
On 9/21/2013 1:54 PM, Ben Bacarisse wrote:
> Cal Dershowitz <Cal@example.invalid> writes:
> <snip>
>> Ok. Does one say "data from the command line" for whatever populates
>> ARGV? Something specified by Unix?
>
> Yes, but it would be better just to say "the arguments for the program".
> After all, that's all @ARGV stands for -- the "argument vector" so named
> because C programmers use argv as the canonical name for the C
> equivalent.
>
> They do often come from a command line, but some environments don't have a
> command line (for example Perl scripts running on a web server may not
> have such a thing), and programs can be started in other ways (see, for
> example, perldoc -f exec).
>
> <snip>
>
#!/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//;
#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 /$RE{num}{int}/;
}
@matching = sort @matching;
my $winner = pop @matching;
print "winner is $winner\n";
I can't run this yet because my linux terminal needs some tlc, but I
think this is getting close.
I'm really enjoying the reading on page 138 of the alpaca book.
Cheers,
--
Cal
------------------------------
Date: Sun, 22 Sep 2013 00:58:38 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <U_udnT82vZi2PqPPnZ2dnUVZ_jidnZ2d@supernews.com>
On 9/21/2013 7:48 PM, $Bill wrote:
> On 9/21/2013 10:13, Cal Dershowitz wrote:
>> #!/usr/bin/perl -w
>
> See what this one does (I'm using Windows 8 with tcsh here):
>
> use strict;
> use warnings;
>
> die "Needs base filename and file ext args" if @ARGV < 2;
>
> my $base = shift;
> my $ext = shift;
> print "base='$base', ext='$ext'\n";
>
> opendir DIR, '.' or die "opendir '.': $! ($^W)";
> # grep out base*.ext files
> my @files = grep /^$base\d*\.$ext/, readdir DIR;
> closedir DIR;
>
> print "Matching files are (@files)\n";
>
> __END__
Cool, cool, $Bill I believe we're new to each other. I like that you
identified yourself with an 'S' which is how some people describe the
dollar sign thingy. Perl makes for a very interesting program language
for people who aren't afraid to talk about "s underscore" in public.
Some people say "sigil."
I took your script and will fire it up once I get wireless connectivity
for my linux box again. I'm not at that level of maturity where I can
be dancing around on the terminal and downloading cpan where I simply
cannot.
My contention is that I'm guaranteed to be on topic by tuesday. Until
then I'd like to consider the question of what perl environment works
best on a windows 8 laptop, which is at best a shoulder issue as far as
topicality goes. I ask it, because it has directly to do with my
pursuit of laziness.
Thanks all for your generous comments.
--
Cal
------------------------------
Date: Sun, 22 Sep 2013 01:13:43 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <T_2dnRv2ytkpO6PPnZ2dnUVZ_qidnZ2d@supernews.com>
On 9/21/2013 1:35 PM, Jürgen Exner wrote:
> hymie@lactose.homelinux.net (hymie!) 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?
>
> Of course they don't come from STDIN. They are command line parameters
> and have absolutely nothing to do with STDIN.
>
> jue
>
It took me a bit, but I think I definitely agree with you. Indeed, I
believe "command-line parameters" is the common appellation for it.
Do germans typically have directories for their own stuff that have
german encodings like:
/home/jue/Documents/Persoenlichkeiten/
, where you have an actual o umlaut as opposed to the english
transcription? Maybe even the u too.
--
Cal
------------------------------
Date: Sun, 22 Sep 2013 12:39:57 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: utilities in perl
Message-Id: <slrnl3ti7t.5pj.hjp-usenet3@hrunkner.hjp.at>
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. For example all the typical Unix filters: cat, grep, cut,
sort, ...
> In your case, on the other hand, you are starting the program with a set
> of arguments already provided when the program starts. That's ARGV.
Yes, he has provided the program with arguments and those can be
accessed through @ARGV. However, that hasn't anything to do with stdin.
A program can choose to read or not to read from stdin whether it was
passed any command line arguments or not.
> 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. Many programs accept a "-" instead of a filename to mean either
"read from stdin" or "write to stdout". This is something the program
has to handle. tho OS just passes the "-" to the program.
To summarize:
On startup, a program is provided with three sets of information:
1) The argument vector: This is an array of strings containing the
command name and any "command line" arguments, i.e. the arguments
you type on the command line after the command (interactively), or
the arguments to exec (in a program). (Perl is a bit unusual in that
it shoves the first argument (the command name) into $0 and only the
rest of the arguments into @ARGV).
2) The environment: Another array of strings. By convention each program
passes this through to any programs it invokes and the strings are in
"key=value" format. This contains the PATH, locale information,
information about the terminal (if applicable) and other
configuration information.
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.)
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/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 22 Sep 2013 04:22:46 -0700
From: "$Bill" <bill@todbe.com>
Subject: Re: utilities in perl
Message-Id: <l1mju7$nck$1@dont-email.me>
On 9/22/2013 00:58, Cal Dershowitz wrote:
>
> Cool, cool, $Bill I believe we're new to each other. I like that you identified yourself with an 'S' which is how some people describe the dollar sign thingy. Perl makes for a very interesting program language for people who aren't afraid to talk about "s underscore" in public. Some people say "sigil."
The $ actually stands for a '1' and an 'S' superimposed (from my days
as a computer operator many decades ago - meaning '1st shift' - and
used to initial run requests in the tiny little initials box).
> I took your script and will fire it up once I get wireless connectivity for my linux box again. I'm not at that level of maturity where I can be dancing around on the terminal and downloading cpan where I simply cannot.
Should work on UNIX or Windows.
> My contention is that I'm guaranteed to be on topic by tuesday. Until then I'd like to consider the question of what perl environment works best on a windows 8 laptop, which is at best a shoulder issue as far as topicality goes. I ask it, because it has directly to do with my pursuit of laziness.
I prefer Windows 7 which I have on my desktop (8 on laptop).
I use Vim for an editor, tcsh for my shell (doesn't work as
well on 8 as it does on 7) and ActiveState Perl which is
easy to install and add modules to using PPM. I try to use
native Windows ported UNIX utilities (rather than emulated
ones as in CygWin). I don't do much, if any, compiling - just
never managed to properly set up a decent compiler/development
environment (and not about to pay for Windoze MSVC) - so I just
use pre-compiled AS Perl for everything.
------------------------------
Date: Sun, 22 Sep 2013 12:53:24 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: utilities in perl
Message-Id: <2NydnYagkN6oR6PPnZ2dnUVZ8nednZ2d@giganews.com>
On 21/09/13 21:35, Jürgen Exner wrote:
> They are command line parameters
> and have absolutely nothing to do with STDIN
Of course that's right, and I'm at fault for sloppy thinking. Sorry for
starting this whole thing off.
--
Henry Law Manchester, England
------------------------------
Date: Sun, 22 Sep 2013 19:43:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: utilities in perl
Message-Id: <acq3ha-rr2.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
>
> To summarize:
>
> On startup, a program is provided with three sets of information:
>
> 1) The argument vector: This is an array of strings containing the
> command name and any "command line" arguments, i.e. the arguments
> you type on the command line after the command (interactively), or
> the arguments to exec (in a program). (Perl is a bit unusual in that
> it shoves the first argument (the command name) into $0 and only the
> rest of the arguments into @ARGV).
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. (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.
This is not really unusual: it's what all the shells do, and I'd wager
also any other language which has some equivalent to $0.
> 2) The environment: Another array of strings. By convention each program
> passes this through to any programs it invokes and the strings are in
> "key=value" format. This contains the PATH, locale information,
> information about the terminal (if applicable) and other
> configuration information.
>
> 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. It's also not uncommon to pass
additional open file descriptors.
The process also has a 'current directory' and a 'root directory', which
are effectively unnumbered file descriptors which are guaranteed to
point to directories; and may also have a 'current tty', which (if it is
present) will always point to a terminal device.
(The ctty and the possibility of chroot are Unix-specific. The rest
should be present on any system supporting C.)
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 4039
***************************************
