[32774] in Perl-Users-Digest
Perl-Users Digest, Issue: 4038 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Sep 21 16:09:39 2013
Date: Sat, 21 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 Sat, 21 Sep 2013 Volume: 11 Number: 4038
Today's topics:
Re: automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <derykus@gmail.com>
Re: automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <derykus@gmail.com>
python <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: python <cartercc@gmail.com>
utilities in perl <cal@example.invalid>
Re: utilities in perl <bill@todbe.com>
Re: utilities in perl <gravitalsun@hotmail.foo>
Re: utilities in perl <news@lawshouse.org>
Re: utilities in perl <hjp-usenet3@hjp.at>
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 <jurgenex@hotmail.com>
Re: utilities in perl <Cal@example.invalid>
Re: utilities in perl <gravitalsun@hotmail.foo>
Re: utilities in perl (hymie!)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 19 Sep 2013 17:55:09 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <87a9j8zr82.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 9/18/2013 6:00 PM, Ben Morrow wrote:
>>
>> Quoth Charles DeRykus <derykus@gmail.com>:
>>> On 9/18/2013 9:55 AM, Ben Morrow wrote:
> ...
>
>>
>> IMHO with properly scoped variables an undef is no more likely to be a
>> mistake than any other value. IME undef warnings cause more problems (in
>> terms of unnecessary code to work around them) than they solve. A simple
>> example would be something like this:
>>
>> my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
>>
>> where silently treating a nonexistent setting as 0 is the right thing to
>> do. With undef warnings turned on that line of code has to become a good
>> bit more complex, to no real advantage.
>
> Maybe it's a personal bias bordering on an OCD affliction, but I'd
> rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
>
> IMO not appallingly tedious and documenting clearly what's going on.
This would in itself warrant some 'clear documentation' a la
# silence 'undefined value' warnings
because on its own, it's just apparently useless code.
------------------------------
Date: Thu, 19 Sep 2013 14:26:43 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <l1fq6t$k85$1@speranza.aioe.org>
On 9/19/2013 9:55 AM, Rainer Weikusat wrote:
> ...
>>
>> Maybe it's a personal bias bordering on an OCD affliction, but I'd
>> rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
>>
>> IMO not appallingly tedious and documenting clearly what's going on.
>
> This would in itself warrant some 'clear documentation' a la
>
> # silence 'undefined value' warnings
>
> because on its own, it's just apparently useless code.
>
If someone knows it's "useless code", I will wager he/she knows well
the dark kingdom of "uninitialized value". (if not, then some lessons
need to be experienced and having been so, you will not want to comment
on such things ever again :)
--
Charles DeRykus
------------------------------
Date: Fri, 20 Sep 2013 13:21:06 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <8738ozk7kd.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>>
> [undef warnings]
[...]
>> Don't warn if 'an undefined value' is used as if somebody
>> thought he wasn't accessing some a C 'stack-allocated object' which was
>> left unitialized for performance reason because that's totally
>> ridicolous for perl, anyway, and not true.
>
> I'm pretty certain that wasn't the reason. The warning was added in perl
> 2 (and goodness me, perl was a lot simpler in those days!); the only
> comments about it still preserved in the perl repo are this paragraph in
> the manpage:
>
> .B \-w
> prints warnings about identifiers that are mentioned only once, and
> scalar variables that are used before being set.
> Also warns about redefined subroutines, and references to undefined
> subroutines and filehandles.
>
> and this comment from the git commit message for perl-2.0, which I
> believe was taken from a release announcement of some sort:
>
> * Warnings are now available (with -w) on use of uninitialized
> variables and on identifiers that are mentioned only once, and on
> reference to various undefined things.
>
> 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. 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.
------------------------------
Date: Fri, 20 Sep 2013 15:09:16 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <87ob7ninzn.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 9/19/2013 9:55 AM, Rainer Weikusat wrote:
>> ...
>>>
>>> Maybe it's a personal bias bordering on an OCD affliction, but I'd
>>> rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
>>>
>>> IMO not appallingly tedious and documenting clearly what's going on.
>>
>> This would in itself warrant some 'clear documentation' a la
>>
>> # silence 'undefined value' warnings
>>
>> because on its own, it's just apparently useless code.
>>
>
> If someone knows it's "useless code", I will wager he/she knows well
> the dark kingdom of "uninitialized value". (if not, then some
> lessons need to be experienced and having been so, you will not want
> to comment on such things ever again :)
Which "dark kingdom"? Assuming the following toy program for testing the
perl PRNG,
------------
use warnings;
use constant WANT => 5;
my ($got, $needed);
do {
++$needed;
++$got if int(rand(100)) >= 89;
} while ($got < WANT);
print("needed $needed\n");
------------
there's a (pseudo-)random chance that this will print a (pseudo-)random
number of warnings in addition to the actual output. What's that
supposed to be so good for that it would excuse any of the possible
contortions which could be used to hack around that?
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"?
------------------------------
Date: Sat, 21 Sep 2013 02:23:19 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <l1joil$bie$1@speranza.aioe.org>
On 9/20/2013 7:09 AM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 9/19/2013 9:55 AM, Rainer Weikusat wrote:
>>> ...
>>>>
>>>> Maybe it's a personal bias bordering on an OCD affliction, but I'd
>>>> rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
>>>>
>>>> IMO not appallingly tedious and documenting clearly what's going on.
>>>
>>> This would in itself warrant some 'clear documentation' a la
>>>
>>> # silence 'undefined value' warnings
>>>
>>> because on its own, it's just apparently useless code.
>>>
>>
>> If someone knows it's "useless code", I will wager he/she knows well
>> the dark kingdom of "uninitialized value". (if not, then some
>> lessons need to be experienced and having been so, you will not want
>> to comment on such things ever again :)
>
> Which "dark kingdom"? Assuming the following toy program for testing the
> perl PRNG,
>
> ...
]
> 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.
--
Charles DeRykus
------------------------------
Date: Fri, 20 Sep 2013 18:31:32 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: python
Message-Id: <l1hpna$p06$1@news.ntua.gr>
I am handled a Python script to re-use a part of it.
I have to options.
Modify Python script and and catch its STDOUT or write the whole code as
a Perl module.
Is there any other way to include Python code on a Perl script;
------------------------------
Date: Fri, 20 Sep 2013 12:04:48 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: python
Message-Id: <693600ff-2549-47b9-8968-5c558d203793@googlegroups.com>
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 f=
ile 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 shou=
ld use the same language for the same task, just as a matter of sanity, rew=
riting as necessary in the language you choose. However, I don't object to =
having a process that uses different languages to handle different parts, a=
nd I have some processes that use Perl, ColdFusion, Visual Basic, and even =
Transact/SQL (Microsoft DTS) for different parts.
CC.
------------------------------
Date: Fri, 20 Sep 2013 17:04:16 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: utilities in perl
Message-Id: <26idnbOHafwbf6HPnZ2dnUVZ_rqdnZ2d@supernews.com>
I'm writing a few utilities in perl and wanted to solicit opinion
regarding a couple things.
$ pwd
/home/fred/Documents/root/pages
$ ./hf.pl elmer fudd
dir is elmer
filetype is fudd
elmer
fudd
$ cat hf.pl
#!/usr/bin/perl -w
use strict;
use 5.010;
if ($#ARGV < 1) {
print "Needs directory and filetype\n";
exit;
}
my $dir = $ARGV[0];
my $filetype = $ARGV[1];
print "dir is $dir\n";
print "filetype is $filetype\n";
print "$dir\n";
print "$filetype\n";
Q1) Do the ultimate 2 statements effectively pipe the input from stdin
to stdout?
Q2) Are there inputs for the two values that could cause these values
to be different before versus after?
Thanks for your comment.
--
Cal Dershowitz
------------------------------
Date: Fri, 20 Sep 2013 18:26:26 -0700
From: "$Bill" <bill@todbe.com>
Subject: Re: utilities in perl
Message-Id: <l1isjs$75j$1@dont-email.me>
On 9/20/2013 17:04, Cal Dershowitz wrote:
> I'm writing a few utilities in perl and wanted to solicit opinion regarding a couple things.
>
> $ pwd
> /home/fred/Documents/root/pages
> $ ./hf.pl elmer fudd
> dir is elmer
> filetype is fudd
> elmer
> fudd
> $ cat hf.pl
> #!/usr/bin/perl -w
> use strict;
> use 5.010;
> if ($#ARGV < 1) {
> print "Needs directory and filetype\n";
> exit;
> }
> my $dir = $ARGV[0];
> my $filetype = $ARGV[1];
> print "dir is $dir\n";
> print "filetype is $filetype\n";
> print "$dir\n";
> print "$filetype\n";
>
> Q1) Do the ultimate 2 statements effectively pipe the input from stdin to stdout?
What ultimate 2 statements ? There's no piping involved here.
You're not using stdin for anything.
> Q2) Are there inputs for the two values that could cause these values to be different before versus after?
Not sure what you mean as to different before and after. There
could be shell problems with the two arguments if they have
unusual characters in them - eg: spaces and such. You may need
some quoting to handle that which would depend on the shell you
are using.
Not at all sure what you're trying to ask here - might help if
you stated what type of utilities you were targeting for your
scripts - they may already exist (unless you just want to practice
your skills and get some experience with Perl).
------------------------------
Date: Sat, 21 Sep 2013 11:31:34 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: utilities in perl
Message-Id: <l1jlha$1p9b$1@news.ntua.gr>
# you may like it
#!/usr/bin/perl
use strict;
use warnings;
use feature 'say';
my $dir = exists $ARGV[0] && -d $ARGV[0] ? $ARGV[0] : './';
foreach(<$dir/*>){say "$_ is ", -d $_ ? 'directory':'file'}
------------------------------
Date: Sat, 21 Sep 2013 15:49:34 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: utilities in perl
Message-Id: <ydKdnQ4lXa1jLKDPnZ2dnUVZ8uednZ2d@giganews.com>
On 21/09/13 01:04, Cal Dershowitz wrote:
> if ($#ARGV < 1) {
> print "Needs directory and filetype\n";
> exit;
> }
> my $dir = $ARGV[0];
> my $filetype = $ARGV[1];
You might think of this instead:
my ( $dir, $filetype ) = @ARGV;
die "Needs directory and filetype\n" unless defined $filetype;
> print "dir is $dir\n";
> print "filetype is $filetype\n";
> print "$dir\n";
> print "$filetype\n";
Better might be:
print << FOO;
dir is $dir
filetype is $filetype
$dir
$filetype
FOO
> Q1) Do the ultimate 2 statements effectively pipe the input from stdin
> to stdout?
No. STDIN contained the two values in one line; your last two "print"
statements will output them with a newline in between. That's aside
from the fact that, as you've written it, STDOUT also contains the
output from the first two "print" statements.
But this is a very strange question; what are you trying to do? Why on
earth do you need a utility which just echoes STDIN to STDOUT? Even if
you do what's with all the directory, filetype stuff? You're not
telling us what you really want, which isn't a good way of getting it.
> Q2) Are there inputs for the two values that could cause these values
> to be different before versus after?
"Before" and "After" what? Meaning between the input and the output?
No, there aren't, since you're not doing anything with the values. Do
you want there to be? If so, what are you trying to do? Or have you
coded something where it looks as if there is a difference and you're
trying to find out where the mistake is? Well post the code and someone
here will tell you. (Often the act of posting it will show you yourself
what the error is).
--
Henry Law Manchester, England
------------------------------
Date: Sat, 21 Sep 2013 17:33:52 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: utilities in perl
Message-Id: <slrnl3rf30.vod.hjp-usenet3@hrunkner.hjp.at>
On 2013-09-21 14:49, Henry Law <news@lawshouse.org> wrote:
> On 21/09/13 01:04, Cal Dershowitz wrote:
>> if ($#ARGV < 1) {
>> print "Needs directory and filetype\n";
>> exit;
>> }
>> my $dir = $ARGV[0];
>> my $filetype = $ARGV[1];
[...]
>> Q1) Do the ultimate 2 statements effectively pipe the input from stdin
>> to stdout?
>
> No. STDIN contained the two values in one line;
No STDIN didn't contain those values at all. @ARGV is not STDIN!
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: Sat, 21 Sep 2013 10:13:54 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <XfednXnog_VNTqDPnZ2dnUVZ_umdnZ2d@supernews.com>
On 9/20/2013 6:26 PM, $Bill wrote:
> On 9/20/2013 17:04, Cal Dershowitz wrote:
>> Q1) Do the ultimate 2 statements effectively pipe the input from
>> stdin to stdout?
>
> What ultimate 2 statements ? There's no piping involved here.
> You're not using stdin for anything.
ok
>
>> Q2) Are there inputs for the two values that could cause these values
>> to be different before versus after?
>
> Not sure what you mean as to different before and after. There
> could be shell problems with the two arguments if they have
> unusual characters in them - eg: spaces and such. You may need
> some quoting to handle that which would depend on the shell you
> are using.
>
> Not at all sure what you're trying to ask here - might help if
> you stated what type of utilities you were targeting for your
> scripts - they may already exist (unless you just want to practice
> your skills and get some experience with Perl).
>
>
I'm trying to take the tasks I do a lot, with a lot of keystrokes and
GUI events and make that what perl does instead. Frequently, I find
that I'm looking for "the highest-numbered something of a filetype" in a
directory. For example, when I improve a script, it goes from
terminal1.pl to terminal2.pl and then and so on till I get the script
right, and then that's the script I want to do something with.
The design of this particular utility has the directory name as the
beginning of the filename. The files exist as concatenations of the
directory, a positive integer, a dot, and a suffix. I put
terminal23th.pl in the directory as an example of a file that should not
match when I test against the pattern.
$ ./hf.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
base is terminal1.pl
ext is
base is terminal2.pl
ext is
base is terminal23th.pl
ext is
$ cat hf.pl
#!/usr/bin/perl -w
use strict;
use 5.010;
use Cwd;
use File::Basename;
if ($#ARGV < 1) {
print "Needs directory and filetype\n";
exit;
}
my $dir = $ARGV[0];
my $filetype = $ARGV[1];
# print "$dir\n";
# print "$filetype\n";
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 ($base, $dir2, $suffix) = (fileparse($file));
print "base is $base\n";
print "ext is $suffix\n";
if ($base =~ m%{$dir}(\d+)\.{$suffix}%) {
push(@matching, $1);
print "match is $_\n";
}
}
$
Q1) Why am I getting nothing for $suffix?
Q2) Why am I getting no matches for the regex?
Thanks for your comment.
--
Cal
------------------------------
Date: Sat, 21 Sep 2013 10:26:32 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <keqdnSu3X_NbS6DPnZ2dnUVZ_qednZ2d@supernews.com>
On 9/21/2013 8:33 AM, Peter J. Holzer wrote:
> On 2013-09-21 14:49, Henry Law <news@lawshouse.org> wrote:
>> On 21/09/13 01:04, Cal Dershowitz wrote:
>>> if ($#ARGV < 1) {
>>> print "Needs directory and filetype\n";
>>> exit;
>>> }
>>> my $dir = $ARGV[0];
>>> my $filetype = $ARGV[1];
> [...]
>>> Q1) Do the ultimate 2 statements effectively pipe the input from stdin
>>> to stdout?
>>
>> No. STDIN contained the two values in one line;
>
> No STDIN didn't contain those values at all. @ARGV is not STDIN!
Hmmmm. I'm looking at Stevens and Rago, p. 774
#include <fcntl.h>
int getopt(int argc, const * const argv[], const char *options);
It certainly reminds a person of the straight C version of it. Maybe
you can say a few words why this is not STDIN.
--
Cal
------------------------------
Date: Sat, 21 Sep 2013 19:36:10 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: utilities in perl
Message-Id: <slrnl3rm8a.h7u.hjp-usenet3@hrunkner.hjp.at>
On 2013-09-21 17:26, Cal Dershowitz <Cal@example.invalid> wrote:
> On 9/21/2013 8:33 AM, Peter J. Holzer wrote:
>> On 2013-09-21 14:49, Henry Law <news@lawshouse.org> wrote:
>>> On 21/09/13 01:04, Cal Dershowitz wrote:
>>>> if ($#ARGV < 1) {
>>>> print "Needs directory and filetype\n";
>>>> exit;
>>>> }
>>>> my $dir = $ARGV[0];
>>>> my $filetype = $ARGV[1];
>> [...]
>>>> Q1) Do the ultimate 2 statements effectively pipe the input from stdin
>>>> to stdout?
>>>
>>> No. STDIN contained the two values in one line;
>>
>> No STDIN didn't contain those values at all. @ARGV is not STDIN!
>
> Hmmmm. I'm looking at Stevens and Rago, p. 774
>
> #include <fcntl.h>
>
> int getopt(int argc, const * const argv[], const char *options);
>
> It certainly reminds a person of the straight C version of it.
The C getopt function (and the arguments argc and argv to the main
function) doesn't have anything to do with stdin in C either.
> Maybe you can say a few words why this is not STDIN.
Because it isn't. They are completely separate. There is no "why" except
that Ken and Dennis thought it was a good idea to have both a standard
input and program arguments.
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: Sat, 21 Sep 2013 10:52:47 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: utilities in perl
Message-Id: <1tmr39ln6suvva7tg287vtplhmt3jnvvuj@4ax.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>On 2013-09-21 17:26, Cal Dershowitz <Cal@example.invalid> wrote:
[...]
>>>>> my $dir = $ARGV[0];
>>>>> my $filetype = $ARGV[1];
>>> [...]
>>>>> Q1) Do the ultimate 2 statements effectively pipe the input from stdin
>>>>> to stdout?
>>>>
>>>> No. STDIN contained the two values in one line;
>>>
>>> No STDIN didn't contain those values at all. @ARGV is not STDIN!
>>
>> Maybe you can say a few words why this is not STDIN.
Try a trivial experiment and redirect STDIN, e.g. feed it from a pipe:
cat whateverfile | myprog.pl foo bar
(yes, this is a useless use of cat, just to make the example
super-explicit)
Now, what value to you expect in $dir and $filetype? Based on your
reasoning it must be (part of) the content of whateverfile because that
is where the content of STDIN is coming from.
jue
------------------------------
Date: Sat, 21 Sep 2013 12:07:53 -0700
From: Cal Dershowitz <Cal@example.invalid>
Subject: Re: utilities in perl
Message-Id: <mdadnUenGOsVc6DPnZ2dnUVZ_jednZ2d@supernews.com>
On 9/21/2013 10:52 AM, Jürgen Exner wrote:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> wrote:
>> On 2013-09-21 17:26, Cal Dershowitz <Cal@example.invalid> wrote:
> [...]
>>>>>> my $dir = $ARGV[0];
>>>>>> my $filetype = $ARGV[1];
>>>> [...]
>>>>>> Q1) Do the ultimate 2 statements effectively pipe the input from stdin
>>>>>> to stdout?
>>>>>
>>>>> No. STDIN contained the two values in one line;
>>>>
>>>> No STDIN didn't contain those values at all. @ARGV is not STDIN!
>>>
>>> Maybe you can say a few words why this is not STDIN.
>
> Try a trivial experiment and redirect STDIN, e.g. feed it from a pipe:
>
> cat whateverfile | myprog.pl foo bar
> (yes, this is a useless use of cat, just to make the example
> super-explicit)
see below for output
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?
>
> Now, what value to you expect in $dir and $filetype? Based on your
> reasoning it must be (part of) the content of whateverfile because that
> is where the content of STDIN is coming from.
For $dir, I'd like it too be able to handle unicode. This is a
component of my templating system, which is within striking distance of
being good. After I figure this program out as a free-standing script,
I'll reduce it to a subroutine.
$filetype, hey for generalty's sake, why not go for unicode again?
>
> jue
I'm not sure what I was suppoosed to see here, jue.
Still looking for how to get $suffix populated with a value. To my eye,
I mimic the example. My output disagrees.
http://search.cpan.org/~rjbs/perl-5.18.1/lib/File/Basename.pm
I got Henry Law's note incorporated here and greatly prefer it if only
for readability.
$ ./hf1.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
base is terminal1.pl
ext is
base is terminal2.pl
ext is
base is terminal23th.pl
ext is
$ cat whateverfile | hf1.pl terminal pl
hf1.pl: command not found
$ cat whateverfile
lucky charms
$ cat hf1.pl
#!/usr/bin/perl -w
use strict;
use 5.010;
use Cwd;
use File::Basename;
if ($#ARGV < 1) {
print "Needs directory and filetype\n";
exit;
}
my ($dir, $filetype) = @ARGV;
die "needs a directory and filetype\n" unless defined $filetype;
# print "$dir\n";
# print "$filetype\n";
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){
chomp($file);
my ($base, $dir2, $suffix) = (fileparse($file));
print "base is $base\n";
print "ext is $suffix\n";
if ($base =~ m%{$dir}(\d+)\.{$suffix}%) {
push(@matching, $1);
print "match is $_\n";
}
}
$
--
Cal
------------------------------
Date: Sat, 21 Sep 2013 22:49:25 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: utilities in perl
Message-Id: <l1kt84$23u0$1@news.ntua.gr>
this is what you want
/hf1.pl /home/fred/Documents/root/pages/terminal/terminal1.pl
/home/fred/Documents/root/pages/terminal/terminal2.pl
/home/fred/Documents/root/pages/terminal/terminal23th.pl
#!/usr/bin/perl
use strict;
use warnings;
foreach (@ARGV)
{
my @info = Path_analyzer($_);
print "upper dir : $info[0]\n";
print "filename : $info[1]\n";
print "filebare : $info[2]\n";
print "extension : $info[3]\n";
print '-'x30, "\n";
}
# 1) dir
# 2) filename
# 3) filename without the extension
# 4) extension
#
sub Path_analyzer
{
return ('','','','') if (! exists $_[0]) || ($_[0] eq '');
my ($dir, $file, $body, $ext) = ($_[0],'','','');
$dir =~s/(\s|\/)*$//;
($dir,$file) = $dir =~/^(.*?)([^\/]+)$/;
$dir =~s/(\s|\/)*$//;
if ( ( $dir=~/^\s*$/ ) || ( $dir eq '.' ) )
{
( $dir = `/bin/pwd` ) =~s/\s*$//
}
if ( -1 == rindex $file, '.' )
{
$body=$file; $ext=undef } else { $body = substr $file,0,(rindex $file,'.');
$ext = substr($file,(rindex $file,'.')+1)
}
$ext //= '';
$dir, $file, $body, $ext
}
------------------------------
Date: 21 Sep 2013 19:59:29 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: Re: utilities in perl
Message-Id: <523dfaa1$0$56431$862e30e2@ngroups.net>
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.
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."
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
-------------------------------------------------------------------------------
------------------------------
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 4038
***************************************
