get file type info from lstat?

[Xuer]

Can I get the file type info from the result list of lstat?
such as if it's a dir( as -d), or a slink( as -s) ...etc.
how to ?

thanks.


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

Re: From Windows -> Linux

[Owen Cook]

On Sat, 13 Mar 2004, Robert wrote:

> I will be going totally Linux for a variety of reasons. My question is 
> this. I have been using ActiveState for a while and use PPM but in one 
> sense it was kind of limiting because I would search CPAN and see 
> something I liked but not be able to try it. Once I move to Linux that 
> whole world opens up to me correct?
> 
> Where is a quick tutorial on using CPAN? Using in the sense of getting 
> modules and compiling them for use.


Well here I can type   perldoc CPAN   and it tells me all. Maybe it is the
same on windows?


Owen


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

From Windows -> Linux

[Robert]

I will be going totally Linux for a variety of reasons. My question is 
this. I have been using ActiveState for a while and use PPM but in one 
sense it was kind of limiting because I would search CPAN and see 
something I liked but not be able to try it. Once I move to Linux that 
whole world opens up to me correct?

Where is a quick tutorial on using CPAN? Using in the sense of getting 
modules and compiling them for use.

Robert

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

Re: perl -d / apache server debug

[Peter Scott]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Mike Ni) writes:
>I have at least 25 perl files written by a person who
>isn't here anymore. All these perl script files were
>programmed to serve the inquiry from the Internet via
>the web server. 
>
>For me to understand the logic behind all these perl
>files, I want to find a way so I can trace the flow
>and look into the data structure. 
>
>In addition to "perl -d", is there better way to do?
>
>Since, these perl scripts were written taking to the
>webserver, therefore the "perl -d" would not work me
>very well? Am I right? 

ptkdb supports remote debugging hooks that will do
what you want.

Perl programs intended to run behind a web server
should be developed so that they can be tested
from the command line, so you don't have to ask for
this help in the first place.

-- 
Peter Scott
http://www.perldebugged.com/
*** NEW *** http://www.perlmedic.com/

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

Re: help with a regex and greediness

[R. Joseph Newton]

Stuart White wrote:


> the file format is not sloppy at all.  I was just
> confused as to why I couldn't use split on the first
> space score comma and space, and then the next space
> score.  <-Perhaps I just answered my question right
> there, seeing that in the second iteration, there is
> no comma and then space.

So are the team names all you want out of the lines?  I guess I never fully
absorbed that.

Joseph


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

Re: help with a regex and greediness

[R. Joseph Newton]

Stuart White wrote:



> $line =
> "merlyn::118:10:Randal:/home/merlyn?/usr/bin/perl";
> @fields = s;oit(/:/,$line);
> #now @fields is ("merlyn:,
> "","118","10","Randal","/home/merlyn","/usr/bin/perl")

I don't think so:

Greetings! E:\d_drive\perlStuff>perl -w
$line =
  "merlyn::118:10:Randal:/home/merlyn?/usr/bin/perl";
  @fields = split(/:/,$line);
  print "$_\n" foreach @fields;

^Z
merlyn

118
10
Randal
/home/merlyn?/usr/bin/perl

The only place a colon split splits is where you have a colon.

> I was having trouble using this example to figure out
> why my line wasn't splitting the way I wanted.  So I
> included this line:
> $line = 'Spurs 94, Suns 82, Heat 99, Magic 74'
>
> > > then @result would look like this, right?
> > > @result[0] = 'Spurs 94'
> >
> > You should know better than this by now, with the
> > help you've been getting.
> > With that @ symbol, you are referring to a slice--an
> > array of one element.  ***
> > When you are referring to a scalar, use the scalar
> > symbol $ ***
> >
>
> Yes, that was an error on my part.  You're right, I
> know that it should have been $result[0]

OK.  It can be tricky, and it took me a few go-rounds to get that down.

> > > @result[1] = 'Suns 82'
> >
> > These first two make sense, pretty much.  I think
> > this is one place where $team1
> > and $team2 might be more sensible, though it is even
> > better, if there is some
> > order to which team is listed first in the pairing,
> > to have you identifier
> > reflect that order, say $home_team and $visitor [if
> > these are accurate of
> > course]
>
> I'll have to study the data to make sure that the home
> team and visiting teams are consistently in the same
> place.  That's a good idea too.

...or you could even use $team_left and $team_right, since those terms would
accurately describe the relative positions of the two substrings within each
line.

>
>
> >
> > >
> > > @result[2] = 'Heat 99'
> >
> > Going on to load more elements into the array does
> > not make sense..  Does your
> > data come in one continuous line, just a long string
> > of team names separated by
> > commas?
>
> Addressed above.

OK.  Sorry I missed the runup.

>
>
> My impression is that it came line by line.
> >  There would be no sense in
> > doing the work of the split only to throw everything
> > back in the same pile.
>
> > There are a lot of different things you could do
> > here, but the sensible ones
> > would indicate that you should do something with the
> > stats for each pairing
> > before you go on to the next line.
> >
> >
> > >
> > > @result[3] = 'Magic 74'
> > >
> > > If I wanted to split on the numbers as well, why
> > > doesn't this work:
> > > @result = split (/\s*\d*,\s*\d*/, $line);
> >
> > The previous post already explained this, and you
> > have seen the result of what
> > you are trying.  You can't do that because the
> > information disappears if you use
> > it in the split expression.
> >
>
> I see.  It seems that I didn't pick up on this
> entirely, though I do remember reading it.
>
> > Splitting the lines into a pair of team-score
> > combinations is one step.  It
> > deserves a line of its own.
> > Extracting the name and score from each team-score
> > clause is another step that
> > deserves a line or three of its own.
> >
>
> Ok, I didn't know this.  I thought I could, and should
> do it all in one or two lines.  I get confused about
> what data $_ has sometimes.

This is a very good indicator that you should be using the default $_ less and
named variables more.  It all may look the same to the compiler, but since human
error is the most likely cause of problems, it is more important to be as
understandable as possible to the human reader.

> After I run the initial
> regex, I am usually extracting information from the
> backreferences.  When those backreferences or $_
> contain more info than I want, my solution is to
> tighten the original regex.  You are suggesting that
> instead of that, I ought to just run a second regex on
> it, or a split on it in order to take the stress off
> of Perl and keep the program efficient, right?  Is
> that what you are suggesting?

Whenever possible, yes.  Try to think through the process the regex engiine will
take.  The classic example is the line trim.  You can do this

$string =~ s /^\s*(.*?)\s*$/;
and it will work, but the engine has to pack all the middle protion around.  It
works much better as:
$string =~ s/^\s*/;
$string =~ s/\s*$/;

likewise a couple well-placed simple splits should handle you lines quite
efficiently--and clearly

my $scoreboard_left, $scoreboard_right = split /,\s*/, $scores_line;
for ($scoreboard_left, $scoreboard_right) {
my ($team_name, $score) = split /\s+/, $_;
...whatever you are doing with the score
}

I must confess that I am a bit at a loss as to what to do with the information
at this point.  I have forgotten what your goal is in terms of the form of
output information you want.  Presumably, you should have some str

Re: Improving performance when working with large text files

[James Edward Gray II]

On Mar 13, 2004, at 1:09 PM, R. Joseph Newton wrote:

"West, William M" wrote:


by slurping the WHOLE file into memory at once (do you have room to 
but a 45
megabyte file into memory?)  the speed of the processing went up-
Highly unlikely.  There is no real speed advantage with Perl in 
slurping a
file.
Slurping certainly can be faster.  I agree that it's not for 
everything, but it certainly has it's place.

There's and excellent article on perl.com about this:

http://www.perl.com/pub/a/2003/11/21/slurp.html

James

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

Re: Read from tape device

[R. Joseph Newton]

Jakob Kofoed wrote:

> Hi again,

Hi,

> Sorry for the delayed answer.

Tha's okay, but please don't top-post.  Instead  trim out anything to which you are
noit directly replying, and follow comments with your specific responses, then add
anything new in a block following.  It helps to keep the flow of discussion cogent.

>
>
> Thank you for all your comments (Yes Joseph, I will try to enhance my basic
> abilities - sorry for the bad code:-)

Actually, the issue is not so much code as meaning.  As you translate a real-world
problem into code, try not to let the meaning become less clear.  Imagination helps
considerably.  If you have any way to visualize the matter your code is describing,
try to do that.  Then it should be much more clear what variable names would best
describe the real-world matter.

>
>
> My thoughts on this project was to make a perl script which copy the content
> of a tape to disk, no matter if it is tar archives, binary files, EBCDIC and
> so on, much like the UNIX tcopy.

Don't try to do it all with the same code.  Instead of writing a script, write a
program, with separate fucntions designed for each kind of file you may to encounter.
You will save yourself a world of grief approaching the problem this way.

> But, I work on Linux and don't have the
> tcopy available.

Oboy, I don't know about this.  This seems like a prety demanding project.  If this is
production work, I would recommend that you Google for some product that has already
ben proven, but...

What is the format in which the tape files are stored?  This is going to be critical.
Since tape is a sequential medium, I assume that each file should be preceded by some
form of header, rather than using a central directory as with a dsik  I don't know,
though.  It is critical that, if you take on this project, you find out and use this
information.  Your best bet is to use file and block size information as you process.
That is

until(end_of_tape_reached()) {
my $file_info = get_file_information(\*TAPE_STREAM);
extract_file($file_info, \*TAPE_STREAM);
}

sub extract_file {
my ($file_info, $tape_stream) = @_;
my $file_type = $file_info->{'file type'};
my $storage_schema = $file_info->{storage schema'};
if ($file_type eq 'EBCIDIC') {
extract_as_EBCIDIC($file_info, $storage_schema, $tape_stream);
} elsif ($file_type eq 'binary') {
extract_as_binary(($file_info, $storage_schema, $tape_stream);
   ...
   }
}

...

>
>
> When you write multiple files to a tape it creates an physical "end of file
> marker" at the end of each file. When some applications write to tape they
> make an EOF between each file and then a double EOF at the end of the tape.

I think you may be causing trouble for yourself trying to do character-based
transfer.  The difference in encodings should raise an alarm bell on that score.  Why
not look for the file size for each file to be transferred, and then use binary-mode
IO?  As I said, I really know nothing about the way files are stored on tape.  The
last tape drive I used was audio tape to load programs onto my Timex-Sinclair 1000.
Yet I am fairly confident that the code above could serve as a driver for this
process.

Why?  Because it is written at a high level, that allows it to direct the process
while leaving implementation detail to the fuctions that it calls.  That is the magic
of structured programming.  It allows you to focus on one level of abstraction at a
time.

HTH,

Joseph


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

Re: second-level string interpolation

[Michael C. Davis]

At 10:39 AM 3/13/04 -0800, R. Joseph Newton wrote:
>> my $header = <<'end_of_header';
>> # File: $filename
>> end_of_header
>>
>> my $filename = 'xyz';
>> print $header, "\n"; # output: want to see # File: xyz, but get # File:
>> $filename
>
>I am not sure how the above is any more clear than it would be if you
assigned a
>value to $filename first.

Mainly that $filename would have different values at different times, in
different code locations.

>I still can't see a good reason for putting that low-level implementation
detail
>at the top of the script, but this approach should work.

I agree, your approach is better at avoiding hidden dependencies and at
keeping code and data closer together.



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

Re: Improving performance when working with large text files

[R. Joseph Newton]

"West, William M" wrote:


> by slurping the WHOLE file into memory at once (do you have room to but a 45
> megabyte file into memory?)  the speed of the processing went up-

Highly unlikely.  There is no real speed advantage with Perl in slurping a
file.  The only good reason I can think of is if there is some reason that all
data in the file must be cross-related in some way, and if the file data itself
is already stored in some very condensed manner.

> ...

> pps- i just reread the question and realized that he was interested in
> reading the file in faster!!  ok::
>
> undef$/;#kills the 'line delimiter'-> maybe "local $/= undef;" in
> #a subroutine is safer

Nope.  Reading it line by line is much more likely to speed up the process.
Also, simplifying regexes will, even if it requires more regular expressions be
run on each line.  Regular expressions with fewer variables will run faster,
because they will have fewer decisions to make.

Joseph


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

Re: second-level string interpolation

[R. Joseph Newton]

"Michael C. Davis" wrote:

> Hi, Apologies if I'm bringing up a repeated topic.   I searched the list
> archive and the web and nothing specific has turned up so far.
>
> Is there a way to defer evaluation of the contents of a here-doc-defined
> value such that one can embed variables in the here-doc and not have them
> evaluated until they are used later?  Something like this:

It looks like you have gotten some good pointers to how you can accomplish
this.  I would suggest that you give some thought to whether it is a good idea
to try this.  What do you hope to accomplish by doing this?  If you simply don't
want to have the heredoc someplace where it interferes wh the flow of code,
there is a much better, much less obfusciated way.

>
>
> code:
> -
> use strict;
> use warnings;
>
> my $header = <<'end_of_header';
> # File: $filename
> end_of_header
>
> my $filename = 'xyz';
> print $header, "\n"; # output: want to see # File: xyz, but get # File:
> $filename

I am not sure how the above is any more clear than it would be if you assigned a
value to $filename first.

>
>
> I tried a few variations and nothing seems to work, as shown below.  (This
> RFC http://dev.perl.org/perl6/rfc/229.html from Perl 6 implies that there
> is fact no way to do this.)  Can anyone clarify.  Thank you.

How about this:

Greetings! E:\d_drive\perlStuff>perl -w
use strict;
use warnings;

sub file_report_line {
   my $filename = shift;

   return  

Re: help with a regex and greediness

[Stuart White]

--- Paul Johnson <[EMAIL PROTECTED]> wrote:
> 
> Stuart White said:
> 
> > I'm not sure what's going wrong here.  Can someone
> > tell me how I can split 'Spurs 94, Suns 82' into:
> > array[0] == 'Spurs' and array[1] == 'Suns'
> 
> @array = /([[:alpha:]]+)/g;
> 

This did what I wanted it to do, thanks!
> -- 
> Paul Johnson - [EMAIL PROTECTED]
> http://www.pjcj.net
> 


__
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

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

Re: help with a regex and greediness

[Stuart White]

--- "R. Joseph Newton" <[EMAIL PROTECTED]> wrote:
> Stuart White wrote:
> 
> > Wow, yeah that helps a lot.
> > Here's a question: If if had:
> > $line = 'Spurs 94, Suns 82, Heat 99, Magic 74'
> >  and then did a split on comma and comma's
> surrounding
> > spaces:
> > @result = split (/\s*,\s*/, $line);
> 
> result?  How specific is "result" to the issue at
> hand?  Would not $score
> 
> >

This is me just trying to get an understanding of
split.  In Learning Perl, there is a good example of
split on a line that is separated by colons.  split
puts all the stuff that isn't a colon into an array,
one element at a time.
$line =
"merlyn::118:10:Randal:/home/merlyn?/usr/bin/perl";
@fields = s;oit(/:/,$line);
#now @fields is ("merlyn:,
"","118","10","Randal","/home/merlyn","/usr/bin/perl")

I was having trouble using this example to figure out
why my line wasn't splitting the way I wanted.  So I
included this line:
$line = 'Spurs 94, Suns 82, Heat 99, Magic 74'


> > then @result would look like this, right?
> > @result[0] = 'Spurs 94'
> 
> You should know better than this by now, with the
> help you've been getting.
> With that @ symbol, you are referring to a slice--an
> array of one element.  ***
> When you are referring to a scalar, use the scalar
> symbol $ ***
> 

Yes, that was an error on my part.  You're right, I
know that it should have been $result[0]

> >
> > @result[1] = 'Suns 82'
> 
> These first two make sense, pretty much.  I think
> this is one place where $team1
> and $team2 might be more sensible, though it is even
> better, if there is some
> order to which team is listed first in the pairing,
> to have you identifier
> reflect that order, say $home_team and $visitor [if
> these are accurate of
> course]

I'll have to study the data to make sure that the home
team and visiting teams are consistently in the same
place.  That's a good idea too.

> 
> >
> > @result[2] = 'Heat 99'
> 
> Going on to load more elements into the array does
> not make sense..  Does your
> data come in one continuous line, just a long string
> of team names separated by
> commas?  

Addressed above.

My impression is that it came line by line.
>  There would be no sense in
> doing the work of the split only to throw everything
> back in the same pile.

> There are a lot of different things you could do
> here, but the sensible ones
> would indicate that you should do something with the
> stats for each pairing
> before you go on to the next line.
> 
> 
> >
> > @result[3] = 'Magic 74'
> >
> > If I wanted to split on the numbers as well, why
> > doesn't this work:
> > @result = split (/\s*\d*,\s*\d*/, $line);
> 
> The previous post already explained this, and you
> have seen the result of what
> you are trying.  You can't do that because the
> information disappears if you use
> it in the split expression.
>

I see.  It seems that I didn't pick up on this
entirely, though I do remember reading it.

> Splitting the lines into a pair of team-score
> combinations is one step.  It
> deserves a line of its own.
> Extracting the name and score from each team-score
> clause is another step that
> deserves a line or three of its own.
> 

Ok, I didn't know this.  I thought I could, and should
do it all in one or two lines.  I get confused about
what data $_ has sometimes.  After I run the initial
regex, I am usually extracting information from the
backreferences.  When those backreferences or $_
contain more info than I want, my solution is to
tighten the original regex.  You are suggesting that
instead of that, I ought to just run a second regex on
it, or a split on it in order to take the stress off
of Perl and keep the program efficient, right?  Is
that what you are suggesting?

> >
> >
> > I just had a thought, it have to look more like:
> > @result = split (/(\s*|\d*),\s*\d*/, $line);
> 
> Unless there is a compelling reason why you must do
> all your regex work for a
> line in one pass, you are better off not doing so.
> 
> Though its Perl implementation is highly efficient,
> the regex process is very
> costly, and the cost rises much more through
> complexity of expression than
> through multiple runs.

Ok, see, I thought that the program would run much
more slowly if I kept running through the data.  I
didn't think to use regular expressions in steps.


> Please review
> perldoc -f split
> for a better understanding.  The split regex, is
> *what gets thrown away*.  Do
> not put any data you may need in it.
> 

The formatting of perldoc from the command line makes
it terribly difficult to read for me.  There are huge
tabs between words.  Is perldoc available in another
format, say the web?  I've gone to the man pages at
perl.org, but I haven't found the equivalent of
perldoc.  Perhaps I've passed over it?  Having perldoc
in a format such that there is one space between each
word, two between each sentence and either an empty
line or a new line and a tab between paragraphs, would
make reading it much more beneficial.  I ju

Re: not getting the syntax

[James Edward Gray II]

On Mar 13, 2004, at 12:36 AM, R. Joseph Newton wrote:

Charlotte Hee wrote:

 $byname{ Owen }{ PHONE } = '999-';
Should be:
$byname{ Owen }->{ PHONE } = '999-';
are you using strict?  The code above should cause an error, not just 
an
uninitialized variable warning.
This isn't true.  The arrow operator (->) is optional between [ ]s and 
{ }s.  The two lines above are identical as far as Perl is concerned 
and error free.

James

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