split by word using | as delimiter

[William]

input file - dummylist.txt:
|ZZ_JEN|1|0|0|0|[email protected]

expected output:
6
ZZ_JEN

current output:
35
Z

code in question:

#!/usr/bin/perl -w

use strict;

my $dummy_list = "/mkapp/webapps/mxrt-cgi/upload_vol/dummylist.txt";

open ( DUMMY_FD , $dummy_list ) || die "Cannot open file $dummy_list\n";
my @lines = <DUMMY_FD>;
foreach my $currentLine ( @lines ) {
my @instrumentEntries = ( split(/|/, $currentLine) );
my $numEntries = @instrumentEntries;
print $numEntries . "\n";

print $instrumentEntries[1] . "\n";
}
close ( DUMMY_FD );


for the line
my @instrumentEntries = ( split(/|/, $currentLine) );

what is the correct way to split $currentLine of the input file?



P.S. i already checked perldoc -f split and perldoc -q split.

 

[it_says_BALLS_on_your forehead]

I just went through this! escape the | :


my @instrumentEntries = ( split(/\|/, $currentLine) );

Can't say if there is anything else wrong in your code, but the escape was
one thing I missed in the same situation just an hour or so ago.

yes. the pipe, '|', acts as a logical 'or' for regular expressions.

 

[Tad McClellan]

my @instrumentEntries = ( split(/|/, $currentLine) );

The vertical bar is "meta" in regular expressions, it
allows alternations (or).

what is the correct way to split $currentLine of the input file?

Backslash metacharacters to match a literal character:

my @instrumentEntries = ( split(/|/, $currentLine) );

P.S. i already checked perldoc -f split and perldoc -q split.

Thanks for doing that.

The reason you didn't find the answer there is because you
had a problem with your regex rather than with split().

 

[John W. Krahn]

input file - dummylist.txt:
|ZZ_JEN|1|0|0|0|[email protected]

expected output:
6
ZZ_JEN

But you have seven fields there, not six.

current output:
35
Z

code in question:

#!/usr/bin/perl -w

use strict;

my $dummy_list = "/mkapp/webapps/mxrt-cgi/upload_vol/dummylist.txt";

open ( DUMMY_FD , $dummy_list ) || die "Cannot open file $dummy_list\n";

You should include the $! variable in the error message so you know *why* it
failed to open.

my @lines = <DUMMY_FD>;
foreach my $currentLine ( @lines ) {

Is there a valid reason to read the entire file into an array first? (Instead
of just reading one line at a time?)

my @instrumentEntries = ( split(/|/, $currentLine) );

As has been explained by others, certain characters serve a special purpose in
a regular expression (and | is one of them.)

my $numEntries = @instrumentEntries;
print $numEntries . "\n";

print $instrumentEntries[1] . "\n";
}
close ( DUMMY_FD );


for the line
my @instrumentEntries = ( split(/|/, $currentLine) );

what is the correct way to split $currentLine of the input file?



P.S. i already checked perldoc -f split and perldoc -q split.

The first argument to split() is a regular expression so the regular
expression man page(s) should be consulted.



John

 

[Eric J. Roode]

Others have answered your primary question. I just have a couple of
comments; hope you don't mind.

open ( DUMMY_FD , $dummy_list ) || die "Cannot open file $dummy_list

\n";

If 'open' (or many other functions) fails, the reason is stored in the
variable $! -- it is a good idea to include that in your error message.

my @lines = <DUMMY_FD>;
foreach my $currentLine ( @lines ) {

Strictly speaking, it is not wrong to do the above. But it generally
makes more sense to write the above as:

while (my $currentLine = <DUMMY_FD>) {

Why read the entire file into memory, when you're only dealing with one
line at a time? For small files, the difference is trivial. I
personally regularly deal with files and database tables whose sizes
range in the tens of gigabytes. Reading files one line at a time is a
good habit to get into.

my @instrumentEntries = ( split(/|/, $currentLine) );

As others have pointed out, | is special within regular expressions, and
must be escaped to be treated as a literal.

P.S. i already checked perldoc -f split and perldoc -q split.

Very good. This alone puts you ahead of 90% of posters to
comp.lang.perl.misc.

--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`

 

[Dr.Ruud]

Eric J. Roode schreef:

William:

Strictly speaking, it is not wrong to do the above. But it generally
makes more sense to write the above as:

while (my $currentLine = <DUMMY_FD>) {

Why read the entire file into memory, when you're only dealing with
one line at a time?

That distinction seams not clear to many Perl programmers.

Compare this version:

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

while (<>) {
chomp;
print "$.\t$_\n";
}

to this one: (s/while/for/)

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

for (<>) {
chomp;
print "$.\t$_\n";
}

From perlfaq4:
Use of ".." in a "for" loop will iterate over the range, without
creating the entire range.

 

[Eric J. Roode]

Eric J. Roode schreef:

William:

Strictly speaking, it is not wrong to do the above. But it generally
makes more sense to write the above as:

while (my $currentLine = <DUMMY_FD>) {

Why read the entire file into memory, when you're only dealing with
one line at a time?

That distinction seams not clear to many Perl programmers.

Compare this version: [...]
to this one: (s/while/for/)

[...]

I'll grant you that -- the difference between <> in a 'while' and in a
'for' is subtle, annoyingly so.

Nut I frequently see beginners *explicitly* reading all the lines in a file
into an array, and then iterating over that array, as the OP did above.

--
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`

 

[Anno Siegel]

("But I ... ?)

In any case, as a perl dabbler, I can tell you why some of these
inappropriate techniques are used. Often I need to get something working
in perl where there is already a fairly complex set of perl scripts
involved and I need to add or change just a small part of it.

Not being a perl expert I look for example code and piece things together.
If I need to get from A to Z and I can find A->B, B->C, C->Z that's
what gets used even if there is a better way.

We have a deliberately disparaging term for that: cargo cult programming.
The idea is that parts of machinery are put together without understanding
their function, with less than optimal results.

(The analogy is also disparaging to the people who practice what is known
as "cargo cults". Their motives are not really understood. This is, one
hopes, not deliberate.)

The fact that cargo cult programming "gets things done" really only works
in one-off solutions. When you have to make something work once, with one
set of data, and never again, then an anything-goes approach is fine,
including shameless cargo-culting.

For anything that gets re-used, it is likely to break down in border-line
cases (because the parts don't fit together neatly), or under load (because
the solution is inefficient). Changing it, for one of these or other
reasons, is particularly hard, because there are parts that aren't
understood, so can't be changed.

Now to give myself a little more credit I do try to find the best way but
sometimes I just don't find it.

That is very good, not just for reasons of programming morals, but you
get better-quality software out of it. Cargo-cult programs are shoddy,
not only in an aesthetical, but in a practical sense.

The perl book I use for reference (Programming Perl) seems to focus on:
Facts (like trrying to learn a language fom a dictionary)

Yes, it's a reference (and more).

Advanced features (e.g. arrays of hashes)

Those are essential to modern Perl programming.

Clever tricks

Only very few are there just for their cutesey-factor. Perhaps what
you call "clever tricks" is what we call "idioms", handy solutions
for recurring problems that have become fixed phrases.

I guess I need a better overall education in perl.

The best education is practice, practice, practice.

The problem with printed material is that it ages rapidly. _Programming
Perl_ is more than just a reference. It is written to be read cover
to cover, and it's well worth while doing so, even including the reference
parts. However, some aspects have changed (IO, Unicode), new standard
modules have evolved, so parts of it aren't quite up to date anymore.

Anno

 

[axel]

Now to give myself a little more credit I do try to find the best way but
sometimes I just don't find it.

The perl book I use for reference (Programming Perl) seems to focus on:
Facts (like trrying to learn a language fom a dictionary)
Advanced features (e.g. arrays of hashes)
Clever tricks

Perhaps you should add the Perl Cookbook to your library.

Axel