calling a perl script on windows

[Mahdi A Sbeih]

Hi all,

I am working on porting some scripts from unix to windows, and I noticed 
that perl ignores the first line of the script, and it seems I have to 
run the script like this:

D:\Perl\bin\perl.exe myscript.pl

if I run it like we do on unix:
./myscript.pl

it will search the path and it uses the perl found in the path env variable.


How can I make it to run exactly like Unix, meaning, just use the first 
line in the script?


Thanks,
Mahdi.





--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: pattern match

[Mumia W.]

Ryan Dillinger wrote:
> [...]
> #!/usr/bin/perl
> use warnings;
> use strict;
> 
> open LYNX, "lynx -source http://www.perl.com/ |" or die "Can't open lynx: 
> $!";
> $_ = "";
> $_ =  until /standard\.def/;
> 

If 'standard.def' is not found, this line loops forever.

> my $head = ;
> $head =~ m|^]+>(.*?)|i;
> 

HERF != HREF


> print "Today's www.perl.com headline: $!\n";
> 

$! does not equal $1

>   Thanks Again!
> 
> 
> 

You're welcome.


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: pattern match

[Mr. Shawn H. Corey]

Ryan Dillinger wrote:
> Hello,
> I had two scripts that were identical, well almost. I ran the two
> together, but
> straghtened them out. Anyway I have one here, that when ran say's: Use
> of uninitialized
> value in pattern match (m//) at headline.pl line 7 and 10. I have
> changed differernt things
> within, nothing worked. It is back to it's original state now. Can
> someone point out
> the problem I have with this script please? Thanks For your help!
> 
> #!/usr/bin/perl
> use warnings;
> use strict;
> 
> open LYNX, "lynx -source http://www.perl.com/ |" or die "Can't open
> lynx: $!";
> $_ = "";
> $_ =  until /standard\.def/;
> 
> my $head = ;
> $head =~ m|^]+>(.*?)|i;

HERF? How about HREF?

You would be better off downloading an HTML parser from CPAN like
HTML::TreeBuilder See 


> 
> print "Today's www.perl.com headline: $!\n";
> 
>  Thanks Again!
> 
> 
> 


-- 
__END__

Just my 0.0002 million dollars worth,
   --- Shawn

"For the things we have to learn before we can do them, we learn by
doing them."
  Aristotle

* Perl tutorials at http://perlmonks.org/?node=Tutorials
* A searchable perldoc is at http://perldoc.perl.org/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: pattern match

[Mr. Shawn H. Corey]

Ryan Dillinger wrote:
> Hello,
> I had two scripts that were identical, well almost. I ran the two
> together, but
> straghtened them out. Anyway I have one here, that when ran say's: Use
> of uninitialized
> value in pattern match (m//) at headline.pl line 7 and 10. I have
> changed differernt things
> within, nothing worked. It is back to it's original state now. Can
> someone point out
> the problem I have with this script please? Thanks For your help!
> 
> #!/usr/bin/perl
> use warnings;
> use strict;
> 
> open LYNX, "lynx -source http://www.perl.com/ |" or die "Can't open
> lynx: $!";
> $_ = "";
> $_ =  until /standard\.def/;

Are you absolutely, positively certain that 'standard.def' is in the
file? Try:

print "Found standard.def: $_";

> 
> my $head = ;
> $head =~ m|^]+>(.*?)|i;
> 
> print "Today's www.perl.com headline: $!\n";
> 
>  Thanks Again!
> 
> 
> 


-- 
__END__

Just my 0.0002 million dollars worth,
   --- Shawn

"For the things we have to learn before we can do them, we learn by
doing them."
  Aristotle

* Perl tutorials at http://perlmonks.org/?node=Tutorials
* A searchable perldoc is at http://perldoc.perl.org/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: pattern match

[Timothy Johnson]

At the moment I can't think of why this makes a difference (somebody
help me here), but you aren't specifying a mode for the open() function.
Also, you're not checking whether your match succeeded before using $1
(which is what I think you meant on that last line).

I personally would write it a little more like this for clarity:



#!/usr/bin/perl
use warnings;
use strict;

open(LYNX,"<","lynx -source http://www.perl.com/ |") or die("Can't open
lynx: $!");

until($_ =~ /standard\.def/){
   $_ = ;
}
my $head = ;

if($head =~ m|^]+>(.*?)|i){
   print "Today's www.perl.com headline: $1\n";
}else{
   print "ERROR: Unable to get today's perl.com headline: $!\n";
}



I can't test the rest of it, though, because I don't actually have lynx
on my system.





-Original Message-
From: Ryan Dillinger [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 11, 2006 6:28 PM
To: beginners@perl.org
Subject: pattern match



Use of uninitialized value in pattern match (m//) at headline.pl line 7
and 10. 



#!/usr/bin/perl
use warnings;
use strict;

open LYNX, "lynx -source http://www.perl.com/ |" or die "Can't open
lynx: 
$!";
$_ = "";
$_ =  until /standard\.def/;

my $head = ;
$head =~ m|^]+>(.*?)|i;

print "Today's www.perl.com headline: $!\n";



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

pattern match

[Ryan Dillinger]

Hello,
I had two scripts that were identical, well almost. I ran the two together, 
but
straghtened them out. Anyway I have one here, that when ran say's: Use of 
uninitialized
value in pattern match (m//) at headline.pl line 7 and 10. I have changed 
differernt things
within, nothing worked. It is back to it's original state now. Can someone 
point out

the problem I have with this script please? Thanks For your help!

#!/usr/bin/perl
use warnings;
use strict;

open LYNX, "lynx -source http://www.perl.com/ |" or die "Can't open lynx: 
$!";

$_ = "";
$_ =  until /standard\.def/;

my $head = ;
$head =~ m|^]+>(.*?)|i;

print "Today's www.perl.com headline: $!\n";

 Thanks Again!



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Still getting errors

[John W. Krahn]

Ryan Dillinger wrote:
> Hello again,

I assume that you are replying to my post but it is hard to tell because you
have started a new thread with a new Subject line.


>  I have rewrote this script I hoped the way you told me.

I assume that "you" is me.  The comments I made were (mostly) supposed to
*replace* the code it followed.


> And now I have just one error that states: Use of uninitialized value in
> hash element at
> names.pl line 24, <> line 1.
> Forgive me, but I'm not sure what's going on here.
> 
> 
> 
> #!/usr/bin/perl
> 
> use warnings;
> use strict;

my %names;

> while (<>) {
>   @raw = split;
>   $names{ $raw[ -1 ] } = "@raw[ 0 .. $raw -1 ]";
> }
> 
> while () {
> print "\n1. Sort names by last name\n";
> print "2. Sort names by first name\n";
> print "3. Search for a name\n";
> print "4. Quit\n\n";
> print "Choose a number: ";

  chomp( my $in =  );


> if ($in eq '1') {

  foreach my $name ( sort $keys %names ) {

> print "$name, $names{$name}\n";
>   }
> } elsif ($in eq '2') {

  my @keys = sort { $names{$a} cmp $names{$b} } keys %names;
  foreach my $name ( @keys ) {


>  print "$names{name} $name\n";
>   }
> } elsif ($in eq '3') {
>   print "Search for what? ";

chomp( my $search =  );

my @keys;
while ( my @n = each %names ) {


>   if (grep /$search/, @n) {
> push @keys, $n[ 0 ];
>}
>  }
>  if (@keys) {
> print "Names matched: \n";

  foreach my $name ( sort @keys ) {


>   print " $names{$name} $name\n";
>   }
> } else {
>   print "None found.\n";
> }
> } elsif ($in eq '4') {
>   last;
> } else {
>   print "Not a good answer. 1 to 4 please.\n";
> }
> }
> 
> Sorry I just can;t figure it out.Thank You

Try it like that.



John
-- 
use Perl;
program
fulfillment

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: write out filenames of files existing on a filesystem into afile

[Rob Dixon]

Randal

I'm in two minds as to whether to just let this go as it had gone on for too
long, but I will try just once more to explain my true stance, which you seem
keen to obfuscate.

(Randal L. Schwartz) wrote:
>
>>"Rob" == Rob Dixon <[EMAIL PROTECTED]> writes:
>
> Rob> Not much chance of that I'm afraid Shawn. I can do without the apology, I
> Rob> just wish he'd confirm that his original critique was wrong instead of
> Rob> banging on about filenames with three dots. I think leaving people with
> Rob> that misinformation uncorrected is a lot more important.
>
> My original critique was wrong.  I mistook /^[.]/ for /[^.]/.
> So your post was wrong, but I said it was wrong for the wrong reasons.

You also claimed the rest of my post was incorrect, wouldn't work and hadn't
been tested. You were wrong on all counts, and clearly didn't choose to test the
code yourself.

> That still doesn't solve the problems I addressed about your post elsewhere,
> nor that you had to go three rounds with me in private email repeatedly
> looking for some way to "save" your original post from being labeled wrong.

The quotes are yours: I was indeed trying to save it from the allegations of
your incorrect response. My original post was not wrong as you described it, but
only insofar as it discarded three-dot files. In context even that can only be
considered a problem with portability as the OP used a Windows system where such
files cannot exist. And I didn't 'go three rounds' with you - I didn't consider
it a fight and am surprised if you did.

> I'm here for the group.  I want people to walk away from this list knowing how
> to code *better* Perl.  Your post distracted from that.  I have nothing
> against you personally, but your behaviors distract from my goal, and will be
> called for what they are.

Randal, there are ways to correct people without being abusive and creating this
monstrous storm of debate. Had your initial response been to correct just the
incorrect filename filtering I doubt you would have seen an opportunity to be so
vehement, and I think it is clear that defamatory posts also serve to distract
from teaching people better Perl. Please try to be civil with your criticism and
make this list a better place to learn and to impart what we know.

Rob

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: efficiently keeping a short list

[Dr.Ruud]

Tom Allison schreef:

> I want to keep a short list of the most recently used 'X'.
> < 200 elements.
>
> Is there any suggestions other than to
> unshift @recent, $element;
> $#recent = $maximum;
>
> I know this will create a lot of array movement, but I can't think of
> anything better off the top of my head.  You?

See also Tie::Cacher, and several other modules on CPAN.

-- 
Affijn, Ruud

"Gewoon is een tijger."



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: efficiently keeping a short list

[Jay Savage]

Yet another victim of the dreaded reply-to

On 7/11/06, Jay Savage <[EMAIL PROTECTED]> wrote:

On 7/11/06, Mr. Shawn H. Corey <[EMAIL PROTECTED]> wrote:
> Jay Savage wrote:

>
> No thank you, you have change the script from using seconds to fraction
> of seconds. If you had done this the first time around, my comments
> would be different (see below).
>

I did say that the first time around, or at least I tried to, but see
my follow-up.


>
> $id is no more likely to overflow than Time::HiRes::time. Perl is not C.
> In Perl, if an integer overflows, it is automatically convert to a
> float; no muss, no fuss. The problem you would have with both is
> dropping of insignificant digits. Consider the following:
>

[snip]

> Note the output is zero. This is because 1 is too insignificant to
> effect a number as big as 1e138. There is a whole field of mathematics
> called Numerical Analysis devoted to dealing with such problems.
>

There are also Math::BigInt and Math::BigFloat. But I think thee are
some other drawbacks to autoincrement. keeping order when an item
repeats becomes complicated, requiring linked lists, etc.

> But you are talking really big numbers here; you are more likely to
> experience memory overflow than this.
>

Probably so. Although overflowing anything with a list you expect to
hover in the neighborhood of 200 items is highly unlikely.

> >
> > Of course since OP didn't give any implementation details, it's
> > possible that the list could grow even larger between calls to
> > get_list(). Maybe the user will only want the list of 200 recent items
> > after an average of 1,000,000 elements are added. Then, sure, you'll
> > want to take a different approach. If that's the case, I'd recommend
> > getting a copy of _Mastering Algorithms With Perl_, and reading up on
> > linked lists and b-trees.
> >
>
> The solution I proposed was a double-linked list with a hash to every
> element. The hash is used to remove elements from the middle of the list.

I see that now, although at the time I only saw Charles' reply, which
was what I was responding to. Your porposal is an elegant solution.

> B-trees are only effective when used on disk. Compared to other
> algorithms you can use, b-trees are slow when used in RAM only. Even
> binary b-trees are slower than other algorithms you can use to balance a
> binary tree.
>

That call will be based on the data and the specififc implementation,
but if running out of RAM is a concern, writing to disk will be the
solution. I just suggested that if managing an ordered data set large
enough to be of concern was the issue here, that we were getting a bit
beyond the scope of this list, and that Orwant, et.al. was the logical
next step.

>
> > In my experience, though, it's standard to size the list slightly
> > larger than the number elements you expect to add between accesses.
> > For most UI situations, the working definition of "recent items" is
> > "the most items we think a normal user will access between views of
> > 'recent items.'" The value of a recent items list decreases rapidly
> > when users use more items in a session than the list can hold, and
> > demonstrably recent items get shifted off the bottom.
> >
>
> In Perl, you don't have to pre-allocate memory; again you are thinking
> too C-ish.
>

I don't know where I mentioned allocating memory. My comments weren't
about memory allocation, they were about UI design. I was talking
about the size of the "recent items list" presented to the user. I
think that the concern about RAM is an extreme corner case. If OP is
sizing his list at 200, it's presumably because he expects that to be
a reasonable number for normal use. Items shouldn't fall off the list
while they're still fairly 'recent'. If the 200 slots are filling up
and the list is being pruned frequently enough to cause performace
degradation--or the the list is growing large ienough to cause
degradation before being pruned--OP probably needs to rethink things
because things that can be reasonable thought of as "recent" won't
appear on the list. Let me phrase that more succinctly: if system
resources become an issue for any sort of "recently used" list,
something is almost certainly horribly wrong with the spec.

> I think that keeping a recent-items list of 200 to be silly. A normal
> user will not look beyond the first five (but will complaint unless the
> list holds at least ten items).
>

Exactly.

But to get this back to Perl, let me offer this optimization to my
original suggestion:

   sub get_list {
   my @sorted = sort {$recent{$b} <=> $recent{$a}} keys %recent;
   while (@sorted > $limit) {
   delete $recent{pop @sorted};
   }
   return @sorted;
   }



-- jay
--
This email and attachment(s): [  ] blogable; [ x ] ask first; [  ]
private and confidential

daggerquill [at] gmail [dot] com
http://www.tuaw.com  http://www.dpguru.com  http://www.engatiki.org

values of β wil

Re: efficiently keeping a short list

[Mr. Shawn H. Corey]

Jay Savage wrote:
> Not sure what kind of hardware you have, but it takes considerably
> less than a second for me. Not counting the sleep(), of course, which
> was just to guarantee unique timestamps for the example. Assuming the
> data being used for the keys (the "elements") is of a reasonable size
> (for most values of "a reasonable size") my example should easily
> handle 10's of thousands of "elements" (without the sleep. ;) ).
> 
> Don't believe me? Try this:

No thank you, you have change the script from using seconds to fraction
of seconds. If you had done this the first time around, my comments
would be different (see below).

8< snip

> Yes the problem here is that you're pretty much guaranteed to overflow
> $id at some point, given a sufficienly long-running process, even
> discounting the size of the hash. That's why I went for time() or
> Time::HiRes::time() instead of an autoincrement; no muss, no fuss.
> Unless you're still running your script on the same hardware in 2038.
> 

$id is no more likely to overflow than Time::HiRes::time. Perl is not C.
In Perl, if an integer overflows, it is automatically convert to a
float; no muss, no fuss. The problem you would have with both is
dropping of insignificant digits. Consider the following:

#!/usr/bin/perl

use strict;
use warnings;

my $n = 1e138;
my $m = $n + 1;
my $diff = $m - $n;

print "diff = $diff\n";

__END__

Note the output is zero. This is because 1 is too insignificant to
effect a number as big as 1e138. There is a whole field of mathematics
called Numerical Analysis devoted to dealing with such problems.

But you are talking really big numbers here; you are more likely to
experience memory overflow than this.

> 
> Of course since OP didn't give any implementation details, it's
> possible that the list could grow even larger between calls to
> get_list(). Maybe the user will only want the list of 200 recent items
> after an average of 1,000,000 elements are added. Then, sure, you'll
> want to take a different approach. If that's the case, I'd recommend
> getting a copy of _Mastering Algorithms With Perl_, and reading up on
> linked lists and b-trees.
> 

The solution I proposed was a double-linked list with a hash to every
element. The hash is used to remove elements from the middle of the list.

B-trees are only effective when used on disk. Compared to other
algorithms you can use, b-trees are slow when used in RAM only. Even
binary b-trees are slower than other algorithms you can use to balance a
binary tree.


> In my experience, though, it's standard to size the list slightly
> larger than the number elements you expect to add between accesses.
> For most UI situations, the working definition of "recent items" is
> "the most items we think a normal user will access between views of
> 'recent items.'" The value of a recent items list decreases rapidly
> when users use more items in a session than the list can hold, and
> demonstrably recent items get shifted off the bottom.
> 

In Perl, you don't have to pre-allocate memory; again you are thinking
too C-ish.

I think that keeping a recent-items list of 200 to be silly. A normal
user will not look beyond the first five (but will complaint unless the
list holds at least ten items).


-- 
__END__

Just my 0.0002 million dollars worth,
   --- Shawn

"For the things we have to learn before we can do them, we learn by
doing them."
  Aristotle

* Perl tutorials at http://perlmonks.org/?node=Tutorials
* A searchable perldoc is at http://perldoc.perl.org/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: efficiently keeping a short list

[Jay Savage]

On 7/10/06, Mr. Shawn H. Corey <[EMAIL PROTECTED]> wrote:

Jay Savage wrote:
>   foreach ('a'..'z') {
>  $recent{$_} = time;
>  sleep 1;
>   }

Ouch. The OP did mention his limit was 200. So he must have more than
200 elements to scan. This algorithm will takes at least 3m20s, so it's
hardly fast (which was one of the points of this exercise).



Ah, I just did the math. I think you're responding to the post with
disappearing text. My follow-up made it clear that there were missing
paragraphs in the original, and the code with sleep was just to
simulate a user experience. Whatever the elemets are, it's unlikely
that a person will access more thn one of them per second. So we want
adding items to be speedy, but I figured in some time between adds to
let the example work with time() as it would in a "real world"
application.

If you expect less than 1s between adds, use Time::HiRes.

I hope that makes things a little clearer.

-- jay
--
This email and attachment(s): [  ] blogable; [ x ] ask first; [  ]
private and confidential

daggerquill [at] gmail [dot] com
http://www.tuaw.com  http://www.dpguru.com  http://www.engatiki.org

values of β will give rise to dom!

Re: efficiently keeping a short list

[Jay Savage]

On 7/10/06, Mr. Shawn H. Corey <[EMAIL PROTECTED]> wrote:

Jay Savage wrote:
>   foreach ('a'..'z') {
>  $recent{$_} = time;
>  sleep 1;
>   }

Ouch. The OP did mention his limit was 200. So he must have more than
200 elements to scan. This algorithm will takes at least 3m20s, so it's
hardly fast (which was one of the points of this exercise).



Not sure what kind of hardware you have, but it takes considerably
less than a second for me. Not counting the sleep(), of course, which
was just to guarantee unique timestamps for the example. Assuming the
data being used for the keys (the "elements") is of a reasonable size
(for most values of "a reasonable size") my example should easily
handle 10's of thousands of "elements" (without the sleep. ;) ).

Don't believe me? Try this:

#!/usr/bin/perl -w
use strict;
use Time::HiRes;

my %recent;
my $limit = 200;

sub get_list {
   my @sorted = sort {$recent{$b} <=> $recent{$a}} keys %recent;
   foreach (@sorted[$limit..$#sorted]){
   delete $recent{$_};
   }
   return @sorted[0..$limit-1];
}

# example usage:

my $time1 = Time::HiRes::time;

foreach ( 0..1 ) {
   $recent{$_} = Time::HiRes::time;
}

print get_list(), "\n";

my $ct =0;

while (my ($k, $v) = each %recent) {
   print "$k: $v\n";
}

my $time2 = Time::HiRes::time;

my $delta = $time2 - $time1;

print "\ntook $delta seconds\n";


For those 10,000 "records" response averages around .5s on my machine,
which is a windows workstation running all sorts of things in the
background, hardly optimal conditions. And that's still not a fair
becnhmark because the print time, by far the most time-consuming part
of the whole operation, is factored into the total. Hashes are fast
and Perl's built-in sort isn't as shabby as most people think.



Try:

my $id = 0;
for ( 'a' .. 'z' ){
  $recent{$_} = $id++;
}

Of course, this assumes you have enough memory for everything. These
days, this is normally true for a personal computer but web servers can
run out of memory because they have so much else to do to.



Yes the problem here is that you're pretty much guaranteed to overflow
$id at some point, given a sufficienly long-running process, even
discounting the size of the hash. That's why I went for time() or
Time::HiRes::time() instead of an autoincrement; no muss, no fuss.
Unless you're still running your script on the same hardware in 2038.


Of course since OP didn't give any implementation details, it's
possible that the list could grow even larger between calls to
get_list(). Maybe the user will only want the list of 200 recent items
after an average of 1,000,000 elements are added. Then, sure, you'll
want to take a different approach. If that's the case, I'd recommend
getting a copy of _Mastering Algorithms With Perl_, and reading up on
linked lists and b-trees.

In my experience, though, it's standard to size the list slightly
larger than the number elements you expect to add between accesses.
For most UI situations, the working definition of "recent items" is
"the most items we think a normal user will access between views of
'recent items.'" The value of a recent items list decreases rapidly
when users use more items in a session than the list can hold, and
demonstrably recent items get shifted off the bottom.

best,

-- jay
--
This email and attachment(s): [  ] blogable; [ x ] ask first; [  ]
private and confidential

daggerquill [at] gmail [dot] com
http://www.tuaw.com  http://www.dpguru.com  http://www.engatiki.org

values of β will give rise to dom!

Re: write out filenames of files existing on a filesystem into afile

[Ask Bjoern Hansen]

Rob Dixon wrote:


Not much chance of that I'm afraid Shawn. I can do without the
apology, I just wish he'd confirm that his original critique was
wrong instead of banging on about filenames with three dots. I think
leaving people with that misinformation uncorrected is a lot more
important.


Hi Rob (and everyone else!),

I for one appreciate your easy going attitude about it.   Reading the 
thread it could have even less pleasant very fast otherwise.


Randal was indeed a little harsh, but on the other hand then you did 
repeat something sub-optimal after he tried to help you improve your 
suggestion.  I can see his frustration with that (too).


Please let the subject go, everyone.  Not harping on about it will be 
the fastest way to get the list back to the usual friendly place (I hope).


That being said, I'd like to point out that Dr. Ruuds suggestion of 
using "-f" seems like the most elegant (and portable) solution to the 
original posters question.   I'll leave it to the rest of you to explain 
"-f" and the other file test operators better.   :-)



 - ask ([EMAIL PROTECTED], temporary list-dad)


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: write out filenames of files existing on a filesystem into afile

[Randal L. Schwartz]

> "Shawn" == "Mr Shawn H Corey" <[EMAIL PROTECTED]> writes:

Shawn> Not everyone who reads this mailing list posts to it. What impression
Shawn> would his comments leave on them? How can we encourage people to use
Shawn> Perl if they think they will receive harsh criticism? The fact that the
Shawn> criticism was to a response and not an original post is unimportant; the
Shawn> fact that is was done is.

I never criticize a question here (unless it's homework), so this shouldn't
be construed by onlookers as a discouragement to ask questions.

I *do* criticize broken *answers* though, so hopefully anyone looking
on will *test* their answers before posting.  Then the original questioner
gets *good* code, I can skip answering that, and we *all win*.

This is what I'm aiming for.  Ask all you want, but when you answer, be DAMN
WELL sure that it's a good answer.  And if you're not sure or you don't have
time to test, MOVE ON, because someone else will probably answer better,
faster, cheaper.  There's enough experts in this group already: we don't need
to be distracted by threads like this where we've had to point out the flaws
in an answer.

Thank you.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: write out filenames of files existing on a filesystem into afile

[Randal L. Schwartz]

> "Rob" == Rob Dixon <[EMAIL PROTECTED]> writes:

Rob> Not much chance of that I'm afraid Shawn. I can do without the apology, I 
just
Rob> wish he'd confirm that his original critique was wrong instead of banging 
on
Rob> about filenames with three dots. I think leaving people with that 
misinformation
Rob> uncorrected is a lot more important.

My original critique was wrong.  I mistook /^[.]/ for /[^.]/.

So your post was wrong, but I said it was wrong for the wrong reasons.

That still doesn't solve the problems I addressed about your post elsewhere,
nor that you had to go three rounds with me in private email repeatedly
looking for some way to "save" your original post from being labeled wrong.

I'm here for the group.  I want people to walk away from this list knowing how
to code *better* Perl.  Your post distracted from that.  I have nothing
against you personally, but your behaviors distract from my goal, and will be
called for what they are.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: write out filenames of files existing on a filesystem into afile

[Randal L. Schwartz]

> "Mumia" == "Mumia W "  writes:

Mumia> Not quite. Rob's program works for rational input data.

And that attitude creates fragile, eventually broken code.

Many years ago, people wrote shell scripts that couldn't deal with spaces in
filenames, because they said something like you just said... "but who would
ever put a SPACE in a filename?".

And now, look around you.  The integration of Unix filesystem space with
Windows and Mac mounts mean that *every* Unix utility has to deal with spaces
in the name.

However, those of us who looked forward and said "you know, *I* may not have
any files that have spaces in the names now, but I'll code to allow for that"
had no problems.  We've been writing scripts to "do the right thing" for
years.

Similarly, if you use a regex like /^\.\.?$/ to check for "an empty
directory" as a security check in some step of your program, a bad
guy can come along and create a file named "..\n" (which is perfectly
legal and matches that regex) that your program will overlook. (The
regex should actually be /\A\.\.?\z/.)

Oops.  Security hole.

So, what I'm arguing for here is not what to do for the common case, but what
to do to prevent future breakage and especially future security issues.

Filenames in Unix can contain any character except "/" and "\0".  Period.
Account for it.  Work with it.  Deal with it.  Even if you think only insane
people would names things differently from your rules, it's the insane person
that will eventually invoke your code, so you might as well Do It Right to
begin with.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Specify download file name

[Anish Kumar K.]

Hi Prasanna

Thanks for the reply. But that is not helping me in the situation

Thanks
Anish

Nagasamudram, Prasanna Kumar wrote:

Hi Anish

Can you try adding the following to your $cgiObject->header ?

-attachment=>'$filename.zip',

And changing

-type=>'application/zip'   to -type=>'application/octet-stream'


[PS : The above is not tested]

Thanks
Prasanna

-Original Message-
From: Anish Kumar K. [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 11, 2006 3:43 PM

To: beginners@perl.org
Subject: Specify download file name

Hi

This is somewhat easy question I feel but for some reason I am not 
getting this


The issue is I am using CGI to download a file, I am setting the header 
as this
print 
$cgiObject->header(-type=>'application/zip',-charset=>'',-Expires=>'-1d'
,-'Cache-Control'=>'private, 
max-age=0');


the download works fine. But the issue is the file name it is coming as 
the filename...say when I download I am geting "downloadwav.pl".
which is the file name of the perl file. Is there a way I can specify a 
file name, It is a zip file.


I tried this
$file_name="attachment.zip";
print "Content-Disposition: attachment; filename = $file_name\n\n";

Not working...any help

Thanks
Anish


  



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Still getting errors

[Mr. Shawn H. Corey]

Ryan Dillinger wrote:
> Hello again,
>  I have rewrote this script I hoped the way you told me.
> And now I have just one error that states: Use of uninitialized value in
> hash element at
> names.pl line 24, <> line 1.

You are not posting the script you are running. It is difficult to
answer specific questions without it.

In general, you get this warning if you use a key for a hash that does
not have an entry in the hash. To avoid it, use exists to determine if
there is an entry:

  if( exists( $hash{$key} ) ){
...
  }

See `perldoc -f exists` for details.


-- 
__END__

Just my 0.0002 million dollars worth,
   --- Shawn

"For the things we have to learn before we can do them, we learn by
doing them."
  Aristotle

* Perl tutorials at http://perlmonks.org/?node=Tutorials
* A searchable perldoc is at http://perldoc.perl.org/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: Still getting errors

[Charles K. Clarkson]

Ryan Dillinger wrote:
: Hello again,
:   I have rewrote this script I hoped the way you told me.
: And now I have just one error that states: Use of uninitialized
: value in hash element at names.pl line 24, <> line 1

When I run the script I get this. Are you sure this is
the script you are running?

Global symbol "$search" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 13.
Global symbol "%name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 14.
Global symbol "$raw" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 17.
Global symbol "$in" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 27.
Global symbol "$in" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 29.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 30.
Global symbol "$keys" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 30.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 31.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 31.
Global symbol "$in" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 33.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 36.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 37.
Global symbol "$in" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 39.
Global symbol "$search" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 41.
Global symbol "$search" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 44.
Global symbol "$keys" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 45.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 53.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 54.
Global symbol "$name" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 54.
Global symbol "$in" requires explicit package name at
C:\1\dfwrein\cgi-bin\a.pl line 60.
Execution of C:\1\dfwrein\cgi-bin\a.pl aborted due to compilation errors.




Charles K. Clarkson
-- 
Mobile Homes Specialist
Free Market Advocate
Web Programmer

254 968-8328

Don't tread on my bandwidth. Trim your posts.


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Still getting errors

[Ryan Dillinger]

Hello again,
 I have rewrote this script I hoped the way you told me.
And now I have just one error that states: Use of uninitialized value in 
hash element at

names.pl line 24, <> line 1.
Forgive me, but I'm not sure what's going on here.



#!/usr/bin/perl

use warnings;
use strict;

my %names = ();
my @raw = ();
my $fn = "";
my $ln ='';
my @keys = ();
my @n = ();

$search = '';
%name;
while (<>) {
  @raw = split;
  $names{ $raw[ -1 ] } = "@raw[ 0 .. $raw -1 ]";
}

while () {
print "\n1. Sort names by last name\n";
print "2. Sort names by first name\n";
print "3. Search for a name\n";
print "4. Quit\n\n";
print "Choose a number: ";

chomp( $in =  );

if ($in eq '1') {
foreach $name ( sort $keys %names ) {
print "$name, $names{$name}\n";
  }
} elsif ($in eq '2') {
   @keys = sort { $names{$a} cmp $names {$b} } keys %names;

  foreach $name ( @keys ) {
 print "$names{name} $name\n";
  }
} elsif ($in eq '3') {
  print "Search for what? ";
  chomp( $search =  );
  @keys;
while ( @n = each %names ) {
  if (grep /$search/, @n) {
$keys[++$keys] = $n[0];

push @keys, $n[ 0 ];
   }
 }
 if (@keys) {
print "Names matched: \n";

foreach $name ( sort @keys ) {
  print " $names{$name} $name\n";
  }
} else {
  print "None found.\n";
}
@keys = ();
} elsif ($in eq '4') {
  last;
} else {
  print "Not a good answer. 1 to 4 please.\n";
}
}

Sorry I just can;t figure it out.Thank You



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: Specify download file name

[Nagasamudram, Prasanna Kumar]

Hi Anish

Can you try adding the following to your $cgiObject->header ?

-attachment=>'$filename.zip',

And changing

-type=>'application/zip'   to -type=>'application/octet-stream'


[PS : The above is not tested]

Thanks
Prasanna

-Original Message-
From: Anish Kumar K. [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 11, 2006 3:43 PM
To: beginners@perl.org
Subject: Specify download file name

Hi

This is somewhat easy question I feel but for some reason I am not 
getting this

The issue is I am using CGI to download a file, I am setting the header 
as this
print 
$cgiObject->header(-type=>'application/zip',-charset=>'',-Expires=>'-1d'
,-'Cache-Control'=>'private, 
max-age=0');

the download works fine. But the issue is the file name it is coming as 
the filename...say when I download I am geting "downloadwav.pl".
which is the file name of the perl file. Is there a way I can specify a 
file name, It is a zip file.

I tried this
$file_name="attachment.zip";
print "Content-Disposition: attachment; filename = $file_name\n\n";

Not working...any help

Thanks
Anish


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Specify download file name

[Anish Kumar K.]

Hi

This is somewhat easy question I feel but for some reason I am not 
getting this


The issue is I am using CGI to download a file, I am setting the header 
as this
print 
$cgiObject->header(-type=>'application/zip',-charset=>'',-Expires=>'-1d',-'Cache-Control'=>'private, 
max-age=0');


the download works fine. But the issue is the file name it is coming as 
the filename...say when I download I am geting "downloadwav.pl".
which is the file name of the perl file. Is there a way I can specify a 
file name, It is a zip file.


I tried this
$file_name="attachment.zip";
print "Content-Disposition: attachment; filename = $file_name\n\n";

Not working...any help

Thanks
Anish


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Curses::UI: No definition found for '< Yes >'

[Mumia W.]

Chasecreek Systemhouse wrote:
> On 7/10/06, Mumia W. <[EMAIL PROTECTED]> wrote:
>> I'm trying to learn to use Curses::UI, and I read the top of "perldoc
>> Curses::UI" and found some example code. Unfortunately, it doesn't work.
>> This is my program:
>> 
>> #!/usr/bin/perl
>> 
>> use strict;
>> use warnings;
>> use Curses::UI;
>> 
>> my $cui = new Curses::UI (-color_support => 1);
>> my $my = $cui->dialog(
>>  -message => 'Hello World.',
>>  -buttons => ['< Yes >', '< No >'],
>>  -values => [1, 0],
>>  -title => 'First Dialog',
>>  );
>> 
>> __END__
>> 
>> When I run this program, I get this error message:
>> 
>>> > Fatal program error:
>>> > --
>>> > process_buttondefs(): Invalid button type.
>>> > No definition found for '< Yes >'
>>> > --
>>> > Press any key to exit...
>> 
> 
> The Curses::UI refers you to a more appropriate example. The example's syntax:
> 
> use FindBin;
> use lib "$FindBin::RealBin/../lib";
> 
> use strict;
> use Curses::UI;
> [...]
> 
> In other words, the < Yes > was supposed to be the label of a button;
> not a button itself...
> 
> HTH/Sx

Thanks. I wanted something simple to start with, and after reading
Curses::UI::Buttonbox's doc page, I created a simple example that works:

#!/usr/bin/perl

use strict;
use warnings;
use Curses::UI;

my $cui = new Curses::UI (-color_support => 1);

my $my = $cui->dialog(
-message => 'Hello World.',
-buttons => ['yes', 'no'],
-values => [1, 0],
-title => 'First Dialog',
);

__END__

'Yes' and 'no' are pre-defined button names.



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]