[32189] in Perl-Users-Digest
Perl-Users Digest, Issue: 3454 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 25 18:09:22 2011
Date: Mon, 25 Jul 2011 15:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 25 Jul 2011 Volume: 11 Number: 3454
Today's topics:
javascript to cgi param <nospam.gravitalsun@hotmail.com.nospam>
Re: javascript to cgi param <jurgenex@hotmail.com>
Re: javascript to cgi param <nospam.gravitalsun@hotmail.com.nospam>
Re: Ownership of a file in unix file system <blmblm.myrealbox@gmail.com>
Re: Script to align columns in a text table. <jimsgibson@gmail.com>
Re: stuck in regex <tadmc@seesig.invalid>
Re: stuck in regex sln@netherlands.com
Re: syntax query: ($var++ && next) if /match/ <jimsgibson@gmail.com>
Re: syntax query: ($var++ && next) if /match/ <blmblm.myrealbox@gmail.com>
Re: why won't perl say which value was uninitialized? <tadmc@seesig.invalid>
Re: why won't perl say which value was uninitialized? <rweikusat@mssgmbh.com>
Re: why won't perl say which value was uninitialized? <hjp-usenet2@hjp.at>
Re: why won't perl say which value was uninitialized? <rweikusat@mssgmbh.com>
Re: why won't perl say which value was uninitialized? <kst-u@mib.org>
Re: why won't perl say which value was uninitialized? <rweikusat@mssgmbh.com>
Re: why won't perl say which value was uninitialized? <kst-u@mib.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 25 Jul 2011 16:29:57 +0300
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: javascript to cgi param
Message-Id: <j0jr41$eg1$1@news.ntua.gr>
I want to make something using the CGI module.There are some javascript user
clickable widgets I would like to use. Do you know any way to grub their
values and use them as $cgi->param('something') ?
------------------------------
Date: Mon, 25 Jul 2011 08:37:10 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: javascript to cgi param
Message-Id: <173r27pf6kihk3dj7c9vvbc4nuhhmsql4k@4ax.com>
"George Mpouras" <nospam.gravitalsun@hotmail.com.nospam> wrote:
>I want to make something using the CGI module.There are some javascript user
>clickable widgets I would like to use. Do you know any way to grub their
>values and use them as $cgi->param('something') ?
No,there isn't unless those javascript user clickable widgets do http
get or http post and include their values in those get or post requests.
And if they do then from a Perl perspective they are no different than
any other parameter in a get or post.
jue
------------------------------
Date: Mon, 25 Jul 2011 21:24:08 +0300
From: George Mpouras <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: javascript to cgi param
Message-Id: <j0kcc9$102r$1@news.ntua.gr>
Ok, thanks Jürgen
------------------------------
Date: 25 Jul 2011 19:46:46 GMT
From: blmblm@myrealbox.com <blmblm.myrealbox@gmail.com>
Subject: Re: Ownership of a file in unix file system
Message-Id: <995vh6F6kpU3@mid.individual.net>
In article <lb4m27p3asd2t95m2g9jgjae1b3fro19ru@4ax.com>,
John <John.Smith@invalid.com> wrote:
(I guess you're the OP, although you seem to be using a different
identity to reply .... Just sayin'.)
> blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:
>
> >In article <862l27lkndps56truopihbm1b24b8g6ugn@4ax.com>,
> > <spam_filter@invalid.nil> wrote:
> >
> >I think your question might be more a UNIX / web server question
> >than a Perl question, and you might get better answers somewhere
> >else (though I'm not sure what group to recommend). But maybe
> >I can say/ask a few marginally useful things:
> >
> >> I need to create a file on a web server (running unix) and set its permission so
> >> that no-one, except with correct ftp username & password can download or view it.
> >
> >What do you mean by "correct ftp username & password" here?
>
> I create the TEST.PL file with a notepad program on my home computer. Then I
> upload it to the web server using FileZilla (an ftp client program). I also use
> FileZilla to download the NEWTEXT.TXT file to see what's in it. To log on to the
> server I need username and password.
Okay, so you want access to the generated file (newtext.txt) to
happen only if you supply this username and password?
> >> On my wwww server I've created test.pl. When I go to
> >> www.notareal.com/cgi-bin/test.pl
> >> Firefox shows "Hello world" as expected. When I use a FTP program the check if
> >> newtext.tx has been created it's there OK.
> >
> >"There"? Where? (This affects which users can access it.)
>
> On the web server. Users access via web using, say, Firefox and going to
> www.notareal.com/cgi-bin/test.pl
> Once they see "Hello World" they should be able to go to
> www.notareal.com/cgi-bin/newtext.txt
> or atleast something should come up on the browser.
But now you seem to be saying that anyone who can (successfully)
point a browser at the CGI program should also be able to view the
generated file. ?
> >> The problem is that I cannot download the newtext.txt or view it. I can delete it
> >> but that's just about it.
> >>
> >>
> >> Here is a simple test.pl:
> >>
> >> #!/usr/bin/perl
> >> print "Content-Type: text/html; charset=iso-8859-1\n\n";
> >> print '<html><BODY>';
> >> open(TEKSTI,">newtext.txt");
> >> print TEKSTI "just testing";
> >> close(TEKSTI);
> >> chmod 0600,"newtext.txt"; ## The problem line
> >> print "Hello world</body> </HTML>";
> >>
> >>
> >>
> >> If I leave out the problem line everything works but the file is set as 644 and
> >> not 600. Can I leave it as 644? Can someone without user name and password still
> >> access it from browsers or other program?
> >
> >644 is world-readable, so the answer is sort of "yes", though it
> >also depends on permissions of enclosing directories.
> >
> >> I tried this on another www page and it worked there ok.
> >
> >"Another www page"? do you mean another CGI program, or what?
>
> I uploaded the very same TEST.PL on www.anotherofmyhomepages.com and then used
> Firefox to see if I get an 404 error or "Hello world". I get the greeting. In
> addition to greeting message a file NEWTEXT.TXT should have been created on the
> server (it has).
That it doesn't work the same way on the two sites isn't totally
surprising -- they could have their Web servers configured differently.
(Some of the other replies to your original post have given some
specifics about that.)
> >One question I would ask is this: What does newtext.txt show as
> >its owning UID? (I'm thinking it might be a UID belonging to the
> >Web server, and that might not be what you intended.)
>
> When I use Filezilla to look at the file listing on the server I see the
> NEWTEXT.TXT is 0600 80 80 which means that its a file that owner (me) can modify
> and read but not some anonymous user. The "80 80" means owner is "no-one".
>
> On www.anotherofmyhomepages.com NEWTEXT.TXT is 0600 80 80 and it can be accessed,
> modified, deleted withe FileZille ftp client program.
> However, on www.notareal.com NEWTEXT.TXT is also 0600 80 80 and but it can only
> be deleted with FileZille ftp client program. Any modification (change 0600 ->
> 0755 etc), download is not possible.
But *this* difference makes no sense to me -- it seems to me that the
permissions and ownership are the same on both, so why would what you
can do with the file be different? Hm.
Is it at all possible that the owning UIDs are different despite what
FileZilla is telling you??
> What I am thinking is that is the some other Perl command I should use for
> compatibility.
I'm really, really skeptical that you will be able to solve this
problem by doing something with your Perl program. I could be
wrong, but it seems to me that the problem here has more to do
with how the systems you're trying to work with are configured,
and that you should either ask this question again in another group
where such questions are on-topic, or possibly ask the tech-support
people at www.notareal.com and/or www.anotherofmyhomepages.com.
> Or is there some guideline that "you should not create files in
> cg-bin directory" etc.
Well, it seems to me that there are security risks associated with
a world-accessible CGI program being able to create files on the
Web server. I know so little about this that I hesitate to say
any more than that, but I know I've hesitated to deploy CGI scripts
that need to create/modify files because I didn't feel like I knew
enough to do so safely and didn't quite have the time and inclination
to dig into the subject.
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
------------------------------
Date: Mon, 25 Jul 2011 09:32:45 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Script to align columns in a text table.
Message-Id: <250720110932450319%jimsgibson@gmail.com>
In article <LpKdnZJVmux6k7HTnZ2dnUVZ7sqdnZ2d@bt.com>, RedGrittyBrick
<RedGrittyBrick@SpamWeary.invalid> wrote:
> I use a plain-text mark-up system to produce HTML and PDF documents from
> plain text files which I edit using a text editor.
> (see http://superuser.com/questions/209897/text-formatter-tools/)
>
> When you edit a table in the midst of a file, it is tedious to insert or
> delete numerous spaces to get the columns to line up. I needed to filter
> chunks of text through a tool a little better suited to this than Unix's
> `column` utility - so I wrote the following Perl script.
>
Have you looked at the Text::Table module? (I have not used it).
--
Jim Gibson
------------------------------
Date: Mon, 25 Jul 2011 08:50:23 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: stuck in regex
Message-Id: <slrnj2qsn0.l4i.tadmc@tadbox.sbcglobal.net>
elliot <elliot@example.net> wrote:
> On 07/24/2011 07:27 AM, Tad McClellan wrote:
>> elliot<elliot@example.net> wrote:
>>> remove an integer if it is the first word in a line, as well
>>> as whitespace thereafter.
>>
>>
>> perl -pe 's/^\s*\d+\s+//' cfile.c
>>
>>
>
> Nice:
A nice result is often possible once there is a clear and
unambiguous statement of what is to be accomplished.
Have you seen the Posting Guidelines that are posted here frequently?
> Sometimes simple and elegant are the same things.
A problem well stated is a problem half-solved.
-- Charles Kettering
[ I graduated from Kettering High School ]
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Mon, 25 Jul 2011 13:00:30 -0700
From: sln@netherlands.com
Subject: Re: stuck in regex
Message-Id: <94ir27ljjr2ave8parn0lis3ot4h4ilmsu@4ax.com>
On Sun, 24 Jul 2011 21:00:45 -0600, elliot <elliot@example.net> wrote:
>On 07/24/2011 12:13 PM, sln@netherlands.com wrote:
>
>> That script produces this output:
>>
>> #include<stdio.h>
>> #include<malloc.h>
>> voidtestc(double **pa)
>> {doubleb;
>> double*a;
>> intm;
>> a= (double*) malloc(sizeof(double)*);
>> a[]=1.23;a[]=2.46;a[]=3.69;a[]=4.11;a[]=7.21;*pa=a;for(m=;m<5;m++)
>> {b=a[m];b=b+.0;a[m]=b;}}
>>
>>
>> Doesen't make a lot of sence.
>
>What input files were you using?
>
>$ cat cfile3.c
> 1 #include <stdio.h>
> 2 #include <malloc.h>
> 3
> 4 void testc(double **pa)
> 5 {
> 6 double b;
> 7 double *a;
> 8 int m;
> 9
> 10 a = (double*) malloc(sizeof(double)*5);
> 11 a[0]=1.23;
> 12 a[1]=2.46;
> 13 a[2]=3.69;
> 14 a[3]=4.11;
> 15 a[4]=7.21;
> 16 *pa=a;
> 17 for (m=0;m<5;m++)
> 18 {
> 19 b=a[m];
> 20 b=b+1.0;
> 21 a[m]=b;
> 22 }
> 23 }
>
>
>// gcc -c -Wall -Wextra cfile2.c -o testc.o
>
>Something like this?
The line numbering wasn't apparent (to me) as being the thing you
wanted stripped. Why not just use a copy of the original?
But, if that's the case, its easy to strip.
Below is what you would do to preserve the original source formatting
(incase of a compile error that you might need a reference back to).
-sln
use strict;
use warnings;
$/ = undef;
my $src = <DATA>;
my $maxpad = 20;
while ($src =~ / ^ [^\S\n]* \d+ ([^\S\n]+) /xmg) {
if (length $1 < $maxpad) {
$maxpad = length $1
}
}
print "\nmaximum whitespace pad after line number = $maxpad\n\n",'-'x20,"\n\n";
$src =~ s/ ^ [^\S\n]*\d+[^\S\n]{0,$maxpad} //xmg;
print "'$src'\n";
__DATA__
1 #include <stdio.h>
2 #include <malloc.h>
3
4 void testc(double **pa)
5 {
6 double b;
7 double *a;
8 int m;
9
10 a = (double*) malloc(sizeof(double)*5);
11 a[0]=1.23;
12 a[1]=2.46;
13 a[2]=3.69;
14 a[3]=4.11;
15 a[4]=7.21;
16 *pa=a;
17 for (m=0;m<5;m++)
18 {
19 b=a[m];
20 b=b+1.0;
21 a[m]=b;
22 }
23 }
Output:
maximum whitespace pad after line number = 1
--------------------
'#include <stdio.h>
#include <malloc.h>
void testc(double **pa)
{
double b;
double *a;
int m;
a = (double*) malloc(sizeof(double)*5);
a[0]=1.23;
a[1]=2.46;
a[2]=3.69;
a[3]=4.11;
a[4]=7.21;
*pa=a;
for (m=0;m<5;m++)
{
b=a[m];
b=b+1.0;
a[m]=b;
}
}'
------------------------------
Date: Mon, 25 Jul 2011 09:20:31 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <250720110920316273%jimsgibson@gmail.com>
In article <87ipqrrgx1.fsf@sapphire.mobileactivedefense.com>, Rainer
Weikusat <rweikusat@mssgmbh.com> wrote:
> blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> writes:
> > In article <87sjpy9wte.fsf@sapphire.mobileactivedefense.com>,
> > Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> [...]
>
> >> Why this, since it does exactly what its literal meaning appears to
> >> be:
> >>
> >> $seen = 1 and next if /^paul/
> >
> > I would say that this line of code has an unambiguous literal
> > meaning only to someone who knows the relative precedence of all
> > the operators.
>
> To someone who is aware of the concept of 'operators with different
> precedence' but who doesn't really now what the precedence happens to
> be *and* who isn't willing to look it up in the manual, no code
> sequence has an unambigious meaning. But - imagine that - people
> actually use language for everyday communication and manage to make
> this work.
There is no ambiguity to the block form:
if( /^paul/ ) {
$seen = 1;
next;
}
That is the point. The three constructs are separated by braces and
semi-colons, and the order of execution does not depend upon precedence
rules.
>
>
> > And (as someone else pointed out) what if the
> > assignment was "$seen = 0"?
>
> The assignment isn't $seen = 0. Making uninformed changes to working
> code (such as turning $seen = 1 and next into $seen = 0 and next) may
> (and likely will) result in code which doesn't work anymore.
But if the algorithm requires that $seen be set to zero, then the
construct will not work anymore, and the programmer will have to use a
different one. That is not the case for the block form.
>
> [...]
>
> >> (set $seen to 1 and execute next if $_ matches /^paul/)
> >
> > But isn't that sentence also potentially ambiguous?
>
> 'Potentially ambiguous' is a combination of terms which makes no
> sense (everything is 'potentially ambiguous'). Generally, sentences
> don't have an unambiguous meaning outside of the (con)text they were
> meant to be part of and this is still the statement + statement
> modifier situation.
English and other natural languages can be ambiguous. Computer
languages should minimize ambiguity.
That is the point.
--
Jim Gibson
------------------------------
Date: 25 Jul 2011 19:49:13 GMT
From: blmblm@myrealbox.com <blmblm.myrealbox@gmail.com>
Subject: Re: syntax query: ($var++ && next) if /match/
Message-Id: <995vlpF6kpU4@mid.individual.net>
In article <87ipqrrgx1.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> writes:
> > In article <87sjpy9wte.fsf@sapphire.mobileactivedefense.com>,
> > Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> [...]
>
> >> A text doesn't become easier to understand by adding more
> >> non-alphanumeric characters to it.
> >
> > Presumably you mean "program text" here (since if you could also mean
> > natural language text I would respectfully disagree and I suspect you
> > would too since as this sentence is meant to demonstrate punctuation
> > can be very helpful in making sense of long sentences and indeed in
> > separating sentences not to mention that without nonalphanumerics
> > you couldnt spell contractions right).
>
> ,,!`!I%%^^^actu;;;;!ly```````mea::@:@n#~~tt\||||||ext$$
Ah well, I didn't realize that when you said "adding more ....
characters" you meant "at random, with no particular concern for
whether the added characters are helpful". "Whatever", maybe.
>
> [...]
>
> > The case is perhaps less clear for program text, but I would argue
> > that judicious use of parentheses, even when not needed, is an
> > aid to understanding. Then again, I'm probably biased by the fact
> > that I'd rather put in some unnecessary parentheses from time to
> > time than try to keep in my head a table of operator precedences.
> > For example, I would rather just write
> >
> > (a && b) || (c && d)
>
> That's not a suitable example because the parentheses in the original
> code were not used to clarify the precedence within a complex
> expression but to separate a statement/expression [$seen = 1 and next]
> from a statement modifier.
Oh, I think it's quite a suitable example of what I meant.
Now, if *your* statement ("a text doesn't become easier ....")
wasn't actually intended to apply fairly broadly, then okay,
examples of parentheses used to clarify precedences aren't relevant.
But this is getting contentious, for no good purpose I can think of,
so onward .... :
With reference to the specific example, I would argue that someone
whose knowledge of Perl is limited may not realize that the clause
beginning "if" is a "statement modifier" (with the implication that
it applies to the whole statement rather than some smaller unit).
Parentheses would remove that source of possible confusion.
> [...]
>
> >> Why this, since it does exactly what its literal meaning appears to
> >> be:
> >>
> >> $seen = 1 and next if /^paul/
> >
> > I would say that this line of code has an unambiguous literal
> > meaning only to someone who knows the relative precedence of all
> > the operators.
>
> To someone who is aware of the concept of 'operators with different
> precedence' but who doesn't really now what the precedence happens to
> be *and* who isn't willing to look it up in the manual, no code
> sequence has an unambigious meaning.
True. My preference is for a style that doesn't depend quite so much
on details I don't care to remember. Others' mileage obviously varies.
> But - imagine that - people
> actually use language for everyday communication and manage to make
> this work.
What is "this" here? Are we talking about code or natural language?
It sounds like you mean the latter, and while yes we usually *do*
manage to make that work, I've certainly been in situations in which
text-only natural-language communication went badly wrong because
the sender and receiver interpreted a particular combination of
words differently.
> > And (as someone else pointed out) what if the
> > assignment was "$seen = 0"?
>
> The assignment isn't $seen = 0. Making uninformed changes to working
> code (such as turning $seen = 1 and next into $seen = 0 and next) may
> (and likely will) result in code which doesn't work anymore.
Exactly. But the difference is not just that a different value is
assigned (which yes might have unwanted consequences) but that ....
Well, I think you addressed this point in a later post, and it sounds
like you agree that using "and" here was not really a good idea.
> [...]
>
> >> (set $seen to 1 and execute next if $_ matches /^paul/)
> >
> > But isn't that sentence also potentially ambiguous?
>
> 'Potentially ambiguous' is a combination of terms which makes no
> sense (everything is 'potentially ambiguous').
Eh, I suppose.
> Generally, sentences
> don't have an unambiguous meaning outside of the (con)text they were
> meant to be part of and this is still the statement + statement
> modifier situation.
I understood your "(set ...." line to be intended as pseudocode
or perhaps some variant of natural language. Was that not what you
meant? In that context, how is a reader supposed to know that the
"if" is a "statement modifier" rather than something that modifies
some smaller unit?
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
------------------------------
Date: Mon, 25 Jul 2011 09:08:34 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: why won't perl say which value was uninitialized?
Message-Id: <slrnj2qtp3.l4i.tadmc@tadbox.sbcglobal.net>
jidanni@jidanni.org <jidanni@jidanni.org> wrote:
> I don't see why messages like
> Use of uninitialized value in print at bla.pl line 44
> can't say which value was it that was uninitialized.
> Is it really that much skin off perl's back?
> Why must it hold its cards so close to its chest?
> It knows exactly which of the say 50 variables had the problem,
What if it was not a variable at all?
print give_undef(), "\n";
sub give_undef { return undef }
What should it say in that case?
> why doesn't
> it cough up the details
It will try if you have v5.10 or better.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Mon, 25 Jul 2011 16:06:36 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: why won't perl say which value was uninitialized?
Message-Id: <871uxecscj.fsf@sapphire.mobileactivedefense.com>
Tad McClellan <tadmc@seesig.invalid> writes:
> jidanni@jidanni.org <jidanni@jidanni.org> wrote:
>> I don't see why messages like
>> Use of uninitialized value in print at bla.pl line 44
>> can't say which value was it that was uninitialized.
>> Is it really that much skin off perl's back?
>> Why must it hold its cards so close to its chest?
>> It knows exactly which of the say 50 variables had the problem,
>
>
> What if it was not a variable at all?
>
> print give_undef(), "\n";
> sub give_undef { return undef }
>
> What should it say in that case?
"Alle Wege des Marximus fuehren nach Moskau!"
That's a historic election slogan of the Bavarian branch of the
so-called 'conservative' German part (CSU) and it is pretty much the
perfect formulation for "Don't listen to them. Don't argue about their
stuff, no matter if it makes any sense or not. They are EVIL and
that's all what really counts!".
http://www.crushkilldestroy.org/weblog/archives/alle_wege.jpg
------------------------------
Date: Mon, 25 Jul 2011 18:25:42 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: why won't perl say which value was uninitialized?
Message-Id: <slrnj2r686.s6h.hjp-usenet2@hrunkner.hjp.at>
On 2011-07-25 14:08, Tad McClellan <tadmc@seesig.invalid> wrote:
> jidanni@jidanni.org <jidanni@jidanni.org> wrote:
>> I don't see why messages like
>> Use of uninitialized value in print at bla.pl line 44
>> can't say which value was it that was uninitialized.
>> Is it really that much skin off perl's back?
>> Why must it hold its cards so close to its chest?
>> It knows exactly which of the say 50 variables had the problem,
>
>
> What if it was not a variable at all?
>
> print give_undef(), "\n";
> sub give_undef { return undef }
>
> What should it say in that case?
Use of uninitialized value in argument 1 of print.
(Or better "Use of value undef in ..." but that is unlikely to change)
hp
------------------------------
Date: Mon, 25 Jul 2011 18:25:57 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: why won't perl say which value was uninitialized?
Message-Id: <8739huff16.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2011-07-25 14:08, Tad McClellan <tadmc@seesig.invalid> wrote:
>> jidanni@jidanni.org <jidanni@jidanni.org> wrote:
>>> I don't see why messages like
>>> Use of uninitialized value in print at bla.pl line 44
>>> can't say which value was it that was uninitialized.
>>> Is it really that much skin off perl's back?
>>> Why must it hold its cards so close to its chest?
>>> It knows exactly which of the say 50 variables had the problem,
>>
>>
>> What if it was not a variable at all?
>>
>> print give_undef(), "\n";
>> sub give_undef { return undef }
>>
>> What should it say in that case?
>
> Use of uninitialized value in argument 1 of print.
Why should it say anything, given that there isn't even an lvalue
involved here? In C or C++ (and presumably, other, similar languages)
it is an error to use a variable with storage class auto to which no
value was assigned before use: The value of the variable is
indeterminate, what happens upon use of it is thus undefined behaviour
and the value is additionally (for usual implementations)
more-or-less random/ unpredictable (whatever happened to be stored in
a particular place on the stack or whatever value some register
had). It is actually one of the advantages of Perl that modifiable
objects start with a useful default value and that code which looks
like this:
if ($i > $#widths || length(content[$i]) > $widths[$i]) ...
can thus be simplified to
if (length($content[$i]) > $widths[$i]) ...
Why is this to be sacrificed on an altar dediciated to someone who did
a half-assed implementation of a warning for situation which is
perfectly legal because of a bad hangover and inbred intolerance
for differences, no matter if they happen to be beneficial or not?
NB: 'I can construct examples where this feature can be harmful' is no
argument in favor of that because such an example can be used for any
feature, meaning, the set of feature supposed to be taboo among the
natives was defined before the examples where constructed.
------------------------------
Date: Mon, 25 Jul 2011 12:29:48 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: why won't perl say which value was uninitialized?
Message-Id: <lnd3gyi2fn.fsf@nuthaus.mib.org>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2011-07-25 14:08, Tad McClellan <tadmc@seesig.invalid> wrote:
>>> jidanni@jidanni.org <jidanni@jidanni.org> wrote:
>>>> I don't see why messages like
>>>> Use of uninitialized value in print at bla.pl line 44
>>>> can't say which value was it that was uninitialized.
>>>> Is it really that much skin off perl's back?
>>>> Why must it hold its cards so close to its chest?
>>>> It knows exactly which of the say 50 variables had the problem,
>>>
>>>
>>> What if it was not a variable at all?
>>>
>>> print give_undef(), "\n";
>>> sub give_undef { return undef }
>>>
>>> What should it say in that case?
>>
>> Use of uninitialized value in argument 1 of print.
>
> Why should it say anything, given that there isn't even an lvalue
> involved here?
What does the presence or absence of an lvalue have to do with this?
> In C or C++ (and presumably, other, similar languages)
> it is an error to use a variable with storage class auto to which no
> value was assigned before use:
[...]
> It is actually one of the advantages of Perl that modifiable
> objects start with a useful default value
Agreed.
> and that code which looks
> like this:
>
> if ($i > $#widths || length(content[$i]) > $widths[$i]) ...
>
> can thus be simplified to
>
> if (length($content[$i]) > $widths[$i]) ...
True, but not a *direct* consequence of the fact that uninitialized
scalars are set to undef. It follows from the fact that the undef
value can be used without error in certain contexts.
> Why is this to be sacrificed on an altar dediciated to someone who did
> a half-assed implementation of a warning for situation which is
> perfectly legal because of a bad hangover and inbred intolerance
> for differences, no matter if they happen to be beneficial or not?
Perfectly legal? Then what should print do with an undef argument?
Perl permits undef values in some contexts, but not in others. The
choic of where undef is permitted and where it isn't (more precisely,
where triggers a warning) probably isn't 100% logical and consistent,
but that's life.
> NB: 'I can construct examples where this feature can be harmful' is no
> argument in favor of that because such an example can be used for any
> feature, meaning, the set of feature supposed to be taboo among the
> natives was defined before the examples where constructed.
If *I* pass an undef value to print, it's because I made a mistake,
and I'd like the implementation to warn me about it. Otherwise,
why are undef and the empty string distinct concepts?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Mon, 25 Jul 2011 22:13:35 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: why won't perl say which value was uninitialized?
Message-Id: <87vcuqcbcw.fsf@sapphire.mobileactivedefense.com>
Keith Thompson <kst-u@mib.org> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>> On 2011-07-25 14:08, Tad McClellan <tadmc@seesig.invalid> wrote:
>>>> jidanni@jidanni.org <jidanni@jidanni.org> wrote:
>>>>> I don't see why messages like
>>>>> Use of uninitialized value in print at bla.pl line 44
>>>>> can't say which value was it that was uninitialized.
>>>>> Is it really that much skin off perl's back?
>>>>> Why must it hold its cards so close to its chest?
>>>>> It knows exactly which of the say 50 variables had the problem,
>>>>
>>>>
>>>> What if it was not a variable at all?
>>>>
>>>> print give_undef(), "\n";
>>>> sub give_undef { return undef }
>>>>
>>>> What should it say in that case?
>>>
>>> Use of uninitialized value in argument 1 of print.
>>
>> Why should it say anything, given that there isn't even an lvalue
>> involved here?
>
> What does the presence or absence of an lvalue have to do with this?
Judgeing from the output ('uninitialized value' as opposed to 'undef
value') the intent of this less-than-delightful exercise in humbug
seems to have been to catch cases where something which can be
'initialized' aka 'assigned to' is used despite this wasn't
done. Consequently, this makes preciously little sense if no such
something was involved.
[...]
>> Why is this to be sacrificed on an altar dediciated to someone who did
>> a half-assed implementation of a warning for situation which is
>> perfectly legal because of a bad hangover and inbred intolerance
>> for differences, no matter if they happen to be beneficial or not?
>
> Perfectly legal? Then what should print do with an undef argument?
Well, what it is supposed to do: Print nothing aka 'an empty string'.
[rw@sapphire]/tmp $perl -e 'printf("|%s|%u|\n", undef, undef)'
||0|
> Perl permits undef values in some contexts, but not in others. The
> choic of where undef is permitted and where it isn't (more precisely,
> where triggers a warning) probably isn't 100% logical and consistent,
> but that's life.
"A program printed it. It must be sensible!". That's indeed a great
argument.
>> NB: 'I can construct examples where this feature can be harmful' is no
>> argument in favor of that because such an example can be used for any
>> feature, meaning, the set of feature supposed to be taboo among the
>> natives was defined before the examples where constructed.
>
> If *I* pass an undef value to print, it's because I made a mistake,
> and I'd like the implementation to warn me about it.
But, as you wrote above, you consider it to be a mistake because the
warning is printed.
> Otherwise, why are undef and the empty string distinct concepts?
[rw@sapphire]/tmp $perl -e 'printf("%u,%u\n", defined(undef), defined(""));'
0,1
Technically, this difference implies that a subroutine can return
something which evaluates to false (ie 0 or an empty string) and the
caller can distinguish this from 'it returned an error undicator' by
looking at the definedness of the returned value.
------------------------------
Date: Mon, 25 Jul 2011 14:50:45 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: why won't perl say which value was uninitialized?
Message-Id: <ln8vrmhvwq.fsf@nuthaus.mib.org>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>>> On 2011-07-25 14:08, Tad McClellan <tadmc@seesig.invalid> wrote:
>>>>> jidanni@jidanni.org <jidanni@jidanni.org> wrote:
>>>>>> I don't see why messages like
>>>>>> Use of uninitialized value in print at bla.pl line 44
>>>>>> can't say which value was it that was uninitialized.
>>>>>> Is it really that much skin off perl's back?
>>>>>> Why must it hold its cards so close to its chest?
>>>>>> It knows exactly which of the say 50 variables had the problem,
>>>>>
>>>>>
>>>>> What if it was not a variable at all?
>>>>>
>>>>> print give_undef(), "\n";
>>>>> sub give_undef { return undef }
>>>>>
>>>>> What should it say in that case?
>>>>
>>>> Use of uninitialized value in argument 1 of print.
>>>
>>> Why should it say anything, given that there isn't even an lvalue
>>> involved here?
>>
>> What does the presence or absence of an lvalue have to do with this?
>
> Judgeing from the output ('uninitialized value' as opposed to 'undef
> value') the intent of this less-than-delightful exercise in humbug
> seems to have been to catch cases where something which can be
> 'initialized' aka 'assigned to' is used despite this wasn't
> done. Consequently, this makes preciously little sense if no such
> something was involved.
Would you be satisified if the warning said "undefined value" rather
than "uninitialized value"? I agree that "uninitialized" is a bit
misleading; after all, it could be a variable that was explictly
initialized to undef:
my $x = undef;
print $x, "\n";
> [...]
>
>>> Why is this to be sacrificed on an altar dediciated to someone who did
>>> a half-assed implementation of a warning for situation which is
>>> perfectly legal because of a bad hangover and inbred intolerance
>>> for differences, no matter if they happen to be beneficial or not?
>>
>> Perfectly legal? Then what should print do with an undef argument?
>
> Well, what it is supposed to do: Print nothing aka 'an empty string'.
What is the basis for your assertion that ``print undef'' is *supposed*
to print an empty string?
> [rw@sapphire]/tmp $perl -e 'printf("|%s|%u|\n", undef, undef)'
> ||0|
perl -we 'printf("|%s|%u|\n", undef, undef)'
Use of uninitialized value in printf at -e line 1.
Use of uninitialized value in printf at -e line 1.
||0|
If you're going to use Perl's actual behavior as an argument for how it
*should* behave, then it follows that it *should* warn about passing
undef to print or printf.
>> Perl permits undef values in some contexts, but not in others. The
>> choic of where undef is permitted and where it isn't (more precisely,
>> where triggers a warning) probably isn't 100% logical and consistent,
>> but that's life.
>
> "A program printed it. It must be sensible!". That's indeed a great
> argument.
I have no idea how you derived that "argument" from what I actually
wrote.
>>> NB: 'I can construct examples where this feature can be harmful' is no
>>> argument in favor of that because such an example can be used for any
>>> feature, meaning, the set of feature supposed to be taboo among the
>>> natives was defined before the examples where constructed.
>>
>> If *I* pass an undef value to print, it's because I made a mistake,
>> and I'd like the implementation to warn me about it.
>
> But, as you wrote above, you consider it to be a mistake because the
> warning is printed.
No, I didn't say that.
There are two reasonably sensible things that ``print undef;''
could do. One is to quietly treat the argument as an empty string.
The other is to treat it as an error and warn about it (and
probably treat it as an empty string if warnings are suppressed).
I personally prefer the latter (which is lucky for me, because that's
how Perl happens to behave). If I want to print an empty string,
I print an empty string. If I try to print something whose value
is undef, it's *probably* because I made a mistake somewhere.
>> Otherwise, why are undef and the empty string distinct concepts?
>
> [rw@sapphire]/tmp $perl -e 'printf("%u,%u\n", defined(undef), defined(""));'
> 0,1
>
> Technically, this difference implies that a subroutine can return
> something which evaluates to false (ie 0 or an empty string) and the
> caller can distinguish this from 'it returned an error undicator' by
> looking at the definedness of the returned value.
I'm reasonably happy with the way Perl currently behaves in this
particular context. You obviously aren't. I don't think either
of us has an ironclad argument about how it *should* behave.
(But then, you can get the behavior you like with "no warnings;".)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
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 3454
***************************************
