[17213] in Perl-Users-Digest
Perl-Users Digest, Issue: 4635 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 16 21:10:35 2000
Date: Mon, 16 Oct 2000 18:10:20 -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: <971745019-v9-i4635@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 16 Oct 2000 Volume: 9 Number: 4635
Today's topics:
Re: question (Martien Verbruggen)
Re: question <joe+usenet@sunstarsys.com>
Re: question (Martien Verbruggen)
Re: question <mauldin@netstorm.net>
Re: question (Martien Verbruggen)
Re: question <joe+usenet@sunstarsys.com>
Re: question (Martien Verbruggen)
Re: question <joe+usenet@sunstarsys.com>
Re: question <anmcguire@ce.mediaone.net>
redirecting stderr in an open statement on WIN32 <chahn@peregrine.com>
Run perl script as service gaddamsr@my-deja.com
Re: Save As... Popup box exit72@excite.com
Re: Save As... Popup box (Jerome O'Neil)
Re: Save As... Popup box exit72@excite.com
Re: Save As... Popup box <tony_curtis32@yahoo.com>
Re: Save As... Popup box (Jerome O'Neil)
Re: Save As... Popup box (Martien Verbruggen)
Re: Sorting a list <lr@hpl.hp.com>
Re: split problem <godzilla@stomp.stomp.tokyo>
Re: Substracting one list from another <ren.maddox@tivoli.com>
Re: Substracting one list from another <nospam@luisr@juanadiaz.org>
Re: Substracting one list from another <nospam@luisr@juanadiaz.org>
Re: What is wrong with this subroutine? <g.soper@soundhouse.co.uk>
Re: Why '12 13 14' =~ /1./g match only 12 ? <ren.maddox@tivoli.com>
Re: Why '12 13 14' =~ /1./g match only 12 ? (Tony L. Svanstrom)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 16 Oct 2000 22:11:23 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: question
Message-Id: <slrn8umv84.a0g.mgjv@verbruggen.comdyn.com.au>
On 16 Oct 2000 14:23:00 -0400,
Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
> >
> > sub action ($) {
> > local($., *IN);
> > my $line = shift;
> > open IN, $file_b or die $!;
> > 1 while <IN>;
> > return $line;
> > }
>
> Well done! However, I think you've forgotten
> an essential piece of the original inplementation
> of action. In the original "action", each time
> it's called, the entirety of fileB is parsed.
> In Martien's solution, and yours as well, fileB
> is only read the first time that action is called.
> in particular, your code's
>
> 1 while <IN>;
>
> line will only be looped through on the first call
> of your "action". Subsequent calls will bypass this
> line, since you've already read the entire file in,
> but you didn't *close* it in your code.
>
> This certainly gets $. "right", but for the wrong
> reason. I'm still looking for a better solution,
> but I think we're finally getting somewhere on this
> thread.
I think you're mistaken :)
The file is closed. localisation of filehandles does two things: It
protects other parts of the program from having the handle clobbered,
and it also makes sure that the filehandle is closed on exit of the
block that the handle is scoped to. I can't exactly find the section
of the documentation that discusses this (if there is any) but it's
easy enough to prove:
sub action
{
local($., *IN);
open(IN, $fileB) or die $!;
print $. while (my $line = <IN>);
return $.;
}
action();
action();
This is very common idiom in subs where you want to exit early, but
don't want to be bothered having to explicitly close the file.
I think the main point that comes out of this, for me anyway, is that
any module or library that reads a file should localise $. and the
file handle they use. And if they don't use a lexically scoped
variable in the loop, they should also localise $_.
One other point that you've been arguing, and that I probably can
agree with, is that if you want to be _absolutely_ certain that your
$_ and $. don't get clobbered by a library, you need to use explicit
lexical variables instead.
However, if you ever find yourself in a situation where you're in a
loop (reading a file line by line) calling a sub that reads a file,
that you need to redesign your algorithm. Opening and/or closing files
in tight loops is something to be avoided. if a library contains a
method/sub that opens a reads a file each single time it gets called,
it probably needs redesign.
That does not stop a library doing initialisation like this:
package Foo;
my @config;
sub read_config
{
open(IN, $config_file) or die $!;
@config = <IN>;
close IN;
}
sub banana
{
read_config unless @config;
# do other interesting work here
}
package main;
open(BAR, $file) or die $!;
while(<BAR>)
{
# use $.
}
close BAR;
In this situation your $. will be clobbered only once, and code like
this is common enough to potentially break things (badly enough,
explicit initialisation would be much better, or initialisation at
load time). Other alternatives is checking time stamps on files and
rereading them when needed. This one might clobber your $. even more
erratically.
I still say that the main point is that a conscientious module
developer should localise $., especially if there is a chance that a
sub reading a file gets called from another. I concede that it is
unlikely that all modules do this correctly. But I stipulate that the
situation of a read within a read, _and_ the necessity of $. is rare
enough to not worry too much.
However, there is only one way to make absolutely certain that your
variable doesn't get clobbered, and that is by using a lexical.
Maybe it's not entirely clear yet why you can't just localise the $.
in the calling loop? local does not scopy lexically, but dynamically.
The local copy of $. is not limited to the block it is declared in,
but to any other block it calls. It's a runtime directive. The
localised copy of $. will be used until the block it is declared in
ends, _including_ in all the subs that are called from there.
#!/usr/local/bin/perl -wl
use strict;
use vars qw($var);
$var = 'foo';
{
local $var = 'bar';
sub print_var { print $var }
print_var;
}
{
local $var = 'baz';
print_var;
}
print_var;
__END__
bar
baz
foo
Lexically scoped variables work differently: They strictly obey block
scope.
#!/usr/local/bin/perl -wl
use strict;
use vars qw($var);
$var = 'foo';
{
my $var = 'bar';
sub print_var { print $var }
print_var;
}
{
local $var = 'baz';
print_var;
}
print_var;
__END__
bar
bar
bar
Martien
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | "Mr Kaplan. Paging Mr Kaplan..."
NSW, Australia |
------------------------------
Date: 16 Oct 2000 19:10:38 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: question
Message-Id: <m3k8b8pekx.fsf@mumonkan.sunstarsys.com>
mgjv@tradingpost.com.au (Martien Verbruggen) writes:
> I think you're mistaken :)
>
> The file is closed. localisation of filehandles does two things: It
> protects other parts of the program from having the handle clobbered,
> and it also makes sure that the filehandle is closed on exit of the
> block that the handle is scoped to. I can't exactly find the section
> of the documentation that discusses this (if there is any) but it's
> easy enough to prove:
>
> sub action
> {
> local($., *IN);
> open(IN, $fileB) or die $!;
> print $. while (my $line = <IN>);
> return $.;
> }
>
> action();
> action();
>
A stack trace on Andrew's solution reveals your analysis to be correct.
Here's the relevant piece:
------
read(4, "HI\nTHERE\n", 4096) = 9
write(1, "HI\n", 3HI
) = 3
write(1, "THERE\n", 6THERE
) = 6
read(4, "", 4096) = 0
close(4) = 0
munmap(0x40019000, 4096) = 0
write(1, "It reads: ALPHA\n", 16It reads: ALPHA
) = 16
write(1, "A is still at line 0\n", 21A is still at line 0
) = 21
write(1, "A is at line: 2\n", 16A is at line: 2
) = 16
open("file_b", O_RDONLY) = 4
-----
It's "}" (actually the gc :), not "open" that closes local filehandles.
Well, I'm pretty certain the "final solution" that Andrew posted is
write, but I can't seem to get it to work on my machine, so I'm
not confident in the results I'm getting (my perl version is 5.005_03).
Could anyone confirm that Andrew's code works, and with what perl version?
If you can get it working on your box, what happens if you change
Andrew's code and explicitly reintroduce the "close IN;" statement?
Does that clobber $., or leave it alone? It shouldn't make a difference,
but it's not clear from the documentation in "perldoc -f close" exactly
what will happen for local filehandles.
--
Joe Schaefer
------------------------------
Date: Mon, 16 Oct 2000 23:14:39 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: question
Message-Id: <slrn8un2uo.a0g.mgjv@verbruggen.comdyn.com.au>
On Mon, 16 Oct 2000 15:08:42 -0500,
Andrew N. McGuire <anmcguire@ce.mediaone.net> wrote:
> On 16 Oct 2000, Joe Schaefer quoth:
> JS> 1 while <IN>;
> JS>
> JS> is reevaluated each time action is called- my mistake!
> JS> ( I think "}" is closing the file for you.)
> JS> Your code still doesn't seem to work, though- if I use
> JS> this:
>
> Actually it is open() that closes the file file by implicitly calling
> close() for every open() after the first. ( Thats a mouthful ).
This prompted me to search for the bit of the documentation that
states that filehandles are implicitly closed when they go out of
scope. It's hard to find.
# man perldelta
[snip]
Implicitly closed filehandles are safer
Sometimes implicitly closed filehandles (as when they are
localized, and Perl automatically closes them on exiting
the scope) could inadvertently set $? or $!. This has
been corrected.
[snip]
It's implicit (sic) from this statement that an implicit close happens
on a localised file handle.
No documentation on this in perlfunc open() or close() or perlopentut.
However, it can be demonstrated:
#!/usr/local/bin/perl -wl
use strict;
sub foo
{
local(*FOO);
print FOO 'bar';
open(FOO, '>/tmp/fooble') or die $!;
print FOO 'bar';
}
foo;
foo;
__END__
Filehandle main::FOO never opened at /tmp/foo.pl line 7.
Filehandle main::FOO never opened at /tmp/foo.pl line 7.
Note that it warns on _both_ invocations of foo(), without any
explicit closes anywhere. It would have to, because even if there was
no implicit close, the local(*FOO) should create a local copy of FOO,
which should never be the same copy on subsequent invocations of
foo().
Martien
--
Martien Verbruggen |
Interactive Media Division | This matter is best disposed of from
Commercial Dynamics Pty. Ltd. | a great height, over water.
NSW, Australia |
------------------------------
Date: Mon, 16 Oct 2000 23:07:36 GMT
From: Jim Mauldin <mauldin@netstorm.net>
Subject: Re: question
Message-Id: <39EB89EA.4FC6B467@netstorm.net>
Joe Schaefer wrote:
>
> "Christian Gersch" <c.gersch@iglusoft.com> writes:
>
> > If ($. = 4) $text = $_;
>
> this should read
>
> if ($. == 4) { $text = $_; } #GOOD
>
> or you could do the whole loop in one line:
>
> $text = <FILE> while ($. <= 4); #BAD
>
> but using $. really isn't a good idea
> since it makes your code difficult to
> read (most perlies don't know what $.
> does- I had to look it up myself). Put
> your own line counter variable in, and
> name it as such, and break your code up
> so each line does one thing.
>
> Remember, code is for humans (especially
> you) to read, so keep simplicity and
> clarity higher values than cleverness and
> obscurity.
>
At the risk of incurring the ire of some people I respect a great deal
in this ng, and in light of the discussion subsequent to tbe above-cited
post, I have to agree with the general principles that Joe Schaefer is
promoting.
Perl's strength arises not from shortcuts that are useful, valid but
sometimes obscure (e.g. $.), but from
a) data types ($,@,%) and related functions that can be easily
generalized and that isolate the programmer from the tedious and
error-prone task of creating and manipulating low-level structures and
procedures, not the least of which is the direct manipulation of
pointers (I don't mean references - see below).
b) a powerful regex engine;
c) a comparatively simple and robust implementation of references that
has fuelled a vast expansion in the number of modules, which are now for
all intents and purposes part of the core language. This is where the
future of the Perl lies.
Beyond very short programs, a linear increase in the number of lines of
code results in a geometric increase in program complexity and the risk
of conflict and mistakes. Perl's evolution is toward more structure,
and the availability (still "optional") of self-imposed discipline to
"save us from ourselves."
In this light, expending effort to defend $. over $line_number is an
anachronism, and roughly analagous to the difficulty some people had
moving from assembler to 3GL.
IHMO,
-- Jim
------------------------------
Date: Mon, 16 Oct 2000 23:28:22 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: question
Message-Id: <slrn8un3of.a0g.mgjv@verbruggen.comdyn.com.au>
On 16 Oct 2000 19:10:38 -0400,
Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
>
> Well, I'm pretty certain the "final solution" that Andrew posted is
> write, but I can't seem to get it to work on my machine, so I'm
> not confident in the results I'm getting (my perl version is 5.005_03).
> Could anyone confirm that Andrew's code works, and with what perl version?
Andrew's code works with perl 5.6.0 on Linux. It does not, however,
work on perl5.00503 on Linux. Looks like 5.00503 has a bug that's
preventing it from doing this correctly. Maybe it's related to the
other bug that has been fixed in 5.6.0 related to implicitly closed
file handles (where $? or $! got set incorrectly). I can't find a
reference to it in the documentation.
Looks like a lot of the confusion comes from different versions of
Perl behaving differently :)
> If you can get it working on your box, what happens if you change
> Andrew's code and explicitly reintroduce the "close IN;" statement?
> Does that clobber $., or leave it alone? It shouldn't make a difference,
> but it's not clear from the documentation in "perldoc -f close" exactly
> what will happen for local filehandles.
Hmm. even with an explicit close it still misbehaves on 5.00503. But I
wouldn't be too sure that it shouldn't make a difference (see remark
about bugs in 5.00503). There must be another, unrelated, difference
in the way file closes happen on localised filehandles in 5.00503.
However, perldelta does not mention it.
The source distribution of perl 5.6.0 contains a bit more information:
# cat Changes
[snip]
[ 3494] By: jhi on 1999/05/28 16:44:34
Log: From: Paul Johnson <pjcj@transeda.com>
To: perl5-porters <perl5-porters@perl.org>
Subject: [PATCH 5.005_57] Fixes related to working local $.
Date: Fri, 28 May 1999 15:11:18 +0100
Message-ID: <19990528151118.A289@west-tip.transeda.com>
Branch: cfgperl
! ext/IO/lib/IO/Handle.pm pod/perlvar.pod t/lib/io_linenum.t
[snip]
While it doesn't say _what_ exactly got changed, it looks like this
may be what causes the difference. Since they're called 'fixes' it is
safe to assume that the 5.00503 behaviour is broken (which is also my
personal opinion)
Martien
--
Martien Verbruggen |
Interactive Media Division | 42.6% of statistics is made up on the
Commercial Dynamics Pty. Ltd. | spot.
NSW, Australia |
------------------------------
Date: 16 Oct 2000 19:44:35 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: question
Message-Id: <m3g0lwpd0c.fsf@mumonkan.sunstarsys.com>
Jim Mauldin <mauldin@netstorm.net> writes:
> > $text = <FILE> while ($. <= 4); #BAD
The most humourous aspect of the whole thing is that my
"detractors" didn't even bother to check that my original post
was error-free :)
Thanks for the vote; I wasn't sure if anyone would be brave
enough to say what you did.
--
Joe Schaefer
------------------------------
Date: Mon, 16 Oct 2000 23:58:35 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: question
Message-Id: <slrn8un5h4.a0g.mgjv@verbruggen.comdyn.com.au>
On 16 Oct 2000 19:44:35 -0400,
Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
> Jim Mauldin <mauldin@netstorm.net> writes:
>
> > > $text = <FILE> while ($. <= 4); #BAD
>
> The most humourous aspect of the whole thing is that my
> "detractors" didn't even bother to check that my original post
> was error-free :)
>
> Thanks for the vote; I wasn't sure if anyone would be brave
> enough to say what you did.
Hey, I've already said at least once that I agree, at least partly,
with the point you're making, or at least what I think the point
you're making is. :)
Martien
--
Martien Verbruggen |
Interactive Media Division | That's funny, that plane's dustin'
Commercial Dynamics Pty. Ltd. | crops where there ain't no crops.
NSW, Australia |
------------------------------
Date: 16 Oct 2000 20:03:19 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: question
Message-Id: <m3bswkpc54.fsf@mumonkan.sunstarsys.com>
mgjv@tradingpost.com.au (Martien Verbruggen) writes:
> Hey, I've already said at least once that I agree, at least partly,
> with the point you're making, or at least what I think the point
> you're making is. :)
Sorry about that, I guess it wasn't clear to me at the time which
"part" you we're agreeing with- but I get it now :)
Thanks.
--
Joe Schaefer
------------------------------
Date: Mon, 16 Oct 2000 19:57:23 -0500
From: "Andrew N. McGuire " <anmcguire@ce.mediaone.net>
Subject: Re: question
Message-Id: <Pine.LNX.4.21.0010161942200.25402-100000@hawk.ce.mediaone.net>
On Mon, 16 Oct 2000, Jim Mauldin quoth:
JM> Joe Schaefer wrote:
JM> >
JM> > "Christian Gersch" <c.gersch@iglusoft.com> writes:
JM> >
JM> > > If ($. = 4) $text = $_;
JM> >
JM> > this should read
JM> >
JM> > if ($. == 4) { $text = $_; } #GOOD
JM> >
JM> > or you could do the whole loop in one line:
JM> >
JM> > $text = <FILE> while ($. <= 4); #BAD
JM> >
JM> > but using $. really isn't a good idea
JM> > since it makes your code difficult to
JM> > read (most perlies don't know what $.
JM> > does- I had to look it up myself). Put
JM> > your own line counter variable in, and
JM> > name it as such, and break your code up
JM> > so each line does one thing.
JM> >
JM> > Remember, code is for humans (especially
JM> > you) to read, so keep simplicity and
JM> > clarity higher values than cleverness and
JM> > obscurity.
JM> >
JM>
JM> At the risk of incurring the ire of some people I respect a great deal
JM> in this ng, and in light of the discussion subsequent to tbe above-cited
JM> post, I have to agree with the general principles that Joe Schaefer is
JM> promoting.
JM>
JM> Perl's strength arises not from shortcuts that are useful, valid but
JM> sometimes obscure (e.g. $.), but from
I just cant agree that $. is obscure. That is like saying $?
is obscure. Both are well documented in perlvar and other places,
they behave as documented, so how can that be obscure? As I posted
before, the docs even say:
(Mnemonic: many programs use "." to mean the current line number.)
and I know I have run across $. often enough, I do not consider it
any more obscure than say: $/, $@ or $^W. I also disagree that useful
shortcuts are not a big part of Perls strength. Useful shortcuts
are what seperate Perl from Python (which I think is a fine language
for different reasons).
:-) My 2 cents.
anm
--
$ # = "%.6g" ; stat $0 or die $! ;
_ = q.Just another Perl Hacker. ;
print $ # ;
main'_ . v10 ;
------------------------------
Date: Mon, 16 Oct 2000 15:20:14 -0700
From: "Christopher Hahn" <chahn@peregrine.com>
Subject: redirecting stderr in an open statement on WIN32
Message-Id: <8sfuvc$ndn$1@dfw-ixnews3.ix.netcom.com>
Hello,
I am writing a script on Windows 2000, which might also need
to run on NT 4.0.
I am using a pipe to get the output of a system executable.
The program that I am running is writing to stderr as well as stdout.
(stupid, as the message is "Nothing to do" which is not much of an error)
I am wanting to use:
open("command 2>&1 |") or die "Could not open pipe:$!\n";
but this does not seem to working, as I get lines from the pipe, I write
them to a log. But the output sent to stderr still shows up at the console.
Any ideas appreciated, including pointers to any FAQs that I may
have missed in my search.
TIA,
Christopher
------------------------------
Date: Mon, 16 Oct 2000 23:13:16 GMT
From: gaddamsr@my-deja.com
Subject: Run perl script as service
Message-Id: <8sg226$bbo$1@nnrp1.deja.com>
Hi,
I am trying to run my perl script as a service on NT. I wrote a wrapper
from which i am trying to invoke the perl with parameters. My wrapper
works for notepad or calculator but not for perl.
is it posible to run the perl script as a service ?..
Any type of help or suggestion is appreciated.
Thanks in advance.
--sreeni
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 16 Oct 2000 23:01:20 GMT
From: exit72@excite.com
Subject: Re: Save As... Popup box
Message-Id: <i32nusk9jqpg737vlsaeo96dv9qu6uqci0@4ax.com>
I think if you don't know the answer or you're not willing to help you
should just refrain from posting.
To the original poster , if you want to pop up the save as dialog box
use
print "Location: http://www.yoursite.com/files/file/zip\n\n";
On Mon, 16 Oct 2000 15:49:39 -0500, Michael Carman <mjcarman@home.com>
wrote:
>Rob Donovan wrote:
>>
>> I have a perl script that picks a file from a dir and then I want it to
>> download it from the browser.
>>
>> I know who to send HTML to a browser (ie print content-type
>> text/plain..bla bla...), but how do I make the browser download a
>> file or pop up the 'save as...' box?
>
>Two points:
>1) Despite what you may think, this isn't really a Perl question. It's
> a CGI one, and there are forums specifically for CGI which will
> greet such inquiries more kindly. (i.e. Many of the folks here don't
> like seeing CGI questions in this forum and may flame you for
> posting them.)
>2) You don't. What the browser does with a particular content type
> is up to the browser (user), not you. They may choose to save it,
> display it, or launch some application to deal with the data.
>
>-mjc
------------------------------
Date: Mon, 16 Oct 2000 23:17:36 GMT
From: jerome@activeindexing.com (Jerome O'Neil)
Subject: Re: Save As... Popup box
Message-Id: <k0MG5.1226$pL5.257468@news.uswest.net>
exit72@excite.com elucidates:
> I think if you don't know the answer or you're not willing to help you
> should just refrain from posting.
>
> To the original poster , if you want to pop up the save as dialog box
> use
>
> print "Location: http://www.yoursite.com/files/file/zip\n\n";
Obviously, you don't know the answer, as this is so completely wrong
as to be laughable. Best to follow your own advice.
To the OP: There is no way to dictate what a particular client
does with a given content type. What happens for one user can't
be guaranteed to work for another.
>>2) You don't. What the browser does with a particular content type
>> is up to the browser (user), not you. They may choose to save it,
>> display it, or launch some application to deal with the data.
This is the right answer.
--
"Civilization rests on two things: the discovery that fermentation
produces alcohol, and the voluntary ability to inhibit defecation.
And I put it to you, where would this splendid civilization be without
both?" --Robertson Davies "The Rebel Angels"
------------------------------
Date: Mon, 16 Oct 2000 23:32:40 GMT
From: exit72@excite.com
Subject: Re: Save As... Popup box
Message-Id: <vl3nus47bo7k05sicl7hf45h6du872atpq@4ax.com>
works fine for me and everyone else I know , of course there is
another way to do it but I've tried this under redhat and windows and
it works just fine , why don't you run it and see what happens.
Of course if you have your browser configured to not pop the save as
it will not work but that is not the issue here.
Oct 2000 23:17:36 GMT, jerome@activeindexing.com (Jerome O'Neil)
wrote:
>exit72@excite.com elucidates:
>> I think if you don't know the answer or you're not willing to help you
>> should just refrain from posting.
>>
>> To the original poster , if you want to pop up the save as dialog box
>> use
>>
>> print "Location: http://www.yoursite.com/files/file/zip\n\n";
>
>Obviously, you don't know the answer, as this is so completely wrong
>as to be laughable. Best to follow your own advice.
>
>To the OP: There is no way to dictate what a particular client
>does with a given content type. What happens for one user can't
>be guaranteed to work for another.
>
>>>2) You don't. What the browser does with a particular content type
>>> is up to the browser (user), not you. They may choose to save it,
>>> display it, or launch some application to deal with the data.
>
>This is the right answer.
------------------------------
Date: 16 Oct 2000 18:38:50 -0500
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: Save As... Popup box
Message-Id: <87r95gbblh.fsf@limey.hpcc.uh.edu>
>> On Mon, 16 Oct 2000 23:32:40 GMT,
>> exit72@excite.com said:
> works fine for me and everyone else I know , of course
> there is another way to do it but I've tried this under
> redhat and windows and it works just fine , why don't
> you run it and see what happens. Of course if you have
> your browser configured to not pop the save as it will
> not work but that is not the issue here.
From the original post:
"how do I make the browser..."
And that *is* the issue. You're wrong, you cannot force a
browser to do something from the server-side. The fact
that it appears to do what you want in *your* particular
configuration is not relevant. We all make mistakes here,
but you have learn and move on.
hth
t
--
Eih bennek, eih blavek.
------------------------------
Date: Mon, 16 Oct 2000 23:44:01 GMT
From: jerome@activeindexing.com (Jerome O'Neil)
Subject: Re: Save As... Popup box
Message-Id: <5pMG5.1234$pL5.269518@news.uswest.net>
exit72@excite.com elucidates:
> works fine for me and everyone else I know , of course there is
> another way to do it but I've tried this under redhat and windows and
> it works just fine , why don't you run it and see what happens.
> Of course if you have your browser configured to not pop the save as
> it will not work but that is not the issue here.
That is precicely and exactly the issue here. You have no controll
over what the user agent does with content. There isn't another
way to do it, as there isn't *any* way to do it.
Thats the whole point.
--
"Civilization rests on two things: the discovery that fermentation
produces alcohol, and the voluntary ability to inhibit defecation.
And I put it to you, where would this splendid civilization be without
both?" --Robertson Davies "The Rebel Angels"
------------------------------
Date: Mon, 16 Oct 2000 23:56:27 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Save As... Popup box
Message-Id: <slrn8un5d5.a0g.mgjv@verbruggen.comdyn.com.au>
[Please, in the future, post your reply AFTER the suitably trimmed
test you reply to]
On Mon, 16 Oct 2000 23:01:20 GMT,
exit72@excite.com <exit72@excite.com> wrote:
[fixed order of post]
> On Mon, 16 Oct 2000 15:49:39 -0500, Michael Carman <mjcarman@home.com>
> wrote:
>
> >Rob Donovan wrote:
> >>
> >> I know who to send HTML to a browser (ie print content-type
> >> text/plain..bla bla...), but how do I make the browser download a
> >> file or pop up the 'save as...' box?
> >
> >Two points:
> >1) Despite what you may think, this isn't really a Perl question. It's
> > a CGI one, and there are forums specifically for CGI which will
>
> I think if you don't know the answer or you're not willing to help you
> should just refrain from posting.
No. Michael is correct. This is NOT a question to be answered here.
There are two (main) reasons for this:
1) The experts on HTML, CGI and the relevant tricks and techniques are
unlikely to be here. They hang out in a different space on Usenet, in
the comp.infosystems.* hierarchy. Any answers from here might be
inaccurate, and the chances of it being corrected by the people in the
know are low.
2) Usenet is divided in spaces that each have a fairly limited topic
to discuss. The reason for that is that it is easier to find the bits
you're interested in, without having to wade through mountains of
irrelevant crap. The more irrelevant crap ends up on a newsgroup, the
less useable it becomes. The less useable a newsgroup is, the fewer
decent people with knowledge and willingness to answer topical
questions will read it. I am not making this up. This is a
historically proven fact.
So, you have just added to the clutter on this group. You, personally,
have made this group less useable. You might find yourself in the
situation, some day, where you need a good answer to something that is
really related to Perl, and you might find that there is no one left
on this group that knows anything about Perl. You will only find
people posting upside down, and discussing HTML and CGI. Is that
really what you want? Alternatively, you may find that there still are
people who discuss Perl, but they can't see any of your posts, because
they've all killfiled you.
So, bite your tongue, and only post Perl-related answers and questions
here. If you want to talk about HTML, go to one of the
comp.infosystems.www.* groups. If you feel you need to answer HTML or
CGI related questions that are posted to this group, do so in private
email, and maybe inform the OP that they shouldn't post here again,
unless it really is Perl they want to talk about.
But, do NOT answer off-topic questions here. And even more
importantly, do NOT flame people for correctly pointing out that HTML
and CGI are not discussed here.
Before using Usenet, you should understand the rules. Go to
news.announce.newusers, and read some of the documentation posted
there regularly.
Martien
--
Martien Verbruggen |
Interactive Media Division | In a world without fences, who needs
Commercial Dynamics Pty. Ltd. | Gates?
NSW, Australia |
------------------------------
Date: Mon, 16 Oct 2000 17:45:02 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Sorting a list
Message-Id: <MPG.145540ec2ff07c8c98ae38@nntp.hpl.hp.com>
In article <m1g0lw1muw.fsf@halfdome.holdit.com> on 16 Oct 2000 14:45:43
-0700, Randal L. Schwartz <merlyn@stonehenge.com> says...
> >>>>> "Uri" == Uri Guttman <uri@sysarch.com> writes:
>
> >>>>> "RLS" == Randal L Schwartz <merlyn@stonehenge.com> writes:
> RLS> That's gonna be annoyingly slow for all but the tiniest of lists.
> RLS> You should look into a Schwartzian Transform (named after me, but
> RLS> not *by* me) or the GSR sort (named by the authors after
> RLS> themselves :-).
We published it as the 'packed-default sort', which we knew was lame.
So we asked this newsgroup for help in naming it.
> Uri> if you are going to slander us, at least get the acronym correct! it is
> Uri> the GRT.
>
> Uri> :)
>
> Uri> and we were looking for a name in public and someone else (i think the
> Uri> departed abigail) coined the one that was accepted.
Yes, it was Abigail, and the name was accepted here by acclamation,
because it is GReaT, like the sorting method. :-)
> Ooops, no offense intended, on either count. Was mistaken on the
> first, misinformed on the second. Must be monday. :) :)
So OK.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Mon, 16 Oct 2000 15:39:22 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: split problem
Message-Id: <39EB839A.1DDC589@stomp.stomp.tokyo>
Michael Carman wrote:
> Godzilla! wrote:
> > Neo James Crum wrote:
> > > ...I have a line like follows:
> > > 234,tree,"Smith, John",6834
> > > ...how to get split to ignore the comma inside the
> > > quotation marks.
> > Do not respond with changed parameters and,
> > "This does not work."
> Bah. Is that how you're attempting to justify your coding now?
Why would I need to justify code which performs
with absolute perfection? Are you confused? Any
person can test my code, as I have, and quickly
ascertain it performs flawlessly.
> By that line of reasoning I could submit that this is
> a perfectly acceptable solution:
> my $line = '234,tree,"Smith, John",6834';
> my @split_line = (
> 234,
> 'tree',
> 'Smith, John',
> 6834,
> );
This is a reasonable solution?
* laughs *
> [snip of poor solution]
> You're making two large assumptions about the formatting of the input
> data: that quoted commas are always followed by a space and that the
> source data does not already contain the © character.
I have made no assumptions and have dealt with parameters
precisely as stated. You are a functional illiterate,
and are quite clearly incapable, to a measured degree,
of reading simple sentences without becoming confused
about what you read, or tried to read.
> Furthermore, the quotes are not part of the data, they're
> part of the formatting. A proper split should remove
> them as such.
This is not stated in the parameters. Have you
tried using an index finger, either right or
left index finger, to assist your reading? Slowly
underscore each word with an index finger. This is
often helpful for a functional illiterate such as
yourself, especially if you vocalize each word
slowly and give each word some thought.
> Neo, as others have suggested, use one of the modules
> designed for this task and ignore the raving reptile.
Ahhh.. another stereotypical functional illiterate
Perl 5 Cargo Cultist! I understand your significant
ignorance and these challenges you face in education.
However, ignorance, a lack of a good education, both
are your own fault, yes?
Godzilla!
--
Dr. Kiralynne Schilitubi ¦ Cooling Fan Specialist
UofD: University of Duh! ¦ ENIAC Hard Wiring Pro
BumScrew, South of Egypt ¦ HTML Programming Class
------------------------------
Date: 16 Oct 2000 16:36:54 -0500
From: Ren Maddox <ren.maddox@tivoli.com>
Subject: Re: Substracting one list from another
Message-Id: <m37l78tqmh.fsf@dhcp11-177.support.tivoli.com>
"Luis E. Rodriguez" <nospam@luisr@juanadiaz.org> writes:
> Hi there! I am looking for a way to substract one list from another in
> PERL. I searched this newsgroup, the PERL FAQs and did not find anything
> that could answer my question.
perldoc -q difference
has the answer, but it has lots of other hits as well.
perldoc -q intersection
takes you to the same answer, but with (currently) no other hits.
The basic answer is "use a hash". Also, the code given in that answer
does not do exactly what you want, but it shouldn't be too difficult
to adapt.
--
Ren Maddox
ren@tivoli.com
------------------------------
Date: Mon, 16 Oct 2000 21:01:23 -0300
From: "Luis E. Rodriguez" <nospam@luisr@juanadiaz.org>
Subject: Re: Substracting one list from another
Message-Id: <zzNG5.23882$Kx.1755946@e420r-sjo1.usenetserver.com>
"Ren Maddox" <ren.maddox@tivoli.com> wrote in message
news:m37l78tqmh.fsf@dhcp11-177.support.tivoli.com...
> perldoc -q intersection
>
> takes you to the same answer, but with (currently) no other hits.
>
> The basic answer is "use a hash". Also, the code given in that answer
> does not do exactly what you want, but it shouldn't be too difficult
> to adapt.
Thanks for your reply. I will check that.
After I posted my question I remembered that in the process of parsing the
results, there is a loop that goes through the entire list so it was easier
than I though. A single line of extra code in the loop will do the job.
But I will check anyway because I am sure this will come handy in the
future.
------------------------------
Date: Mon, 16 Oct 2000 21:04:34 -0300
From: "Luis E. Rodriguez" <nospam@luisr@juanadiaz.org>
Subject: Re: Substracting one list from another
Message-Id: <DCNG5.23883$Kx.1757819@e420r-sjo1.usenetserver.com>
"Darryl Friesen" <Darryl.Friesen@usask.ca> wrote in message
news:8sftmt$l6j$1@tribune.usask.ca...
> Look in the FAQ for union and intersection of lists/hashes. I'm almost
> positive there's examples of this.
>
Thanks for your reply. I will check that.
After I posted my question I remembered that in the process of parsing the
results, there is a loop that goes through the entire list so it was easier
than I though. A single line of extra code in the loop will do the job.
But I will check anyway because I am sure this will come handy in the
future.
------------------------------
Date: Mon, 16 Oct 2000 22:17:52 +0100
From: Geoff Soper <g.soper@soundhouse.co.uk>
Subject: Re: What is wrong with this subroutine?
Message-Id: <4a0e915c43g.soper@soundhouse.co.uk>
In article <lnpul03bbj.fsf@myxa.com>,
Walt Mankowski <walt@myxa.com> wrote:
> Geoff Soper <g.soper@soundhouse.co.uk> writes:
> > It's the split_csv subroutine which is causing the problem.
> Then you should read the discussion on parsing CSV files in perlfaq4.
I don't think it's the CSV routine which is the problem as I've been using
that in the same script for ages without a problem. It's from a book and I
get the impression they're not too good so it's on my list of things to
change.
I think the problem is something more fundamental.
Thanks
--
Geoff Soper
g.soper@soundhouse.co.uk
Take a look at the Soundhouse page http://www.soundhouse.co.uk/
------------------------------
Date: 16 Oct 2000 15:53:39 -0500
From: Ren Maddox <ren.maddox@tivoli.com>
Subject: Re: Why '12 13 14' =~ /1./g match only 12 ?
Message-Id: <m3n1g4v770.fsf@dhcp11-177.support.tivoli.com>
tony@svanstrom.com (Tony L. Svanstrom) writes:
> Just a quick solution, if you're looking for one:
>
> $_ = "12 13 14";
>
> s/(1.)/push(@a,$1)/eg;
Which is about half as fast as the more direct:
@a = /(1.)/g;
Plus, the substitute has the rather strange (though expected)
side-effect of changing the original string to "1 2 3".
--
Ren Maddox
ren@tivoli.com
------------------------------
Date: Tue, 17 Oct 2000 00:11:06 GMT
From: tony@svanstrom.com (Tony L. Svanstrom)
Subject: Re: Why '12 13 14' =~ /1./g match only 12 ?
Message-Id: <1eimjds.47974x1g7pckqN%tony@svanstrom.com>
Ren Maddox <ren.maddox@tivoli.com> wrote:
> tony@svanstrom.com (Tony L. Svanstrom) writes:
>
> > Just a quick solution, if you're looking for one:
> >
> > $_ = "12 13 14";
> >
> > s/(1.)/push(@a,$1)/eg;
>
> Which is about half as fast as the more direct:
>
> @a = /(1.)/g;
>
> Plus, the substitute has the rather strange (though expected)
> side-effect of changing the original string to "1 2 3".
D'oh.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
\O/ \O/ ©99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 4635
**************************************
