[19691] in Perl-Users-Digest
Perl-Users Digest, Issue: 1886 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 7 09:07:58 2001
Date: Sun, 7 Oct 2001 06:05:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1002459907-v10-i1886@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 7 Oct 2001 Volume: 10 Number: 1886
Today's topics:
Re: Am I asking too much ??? (Logan Shaw)
Re: Am I asking too much ??? (Tana)
Apply Regex In Place <LindaTuner@hotmail.com>
Re: Apply Regex In Place (Mark Jason Dominus)
I was all about to enjoy jive in perl except I don't kn <jidanni@deadspam.com>
Perl 5.6.0 chmod bug? (Doug)
Re: Perl 5.6.0 chmod bug? (Logan Shaw)
Re: Perl 5.6.0 chmod bug? <goldbb2@earthlink.net>
Re: Perl 5.6.0 chmod bug? (Martien Verbruggen)
Re: Perl 5.6.0 chmod bug? (Doug)
Re: Perl 5.6.0 chmod bug? (Doug)
Re: Perl 5.6.0 chmod bug? (Doug)
Re: Perl 5.6.0 chmod bug? (Martien Verbruggen)
Re: Perl 5.6.0 chmod bug? (Mark Jason Dominus)
Re: perl cgi javascript <Dave.Stafford@globis.net>
Re: Perl via metasend <tintin@snowy.calculus>
Problems to expect using Perl scripts with Win9x who we <digirini@xs4all.nl>
question about MAP function, please help. <home@home.com>
Re: time transformation (Logan Shaw)
Re: Trapping sendmail errors (with eval?) (Charles DeRykus)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 6 Oct 2001 22:30:41 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Am I asking too much ???
Message-Id: <9poi91$ao3$1@charity.cs.utexas.edu>
In article <4294f74d.0110061259.67c337a0@posting.google.com>,
Tana <tana@acedsl.com> wrote:
>Jon Ericson <Jon.Ericson@jpl.nasa.gov> wrote in message news:<86itducbrg.fsf@jon_ericson.jpl.nasa.gov>...
>> tana@acedsl.com (Tana) writes:
>> > Could someone give me the equivalent PHP code for this PERL code above?
>> > Am I asking too much ???
>> Frankly, yes. This is a newsgroup for discussion of *perl*. Honestly,
>> you'd be better off finding a group discussing *PHP*.
>Sorry people, but no reason to be rude.
>I was just hoping that someone would know both languages.
>Such a person would be able to give me a straight answer in 5 seconds.
A good general rule for most technical newsgroups, including this one,
is that the people who read the group will be glad to answer a question
someone runs into when trying to solve a problem on their own[1], but
requests for the readers of the group to do the work of solving the
problem are considered rude.
In this newsgroup, that usually works out to mean that questions like
"can anyone give me code to do X?" are considered rude, while questions
like "why does the following short piece of code do X when it seems
like it should do Y?" are generally OK.
And if you got a rude response, keep in mind that the patience of
regular readers has probably worn thin because they have seen so many
"questions" which are really requests for someone to provide free
programming service. Sometimes it's even apparent that the person
asking is receiving money for the solution they deliver to some
customer, yet they're expecting the solution to come for free from the
newsgroup.
- Logan
[1] Provided you've made some effort to figure it out on your own.
If the answer is right there in a very obvious place in the
documentation, it's best not to ask the question.
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
------------------------------
Date: 6 Oct 2001 21:56:47 -0700
From: tana@acedsl.com (Tana)
Subject: Re: Am I asking too much ???
Message-Id: <4294f74d.0110062056.fa96da5@posting.google.com>
Jeff Zucker <jeff@vpservices.com> wrote in message news:<3BBF785A.578AE47B@vpservices.com>...
> Tana wrote:
> >
> > Jon Ericson <Jon.Ericson@jpl.nasa.gov> wrote in message news:<86itducbrg.fsf@jon_ericson.jpl.nasa.gov>...
> > > tana@acedsl.com (Tana) writes:
> > >
> > > > I have the following code in PERL:
> > >
> > > [snip code]
> > >
> > > > My question is:
> > > > Could someone give me the equivalent PHP code for this PERL code above?
> > > > Am I asking too much ???
> > >
> > > Frankly, yes. This is a newsgroup for discussion of *perl*. Honestly,
> > > you'd be better off finding a group discussing *PHP*.
> > >
> > > Jon
> >
> > To All,
> > Sorry people, but no reason to be rude.
>
> In what way is Jon's answer rude? You asked if you were asking too much
> and he (and everyone else) replied that yes you were. If you walked
> into a face-to-face meeting about fish and asked how to repair your
> bicycle, it would not be rude to say, "We are discussing fish here" and
> in fact it would be polite (and accurate) to say "you'd be better off
> finding a place discussing bicycles".
>
> > I was just hoping that someone would know both languages.
>
> The possibility that there are some people in the meeting who know about
> both fish and bicycles is not really relevant to whether bicylces are
> the topic of the meeting.
I was not replying to Jon.
Anyway, I am sorry I made all this mess and I asked wrong question.
Tana
------------------------------
Date: Sun, 07 Oct 2001 10:16:29 GMT
From: "Linda Turner" <LindaTuner@hotmail.com>
Subject: Apply Regex In Place
Message-Id: <1YVv7.64617$0x.22955187@typhoon.southeast.rr.com>
Hello. I don't know a great deal about Perl, my expertise is in
Oracle databases. I found a Perl in the archives that does almost
exactly what I want to do, except for one thing. I want to change all
instances of a database column in a SQL directory to another column
name, and do it in place. The Perl below does that. However, I would
like to do it only to directory members with a .sql extension.
Could someone tell me what I need to do to effect that? I'd be most
grateful.
#!/usr/local/bin/perl -w
use File::Find;
use strict;
$/ = undef;
my $start_dir = 'C:\\UF\\SQL';
File::Find::find( \&each_file, $start_dir );
sub each_file {
if ( -T $_ ) { # ignore non-Text
files
print "processing $File::Find::name\n";
if ( open F, "< $_" ) { # open for reading
my $s = <F>; # slurp in the entire
file
close F;
if ( open F, "> $_" ) { # open again for
writing
$s =~ s/COLUMN1/COLUMN1/ig; # apply global regex
print F $s; # write changed text
close F;
}
else {
print "Error opening file for write: $!\n";
}
}
else {
print "Error opening file for read: $!\n";
}
}
}
------------------------------
Date: Sun, 07 Oct 2001 11:43:02 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Apply Regex In Place
Message-Id: <3bc03fc6.4e1e$26f@news.op.net>
In article <1YVv7.64617$0x.22955187@typhoon.southeast.rr.com>,
Linda Turner <LindaTuner@hotmail.com> wrote:
>I would like to do it only to directory members with a .sql extension.
>
>File::Find::find( \&each_file, $start_dir );
>
>sub each_file {
return unless /\.sql$/; # ignore non '.sql' files
> if ( -T $_ ) { # ignore non-Text files
> print "processing $File::Find::name\n";
...
The rest as before.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: 07 Oct 2001 10:32:39 +0800
From: Dan Jacobson <jidanni@deadspam.com>
Subject: I was all about to enjoy jive in perl except I don't know how to invoke it
Message-Id: <m2elogrxh4.fsf@dan.jacobson.tw>
I'm sorry I've downloaded the perl
http://www.illuminated.co.uk/mung/filters/jive etc. but don't know how to
invoke them without appending a
while (<>) {&filter($_);} to them.
How do I run them intact?
I was thinking something like
$ < input perl -ne '&filter($_)' jive
but of course I can't figure out what to really write from all the
perl manuals due to overwhelmization.
Or maybe I'm missing some wrapper program that calls the filter of my
choice? Help.
--
http://www.geocities.com/jidanni Tel+886-4-25854780
------------------------------
Date: 6 Oct 2001 22:55:12 -0700
From: shadowmint@mailcity.com (Doug)
Subject: Perl 5.6.0 chmod bug?
Message-Id: <56a6cb33.0110062155.31b96ccf@posting.google.com>
Is this a bug, or a feature?
On my version of perl (5.6.0; linux rpm), chmod behaves differently (slightly)
depending on if the mode is a string or a number.
chmod 0700, junk; gives:
-rwx------ 1 doug people 0 Oct 7 13:45 junk
and
chmod "0700", junk; gives:
--w-rwxr-T 1 doug people 0 Oct 7 13:42 junk
It's interpreting the number as octal, but the string as decimal (equivalent
for the first statement would be: chmod "448", junk; I'm having it a bit of
difficultly finding much documentation on chmod about this. Is this the
way it is supposed to function?
Is so? Can anyone enlighten me as to why? It seems nebulous and inconsistant.
cheers,
Doug.
------------------------------
Date: 7 Oct 2001 01:17:48 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <9pos2c$bk9$1@charity.cs.utexas.edu>
In article <56a6cb33.0110062155.31b96ccf@posting.google.com>,
Doug <shadowmint@mailcity.com> wrote:
>Is this a bug, or a feature?
It's a feature, of course. Now let me read your question. :-)
>On my version of perl (5.6.0; linux rpm), chmod behaves differently (slightly)
>depending on if the mode is a string or a number.
>
>chmod 0700, junk; gives:
>-rwx------ 1 doug people 0 Oct 7 13:45 junk
>
>and
>
>chmod "0700", junk; gives:
>--w-rwxr-T 1 doug people 0 Oct 7 13:42 junk
>
>
>It's interpreting the number as octal, but the string as decimal (equivalent
>for the first statement would be: chmod "448", junk; I'm having it a bit of
>difficultly finding much documentation on chmod about this. Is this the
>way it is supposed to function?
Yeah, it's that the it is supposed to function. But when I say that,
I'm talking about a different "it" than you are. Witness this:
$ perl -le 'print 0700 + 0'
448
$ perl -le 'print "0700" + 0'
700
$
So it's not just chmod() that interprets things differently. What's
going on is that Perl treats numeric literals in the program text
differently than it treats strings that need to be converted into
numeric values. (Adding zero forces Perl to make the string into a
numeric value.)
In fact what may be confusing you is the very fact that chmod() DOESN'T
behave differently. In the Unix world, /bin/chmod does behave
differently than most other programs (it expects octal); in Perl,
chmod() behaves just like other functions. That is, Perl doesn't make
chmod() magical in any way. (It certainly could -- it could treat
its first argument as a string and process it specially if it begins
with zero. But apparently it doesn't.)
By the way, "perldoc -f chmod' does sort of explain this.
- Logan
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
------------------------------
Date: Sun, 07 Oct 2001 02:35:14 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <3BBFF7A2.C15B6086@earthlink.net>
Doug wrote:
>
> Is this a bug, or a feature?
>
> On my version of perl (5.6.0; linux rpm), chmod behaves differently
> (slightly) depending on if the mode is a string or a number.
>
> chmod 0700, junk; gives:
> -rwx------ 1 doug people 0 Oct 7 13:45 junk
>
> and
>
> chmod "0700", junk; gives:
> --w-rwxr-T 1 doug people 0 Oct 7 13:42 junk
>
> It's interpreting the number as octal, but the string as decimal
> (equivalent for the first statement would be: chmod "448", junk; I'm
> having it a bit of difficultly finding much documentation on chmod
> about this. Is this the way it is supposed to function?
>
> Is so? Can anyone enlighten me as to why? It seems nebulous and
> inconsistant.
It's not chmod acting funny. It's perls numerification of strings which
is acting different from what you expect.
$ perl -le'print 0700'
448
$ perl -le'print "0700"+0'
700
In the first, perl sees an integer literal. Because it matches the
pattern /^0\d*$/, it gets treated as an octal number, becoming 448.
In the second, perl sees a string literal. Doing a numeric conversion,
it doesn't care what it looks like, it gets treated as a decimal.
Actually, converting a string to a number is done with atof, which is
sometimes a bit strange [in a system dependent way, even]:
$ perl -le'print "0x1.8"+0'
1.5
$ perl -le'print "0x100.8"+0'
1.001953125
$ perl -le'print "0x1.008"+0'
1.001953125
Actually, I sorta understand why the first of these three happens, but I
am at a loss about why the second two produce identical results.
--
"Just how stupid are you Kuno?"
"Verily, Tatewaki Kuno knows no limits."
------------------------------
Date: Sun, 7 Oct 2001 16:29:19 +1000
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <slrn9rvthv.d6o.mgjv@martien.heliotrope.home>
On 6 Oct 2001 22:55:12 -0700,
Doug <shadowmint@mailcity.com> wrote:
> Is this a bug, or a feature?
>
> On my version of perl (5.6.0; linux rpm), chmod behaves differently (slightly)
> depending on if the mode is a string or a number.
Yes, it would, unless your string magically would end up as the correct
mode.
> It's interpreting the number as octal, but the string as decimal (equivalent
It has nothing to do with chmod. This is how Perl numberifies strings.
The leading 0 is only special for numeric literals, not in strings.
> for the first statement would be: chmod "448", junk; I'm having it a bit of
That would _not_ be equivalent, as you now know.
> difficultly finding much documentation on chmod about this. Is this the
> way it is supposed to function?
It is supposed to function like that. The chmod() entry has some info:
$ man perlfunc
[SNIP]
chmod LIST
Changes the permissions of a list of files. The
first element of the list must be the numerical
mode, which should probably be an octal number,
and which definitely should not a string of octal
digits: 0644 is okay, '0644' is not. Returns the
number of files successfully changed. See also
the oct entry elsewhere in this document, if all
you have is a string.
[SNIP]
So, you check oct().
and
$ man perldata
[SNIP]
Hexadecimal, octal, or binary, representations in string
literals (e.g. '0xff') are not automatically converted to
their integer representation. The hex() and oct() func
tions make these conversions for you. See the hex entry
in the perlfunc manpage and the oct entry in the perlfunc
manpage for more details.
[SNIP]
> Is so? Can anyone enlighten me as to why? It seems nebulous and
> inconsistant.
I don't think it's nebulous or inconsistent, but maybe I'm just used to
it.
Martien
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | What's another word for Thesaurus?
NSW, Australia |
------------------------------
Date: 7 Oct 2001 04:11:45 -0700
From: shadowmint@mailcity.com (Doug)
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <56a6cb33.0110070308.44892dab@posting.google.com>
> Yeah, it's that the it is supposed to function. But when I say that,
> I'm talking about a different "it" than you are. Witness this:
>
> $ perl -le 'print 0700 + 0'
> 448
> $ perl -le 'print "0700" + 0'
> 700
> $
I see. I'm not sure what it means... but I see. I'm aware that
448 is 700 in octal... This in fact demonstrates my problem exactly:
If I have a string $permissions, and I want a number in octal to
pass to the chmod function, what do I do?
clearly: print "0700" + 0; returns 700; HOWEVER, it still treats
it as a string. This has -not- forced it into a numeric expression;
for instance:
#!/usr/bin/perl -lw
$val = "0700" + 0;
print $val + 0;
Prints out 700; not the 448 that I would expect if $val had been turned
into a numeric expression (and hence the second line being equivalent of
perl -le 'print 0700 + 0';
As previously.
> So it's not just chmod() that interprets things differently. What's
> going on is that Perl treats numeric literals in the program text
> differently than it treats strings that need to be converted into
> numeric values. (Adding zero forces Perl to make the string into a
> numeric value.)
I've read this. Adding a zero forces perl to make the string into a numeric
value. It doesnt in this case. That's the problem. Or rather it does; it
converts 0700 into 700; but then still treats the 700 as a string, rather
than a numeric expression.
What I want to do is really very simple;
#!/usr/bin/perl -w
$permissions = "0700";
$file = "junk";
chmod $permissions, $file;
and get the resulting file (junk) with the correct permissions. Now; that
doesn't work. Neither does adding in a + 0 anywhere. I've tried;
$permissions = 0;
$permissions += "0700";
chmod $permissions + 0, $file;
chmod "$permissions" + 0, $file;
$new = 1;
$new += $permissions;
chmod "$permissions" + 0, $file;
Even that didn't work. It did the equivalent of oct(701) for the permissions. =P
Any suggestions? I probably sound obtuse, and I'm sorry. :) This is really
frustrating me.
> In fact what may be confusing you is the very fact that chmod() DOESN'T
> behave differently. In the Unix world, /bin/chmod does behave
> differently than most other programs (it expects octal); in Perl,
> chmod() behaves just like other functions. That is, Perl doesn't make
> chmod() magical in any way. (It certainly could -- it could treat
> its first argument as a string and process it specially if it begins
> with zero. But apparently it doesn't.)
I'm not sure I know what you mean. Chmod in this case -is- expecting an octal
value (ie. same as the shell chmod). Perl is simply not turning the string into
a number correctly, so it's getting confused.
for instance; in (very many) perl tutorials you see:
...
chmod 0755, "helloworld.cgi";
...
Ah well.
Thanks for your help,
Ciao,
Doug.
------------------------------
Date: 7 Oct 2001 04:11:50 -0700
From: shadowmint@mailcity.com (Doug)
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <56a6cb33.0110070309.14ad347d@posting.google.com>
> Yeah, it's that the it is supposed to function. But when I say that,
> I'm talking about a different "it" than you are. Witness this:
>
> $ perl -le 'print 0700 + 0'
> 448
> $ perl -le 'print "0700" + 0'
> 700
> $
I see. I'm not sure what it means... but I see. I'm aware that
448 is 700 in octal... This in fact demonstrates my problem exactly:
If I have a string $permissions, and I want a number in octal to
pass to the chmod function, what do I do?
clearly: print "0700" + 0; returns 700; HOWEVER, it still treats
it as a string. This has -not- forced it into a numeric expression;
for instance:
#!/usr/bin/perl -lw
$val = "0700" + 0;
print $val + 0;
Prints out 700; not the 448 that I would expect if $val had been turned
into a numeric expression (and hence the second line being equivalent of
perl -le 'print 0700 + 0';
As previously.
> So it's not just chmod() that interprets things differently. What's
> going on is that Perl treats numeric literals in the program text
> differently than it treats strings that need to be converted into
> numeric values. (Adding zero forces Perl to make the string into a
> numeric value.)
I've read this. Adding a zero forces perl to make the string into a numeric
value. It doesnt in this case. That's the problem. Or rather it does; it
converts 0700 into 700; but then still treats the 700 as a string, rather
than a numeric expression.
What I want to do is really very simple;
#!/usr/bin/perl -w
$permissions = "0700";
$file = "junk";
chmod $permissions, $file;
and get the resulting file (junk) with the correct permissions. Now; that
doesn't work. Neither does adding in a + 0 anywhere. I've tried;
$permissions = 0;
$permissions += "0700";
chmod $permissions + 0, $file;
chmod "$permissions" + 0, $file;
$new = 1;
$new += $permissions;
chmod "$permissions" + 0, $file;
Even that didn't work. It did the equivalent of oct(701) for the permissions. =P
Any suggestions? I probably sound obtuse, and I'm sorry. :) This is really
frustrating me.
> In fact what may be confusing you is the very fact that chmod() DOESN'T
> behave differently. In the Unix world, /bin/chmod does behave
> differently than most other programs (it expects octal); in Perl,
> chmod() behaves just like other functions. That is, Perl doesn't make
> chmod() magical in any way. (It certainly could -- it could treat
> its first argument as a string and process it specially if it begins
> with zero. But apparently it doesn't.)
I'm not sure I know what you mean. Chmod in this case -is- expecting an octal
value (ie. same as the shell chmod). Perl is simply not turning the string into
a number correctly, so it's getting confused.
for instance; in (very many) perl tutorials you see:
...
chmod 0755, "helloworld.cgi";
...
Ah well.
Thanks for your help,
Ciao,
Doug.
------------------------------
Date: 7 Oct 2001 04:11:51 -0700
From: shadowmint@mailcity.com (Doug)
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <56a6cb33.0110070310.357ba01b@posting.google.com>
> Yeah, it's that the it is supposed to function. But when I say that,
> I'm talking about a different "it" than you are. Witness this:
>
> $ perl -le 'print 0700 + 0'
> 448
> $ perl -le 'print "0700" + 0'
> 700
> $
I see. I'm not sure what it means... but I see. I'm aware that
448 is 700 in octal... This in fact demonstrates my problem exactly:
If I have a string $permissions, and I want a number in octal to
pass to the chmod function, what do I do?
clearly: print "0700" + 0; returns 700; HOWEVER, it still treats
it as a string. This has -not- forced it into a numeric expression;
for instance:
#!/usr/bin/perl -lw
$val = "0700" + 0;
print $val + 0;
Prints out 700; not the 448 that I would expect if $val had been turned
into a numeric expression (and hence the second line being equivalent of
perl -le 'print 0700 + 0';
As previously.
> So it's not just chmod() that interprets things differently. What's
> going on is that Perl treats numeric literals in the program text
> differently than it treats strings that need to be converted into
> numeric values. (Adding zero forces Perl to make the string into a
> numeric value.)
I've read this. Adding a zero forces perl to make the string into a numeric
value. It doesnt in this case. That's the problem. Or rather it does; it
converts 0700 into 700; but then still treats the 700 as a string, rather
than a numeric expression.
What I want to do is really very simple;
#!/usr/bin/perl -w
$permissions = "0700";
$file = "junk";
chmod $permissions, $file;
and get the resulting file (junk) with the correct permissions. Now; that
doesn't work. Neither does adding in a + 0 anywhere. I've tried;
$permissions = 0;
$permissions += "0700";
chmod $permissions + 0, $file;
chmod "$permissions" + 0, $file;
$new = 1;
$new += $permissions;
chmod "$permissions" + 0, $file;
Even that didn't work. It did the equivalent of oct(701) for the permissions. =P
Any suggestions? I probably sound obtuse, and I'm sorry. :) This is really
frustrating me.
> In fact what may be confusing you is the very fact that chmod() DOESN'T
> behave differently. In the Unix world, /bin/chmod does behave
> differently than most other programs (it expects octal); in Perl,
> chmod() behaves just like other functions. That is, Perl doesn't make
> chmod() magical in any way. (It certainly could -- it could treat
> its first argument as a string and process it specially if it begins
> with zero. But apparently it doesn't.)
I'm not sure I know what you mean. Chmod in this case -is- expecting an octal
value (ie. same as the shell chmod). Perl is simply not turning the string into
a number correctly, so it's getting confused.
for instance; in (very many) perl tutorials you see:
...
chmod 0755, "helloworld.cgi";
...
Ah well.
Thanks for your help,
Ciao,
Doug.
------------------------------
Date: Sun, 7 Oct 2001 21:40:33 +1000
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <slrn9s0fph.d6o.mgjv@martien.heliotrope.home>
On 7 Oct 2001 04:11:50 -0700,
Doug <shadowmint@mailcity.com> wrote:
> Even that didn't work. It did the equivalent of oct(701) for the
> permissions. =P
What about doing an actual oct("0700") to get the correct integer?
Martien
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | What's another word for Thesaurus?
NSW, Australia |
------------------------------
Date: Sun, 07 Oct 2001 12:37:23 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Perl 5.6.0 chmod bug?
Message-Id: <3bc04c81.4f7b$9f@news.op.net>
In article <56a6cb33.0110070308.44892dab@posting.google.com>,
Doug <shadowmint@mailcity.com> wrote:
>If I have a string $permissions, and I want a number in octal to
>pass to the chmod function, what do I do?
You use the oct() function to interpret the string as an octal numeral.
In Perl, strings that look like numerals are *always* interpreted as
*decimal* unless you use something like oct().
>clearly: print "0700" + 0; returns 700; HOWEVER, it still treats
>it as a string. This has -not- forced it into a numeric expression;
Yes, it has. It has been interpreted as the number 700.
>#!/usr/bin/perl -lw
>$val = "0700" + 0;
>print $val + 0;
>
>Prints out 700; not the 448 that I would expect if $val had been turned
>into a numeric expression (and hence the second line being equivalent of
0700 only means an octal numeral when it appears as a literal token in
the source code. Here there is no numeric constant. Instead, you
have the string "0700", which is not the same as the number 700, and
not the same as the number 448. When you use it with the addition
operator, Perl must convert this STRING to a number.
It could do that by converting it as if it were an octal numeral, but
it doesn't. (For very good reasons; you might want to consider why
this is so; the answer is at the bottom of this article.) Perl
converts it as if it were a decimal numeral. Perl *always* interprets
strings as decimal numerals when it needs to convert them to numbers.
>perl -le 'print 0700 + 0';
>
>As previously.
Well, there's no string constant there. In the source code, a literal
constant beginning with a 0 is an octal numeral.
Look:
print "time()" + 0;
does not do the same thing as
print time() + 0;
so why would you expect "0700" and 0700 to be the same? Converting a
string to a number does not mean just dropping the quotes. The
computer's internal representations of strings and numbers are more
complicated than that.
>I've read this. Adding a zero forces perl to make the string into a numeric
>value. It doesnt in this case.
It does. "0700" is a string. It has *no* connection with the
computer's internal representation of the number 700. The computer
cannot do arithmetic on a string like "0700", so Perl must convert it
to a number.
Hmm. Do you program in C? (If not, this next example is unlikely to
be illuminating.) The C version of chmod() is called chmod().
What would you expect to happen if you did
chmod(file, "0700");
in C? Would you expect this to work? It doesn't.
>#!/usr/bin/perl -w
>$permissions = "0700";
>$file = "junk";
>chmod $permissions, $file;
You want
chmod oct($permissions), $file
or die ...;
>Any suggestions?
Yes, I think I understand where your conceptual problem is:
>I'm not sure I know what you mean. Chmod in this case -is- expecting an octal
>value
This is it. There *is no such thing* as an 'octal value'.
'Octal' is a way of representing a number as a sequence of digits.
Decimal is another such way. Numbers and values cannot be octal or
decimal; only strings can be octal or decimal, because 'octal' and
'decimal' are rules for the interpretation of character sequences.
We use the word 'numeral' for a character sequence that happens to
represent some number. You may be confusing numerals with numbers.
The situation is further complicated by the fact that the numeral
'700' has one meaning in the octal system and a different meaning in
the decimal system.
When the computer does arithmetic, it does not use either the octal or
the decimal system. There is nothing special about either of these as
far as the computer is concerned; they are both equally useless for
arithmetic.
When the computer wants to add numbers, it is constrained by its
hardware to use a special internal representation that is neither
octal nor decimal. The internal representation is usually some
variation of base 256. When we talk about the computer storing a
'numeric value', the value must be in this format. If data is not in
this format, the computer cannot do arithmetic on it.
That is why it does not make sense to talk about an 'octal value'.
Only numerals are octal. But numerals are not values; they are only
representations of values. Numeric values in the computer are always
in the special base-256 representation.
Base-256 numbers are hard to type and to read, so I will use <<002A>>
to represent the number 42 in the internal base-256 representation.
It's important to remember that the '0' and the '2' and the 'A' are
ficitons; there is no 0, 2, or A anywhere. It's just a notation.
Now, what does this do?
chmod 700, $file;
When your program is compiled, the Perl compiler sees the character
sequence '7', '0', '0' in your code. This has the form of a decimal
constant, so Perl compiles it to the internal representation <<02bc>>.
Later on, the chmod() is performed, and sets the permissions to the
number <<02bc>>, which is interpreted by the Unix kernel as -w-rwxr-T.
Whoops.
chmod 0700, $file;
When your program is compiled, the Perl compiler sees the character
sequence '0', '7', '0', '0' in your code. This has the form of an
octal constant, so Perl compiles it to the internal representation
<<01c0>>. Later on, the chmod() is performed, and sets the
permissions to the number <<01c0>>, which is interpreted by the Unix
kernel as rwx------.
chmod "0700", $file;
When your program is compiled, the Perl compiler sees the character
sequence '"', '0', '7', '0', '0', '"' in your code. This has the form
of a string constant, so Perl compiles it to a STRING. It does not
compile it as if it were an octal numeral, because octal numerals
start with 0, not with ". It does not compile it as if it were a
decimal numeral, because decimal numerals start with 1-9, not with ".
It is a string constant and it is compiled to a string. Perl's
internal representation of a string is very complicated. But hiding
somewhere inside it is the character sequence "0700", which might have
the internal representation <<30373030>>.
Later on, the chmod() is performed. Perl's chmod() function sees that
the argument is not a number, but a string. It knows that the Unix
chmod() requires a number, not a string. So it converts the string to
a number. When Perl converts a string to a number, it always
interprets it as a decimal numeral, and <<30373030>> is converted to
<<02bc>>, not to <<01c0>>, because "0700" is the decimal
representation of <<02bc>>. The Unix chmod() sets the permissions to
the number <<02bc>>, which is interpreted by the Unix kernel as
-w-rwxr-T. Whoops.
chmod oct("0700"), $file;
When your program is compiled, the Perl compiler sees the character
sequence '"', '0', '7', '0', '0', '"' in your code. This has the form
of a string constant, so Perl compiles it to a string. Perl also
compiles additional code that will pass this string to the oct()
function and use the return value in the chmod().
Later on, the code is executed. Perl's oct() function sees that the
argument is not a number, but a string. The purpose of oct() is to
transform a string in octal representation to a number in the
computer's internal representation. <<30373030>> is converted to the
number <<01c0>> by the oct() function, because "0700" is the octal
representation of <<01c0>>. This number is passed to chmod(), which
sets the permissions to <<01c0>>, which is interpreted by the Unix
kernel as rwx------.
>Perl is simply not turning the string into a number correctly,
That depends on what you mean by 'correctly'.
Strings are always turned into numbers by interpreting them as
*decimal numerals*. This is the correct behavior. It is not what you
happened to want on this occasion, but that does not mean it was
incorrect.
When Perl compiles a numeric constant in your source code, it
interprets it as octal if the constant begins with a 0. It does not
do this when converting a string constant to a number. Why not? What
if it did? This is why not:
open D, "< data" or die;
while (<D>) {
$total += $_;
}
print "The total is: $total\n";
Suppose the data file contained
800
123
070
Wouldn't people be surprised if this program printed out anything
other than 993? But with your suggestion, the 070 line is converted
to the number 56 and the total is 979. People would be very upset by
this. "I just want to add up a bunch of numbers!" they would say.
"Why do I have to worry about this octal business?"
Every program in Perl that wanted to convert a string to a number
would have to do s/^0+//; on the string, to make sure it wa converted
correctly, and not as an octal numeral.
That would be a much bigger pain in the ass than making people write
oct() in the chmod()'s once in a while.
Well, that was a lot of yak, but I hope some of it was helpful.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: Sun, 07 Oct 2001 11:35:11 GMT
From: "Dave Stafford" <Dave.Stafford@globis.net>
Subject: Re: perl cgi javascript
Message-Id: <P5Xv7.22002$DJ3.1901608@nlnews00.chello.com>
>> It is easy enough to validate data from the
>> CGI and spit out the form with submitted values and flagged errors for
>> further editing using CGI.pm
>>
> i usually do both: validate data on the client-side with javascript and
> server-side in perl in case the client has the javascript disabled.
Absolutely. Why waste time, bandwidth and server processing power if
you can have the client do the initial check. Of course the server still
should do the checks as well as the javascript is easily bypassed.
If the client does not support javascript, you have not lost anything.
Javascript is a very useful addition to making robust forms, it is a shame
that the browser developers agree on a single implementation.
Dave
------------------------------
Date: Sun, 7 Oct 2001 17:20:38 +1000
From: "Tintin" <tintin@snowy.calculus>
Subject: Re: Perl via metasend
Message-Id: <foTv7.8$wM5.12386480@news.interact.net.au>
"Rodney" <kc5sbj@yahoo.com> wrote in message
news:4c772a11.0110060903.5aa4bac8@posting.google.com...
> Bart Lateur <bart.lateur@skynet.be> wrote in message
news:<vebkrtgl9cb6nvcbbq0q9kivdf1ae7060r@4ax.com>...
> > Donnajeanne Liu wrote:
> >
> > [snip]
> >
> > >How do I send 1 email, using metasend, with 2 files attached?
> >
> > Gee. I think it would be easiest to drop all this, and just use
> > Mime::Lite both to construct the mail with attachments, and send it.
>
> How does one use MIME::Lite do send attachments? I have bee trying
> with no success using code in the Summer 1999 PERL Journal. I can get
> the mail sent only if I do not attempt attachments.
Have you tried the many examples in the MIME::Lite docs? It's pretty easy.
------------------------------
Date: Sun, 07 Oct 2001 12:45:09 +0200
From: Rinus Luijmes <digirini@xs4all.nl>
Subject: Problems to expect using Perl scripts with Win9x who were written with Linux
Message-Id: <7rb0st00apvsc358d7mj0gr2bu6hort9gr@4ax.com>
I want to make a Perl script that must be used in DOS under Win9x but
I myself use Linux to write scripts. This simple script opens a
textfile, manipulates matching lines and writes a corrected new
textfile. What problems can I expect using this different OS and what
can I do while writing this script to prevent them?
TIA,
--
Rinus Luijmes
www.xs4all.nl/~digirini N 51°57.032' E 006°24.689'
------------------------------
Date: Sun, 07 Oct 2001 08:16:21 GMT
From: Qiang <home@home.com>
Subject: question about MAP function, please help.
Message-Id: <pbUv7.211256$j65.50706539@news4.rdc1.on.home.com>
Hi, all
there are too many perl functions and a lot i need to learn how and when to
use them. now after reading the doc for map function , i am still
confused. here i have two codes which i don't quiet sure what's going on
there and has been keep me up a while tonight. @-)
#1
@sizes = map { -s $_ } @file_names;
my understanding is , elements in @file_names gets read one by one and
saved into $_ , then the block function evalutes each of them i.e the "-s
$_" and put it into @size array. am i right ?
#2:
@a = ('a'..'z');
@b = (0..5);
$c = map {$a[int rand @a]} @b;
print "$c \n";
i got the output as uncertain alphebet combination in length 6. again, my
understanding is : @b gets read and store in $_ one by one. but here we did
not use $_ , so @b works in the map function just like while loop as ..
$c .= $chars[rand @chars] while length $c < $length;
my another question arises.... under what situation should i use map ?
which way is better ? does it make really difference between map code with
this while one regardless of the length of the code , is the
time-consuming ?
thanks
.QiaNg
------------------------------
Date: 6 Oct 2001 22:18:26 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: time transformation
Message-Id: <9pohi2$akh$1@charity.cs.utexas.edu>
In article <3BBF6515.FDCCBD78@yahoo.com>,
Zimmen Gnauh <yah00204052@yahoo.com> wrote:
> What's the simplest way to tranform 12 hour format time into 24 hour
>format, i.e.
> 9:20am ->9:20
> 12:30pm ->12:30
> 4:30pm ->16:30
Others have posted various solutions. Here's a string-oriented
approach:
$time =~ s/12:/0:/; # special cases
$time =~ s/(\d+):(\d+)pm/($1+12).":$2"/e; # handle pm
$time =~ s/am//; # handle am
$time =~ s/24:/0:/; # midnight -> 00
Hope that helps.
- Logan
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
------------------------------
Date: Sun, 7 Oct 2001 07:54:20 GMT
From: ced@bcstec.ca.boeing.com (Charles DeRykus)
Subject: Re: Trapping sendmail errors (with eval?)
Message-Id: <GKtsMK.2HM@news.boeing.com>
In article <fedb623e.0110031629.71534241@posting.google.com>,
Bill Dykstra <bill@ilap.com> wrote:
>Greetings,
>
>I'm having some trouble trapping a fatal sendmail error when trying to
>send email messages. Every now and then sendmail is not available
>(ie: somebody stopped the sendmail process, which happens now and then
>if the sendmail config files are being rebuilt). If my program is
>running, and is in the process of sending a message or messages when
>sendmail is stopped, it crashes, usually with an error such as this:
>
>No local mailer defined
>QueueDirectory (Q) option must be set
>
>Because of this sendmail error, my perl program dies. I've tried
>using eval to trap the error, but I can't get it to work.
>
>Here's a sample of the code I'm trying to use:
>
> eval {
> if (open(MAIL, "| /usr/lib/sendmail -t -oi")) {
> print MAIL "To: $target_address\n";
> print MAIL "From: $source_address\n";
> print MAIL "Subject: Test Message\n";
> print MAIL "\n";
> print MAIL "blah blah blah.....\n";
> if (! close(MAIL)) {
> print "Message $counter not sent. Cannot close mail: $!
>\n";
> }
> }
> else {
> print "Cannot open mail: $! \n";
> }
> };
> warn $@ if $@;
>}
>
>Now, I don't really want to just "warn" when an error occurs. What I
>will be doing is looping and resending the message a few seconds later
>if the error occurs, since sendmail is usually available within a
>couple of seconds. The problem is, I can't even trap the error in
>the first place, so I have no way to loop and retry if sendmail fails.
>
>Any suggestions? Any help will be greatly appreciated!
The untimely demise of sendmail is likely generating
a SIGPIPE which you haven't caught. You might try:
eval {
local $SIG{PIPE} = sub { die "sendmail pipe broke" };
if (open(MAIL, "| /usr/lib/sendmail -t -oi")) {
...
};
if ($@ =~ /^sendmail pipe broke/) {
...
Another avenue might be the builtin IPC::Open3 if
you want to capture sendmail's error message.
--
Charles DeRykus
------------------------------
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:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V10 Issue 1886
***************************************
