[15583] in Perl-Users-Digest
Perl-Users Digest, Issue: 2996 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue May 9 18:21:01 2000
Date: Tue, 9 May 2000 15:20:44 -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: <957910843-v9-i2996@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 9 May 2000 Volume: 9 Number: 2996
Today's topics:
Split and "null delimiter" (was: BEGIN and use) <bmb@ginger.libs.uga.edu>
Re: Split and "null delimiter" (was: BEGIN and use) <aqumsieh@hyperchip.com>
Re: Split and "null delimiter" (was: BEGIN and use) <bmb@ginger.libs.uga.edu>
Re: Split and "null delimiter" (was: BEGIN and use) <aqumsieh@hyperchip.com>
Re: Split and "null delimiter" (was: BEGIN and use) (Ilya Zakharevich)
Re: Split and "null delimiter" (was: BEGIN and use) <bmb@ginger.libs.uga.edu>
Re: Split and "null delimiter" (was: BEGIN and use) <bmb@ginger.libs.uga.edu>
Re: Syntax for passing parameters from command line, t <aqumsieh@hyperchip.com>
system(@args) command <skpurcell@hotmail.com>
Re: trying to access elements of a scalar variable (Abigail)
Unix command as other user <jagman98@home.com>
using perl to rsync <luethke@msr.epm.ornl.gov>
Re: vec and bitwise or ? <lr@hpl.hp.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 9 May 2000 14:40:44 -0400
From: Brad Baxter <bmb@ginger.libs.uga.edu>
Subject: Split and "null delimiter" (was: BEGIN and use)
Message-Id: <Pine.A41.4.10.10005091409180.8776-100000@ginger.libs.uga.edu>
On Tue, 9 May 2000, Brad Baxter wrote:
> On the other hand, why wouldn't there be 7 elements in the array:
>
> @a = split //, 'abc';
I wasn't being serious when I first wrote this, but then I started
wondering about it. I reread the docs for split. Now I have this
example to ask about:
1 #!/usr/local/bin/perl -w
2 use strict;
3
4 my @a;
5 sub p { print scalar @_, " |", join( "|", @_ ), "|\n" }
6
7 @a = split //, 'abc'; p @a; # 3 |a|b|c|
8 @a = split /-/, '-a-b-c-'; p @a; # 4 ||a|b|c|
9
10 @a = split //, 'abc', -1; p @a; # 4 |a|b|c||
11 @a = split /-/, '-a-b-c-', -1; p @a; # 5 ||a|b|c||
12
13 @a = split /()/, 'abc'; p @a; # 5 |a||b||c|
14 @a = split /(-)/, '-a-b-c-'; p @a; # 8 ||-|a|-|b|-|c|-|
15
16 @a = split /()/, 'abc', -1; p @a; # 7 |a||b||c|||
17 @a = split /(-)/, '-a-b-c-', -1; p @a; # 9 ||-|a|-|b|-|c|-||
(This is perl, version 5.005_03)
I'm not sure I follow why a "null delimiter" is treated differently
than a non-null delimiter in every case. In particular, lines 10 and
16 show that a null delimiter was recognized after the 'c' but not
before the 'a'. Hmmmm.
1 #!/usr/local/bin/perl -w
2 use strict;
3
4 $_ = 'abc';
5 my ( $x, $y, $z ) = /( *)(abc)( *)/;
6 print defined( $_ ), "\n" for $x, $y, $z;
7 print "{$x} {$y} {$z}\n";
Output:
1
1
1
{} {abc} {}
This code simply shows that a null string is matched both at the
beginning and at the end of a string.
--
Brad
------------------------------
Date: Tue, 09 May 2000 19:06:05 GMT
From: Ala Qumsieh <aqumsieh@hyperchip.com>
Subject: Re: Split and "null delimiter" (was: BEGIN and use)
Message-Id: <7aya5jr1b6.fsf@Merlin.i-did-not-set--mail-host-address--so-shoot-me>
Brad Baxter <bmb@ginger.libs.uga.edu> writes:
> 1 #!/usr/local/bin/perl -w
> 2 use strict;
> 3
> 4 my @a;
> 5 sub p { print scalar @_, " |", join( "|", @_ ), "|\n" }
> 6
> 7 @a = split //, 'abc'; p @a; # 3 |a|b|c|
This splits on the null pattern, which matches in between characters. So
you get a list of your characters returned.
> 8 @a = split /-/, '-a-b-c-'; p @a; # 4 ||a|b|c|
This splits on a minus sign. split() returns whatever it finds between
consecutive patterns while taking into account the beginning/ending of
the string. Since the first minus sign occurs as the first character,
split() returns what is between the first character and the beginning of
the string; which is null.
Note that there is also a trailing null field, between the last minus
sign, and the end of the string. But, by default, split() preserves
empty leading fields, and deletes empty trailing fields.
> 9
> 10 @a = split //, 'abc', -1; p @a; # 4 |a|b|c||
perldoc -f split
....
If LIMIT is negative, it is
treated as if an arbitrarily large LIMIT had been specified.
....
> 11 @a = split /-/, '-a-b-c-', -1; p @a; # 5 ||a|b|c||
Same as above.
> 12
> 13 @a = split /()/, 'abc'; p @a; # 5 |a||b||c|
This acts like line 7, but captures the nulls in between the characters,
and returns them.
> 14 @a = split /(-)/, '-a-b-c-'; p @a; # 8 ||-|a|-|b|-|c|-|
Same as above.
> 15
> 16 @a = split /()/, 'abc', -1; p @a; # 7 |a||b||c|||
This is a tricky one. I can sort of see why split() returns two nulls at
the end, but it's not very obvious. When the split() reaches the end of
the string, it just found the 'c', so it returns it along with the null
(due to the brackets in the pattern). Due to the -1 limit, split() will
return one more null field.
> 17 @a = split /(-)/, '-a-b-c-', -1; p @a; # 9 ||-|a|-|b|-|c|-||
Same as above.
> (This is perl, version 5.005_03)
>
> I'm not sure I follow why a "null delimiter" is treated differently
> than a non-null delimiter in every case. In particular, lines 10 and
> 16 show that a null delimiter was recognized after the 'c' but not
> before the 'a'. Hmmmm.
It is not exactly trivial, but I hope I have somewhat helped you.
> 1 #!/usr/local/bin/perl -w
> 2 use strict;
> 3
> 4 $_ = 'abc';
> 5 my ( $x, $y, $z ) = /( *)(abc)( *)/;
> 6 print defined( $_ ), "\n" for $x, $y, $z;
> 7 print "{$x} {$y} {$z}\n";
>
> Output:
>
> 1
> 1
> 1
> {} {abc} {}
>
> This code simply shows that a null string is matched both at the
> beginning and at the end of a string.
Yep. Nulls also match in between characters:
#!/usr/bin/perl -wl
use strict;
$_ = 'abc';
my @x = /( *)(.)( *)(.)( *)(.)( *)/;
print join '|' => @x;
__END__
|a||b||c|
--Ala
------------------------------
Date: Tue, 9 May 2000 15:52:25 -0400
From: Brad Baxter <bmb@ginger.libs.uga.edu>
Subject: Re: Split and "null delimiter" (was: BEGIN and use)
Message-Id: <Pine.A41.4.10.10005091534470.8776-100000@ginger.libs.uga.edu>
On Tue, 9 May 2000, Ala Qumsieh wrote:
>
> Brad Baxter <bmb@ginger.libs.uga.edu> writes:
>
> > 1 #!/usr/local/bin/perl -w
> > 2 use strict;
> > 3
> > 4 my @a;
> > 5 sub p { print scalar @_, " |", join( "|", @_ ), "|\n" }
> > 6
> > 7 @a = split //, 'abc'; p @a; # 3 |a|b|c|
>
> This splits on the null pattern, which matches in between characters. So
> you get a list of your characters returned.
Also before leading and after trailing characters.
> > 8 @a = split /-/, '-a-b-c-'; p @a; # 4 ||a|b|c|
>
> This splits on a minus sign. split() returns whatever it finds between
> consecutive patterns while taking into account the beginning/ending of
> the string. Since the first minus sign occurs as the first character,
> split() returns what is between the first character and the beginning of
> the string; which is null.
>
> Note that there is also a trailing null field, between the last minus
> sign, and the end of the string. But, by default, split() preserves
> empty leading fields, and deletes empty trailing fields.
True, but why didn't it preserve the leading field in line 7 above. As in
the regexp's below, // should match the null string in front of the 'a'.
> > 9
> > 10 @a = split //, 'abc', -1; p @a; # 4 |a|b|c||
>
> perldoc -f split
>
> ....
> If LIMIT is negative, it is
> treated as if an arbitrarily large LIMIT had been specified.
> ....
>
> > 11 @a = split /-/, '-a-b-c-', -1; p @a; # 5 ||a|b|c||
>
> Same as above.
... which is why I used it. It clearly shows that split is matching the
null string after the 'c', but not before the 'a'.
> > 12
> > 13 @a = split /()/, 'abc'; p @a; # 5 |a||b||c|
>
> This acts like line 7, but captures the nulls in between the characters,
> and returns them.
... and does *not* preserve the leading field as it does in line 14 below.
> > 14 @a = split /(-)/, '-a-b-c-'; p @a; # 8 ||-|a|-|b|-|c|-|
>
> Same as above.
>
> > 15
> > 16 @a = split /()/, 'abc', -1; p @a; # 7 |a||b||c|||
>
> This is a tricky one. I can sort of see why split() returns two nulls at
> the end, but it's not very obvious. When the split() reaches the end of
> the string, it just found the 'c', so it returns it along with the null
> (due to the brackets in the pattern). Due to the -1 limit, split() will
> return one more null field.
>
> > 17 @a = split /(-)/, '-a-b-c-', -1; p @a; # 9 ||-|a|-|b|-|c|-||
>
> Same as above.
... and again, the leading field is preserved in one case but not the
other.
> > (This is perl, version 5.005_03)
> >
> > I'm not sure I follow why a "null delimiter" is treated differently
> > than a non-null delimiter in every case. In particular, lines 10 and
> > 16 show that a null delimiter was recognized after the 'c' but not
> > before the 'a'. Hmmmm.
>
> It is not exactly trivial, but I hope I have somewhat helped you.
Actually, as hinted in an earlier post, perhaps splitting nulls is the
height of triviality. :-)
> > 1 #!/usr/local/bin/perl -w
> > 2 use strict;
> > 3
> > 4 $_ = 'abc';
> > 5 my ( $x, $y, $z ) = /( *)(abc)( *)/;
> > 6 print defined( $_ ), "\n" for $x, $y, $z;
> > 7 print "{$x} {$y} {$z}\n";
> >
> > Output:
> >
> > 1
> > 1
> > 1
> > {} {abc} {}
> >
> > This code simply shows that a null string is matched both at the
> > beginning and at the end of a string.
>
> Yep. Nulls also match in between characters:
>
> #!/usr/bin/perl -wl
> use strict;
>
> $_ = 'abc';
> my @x = /( *)(.)( *)(.)( *)(.)( *)/;
> print join '|' => @x;
> __END__
> |a||b||c|
1 #!/usr/local/bin/perl -w
2 use strict;
3
4 $_ = 'abc';
5 my @x = /( *)(.)( *)(.)( *)(.)( *)/;
6 print '|', join( '|' => @x ), '|';
7 __END__
8 ||a||b||c||
Compare this to the output from the original line 16:
16 @a = split /()/, 'abc', -1; p @a; # 7 |a||b||c|||
Not exactly the same, but demonstrative of the mysteriously disappearing
leading fields.
This is fun, but it is pointless? :-)
--
Brad
------------------------------
Date: Tue, 09 May 2000 20:25:35 GMT
From: Ala Qumsieh <aqumsieh@hyperchip.com>
Subject: Re: Split and "null delimiter" (was: BEGIN and use)
Message-Id: <7avh0nqxmt.fsf@Merlin.i-did-not-set--mail-host-address--so-shoot-me>
Brad Baxter <bmb@ginger.libs.uga.edu> writes:
> On Tue, 9 May 2000, Ala Qumsieh wrote:
> >
> > Brad Baxter <bmb@ginger.libs.uga.edu> writes:
> >
> > > 1 #!/usr/local/bin/perl -w
> > > 2 use strict;
> > > 3
> > > 4 my @a;
> > > 5 sub p { print scalar @_, " |", join( "|", @_ ), "|\n" }
> > > 6
> > > 7 @a = split //, 'abc'; p @a; # 3 |a|b|c|
> >
> > This splits on the null pattern, which matches in between characters. So
> > you get a list of your characters returned.
>
> Also before leading and after trailing characters.
Correct. I mentioned this later on.
> > > 8 @a = split /-/, '-a-b-c-'; p @a; # 4 ||a|b|c|
> >
> > This splits on a minus sign. split() returns whatever it finds between
> > consecutive patterns while taking into account the beginning/ending of
> > the string. Since the first minus sign occurs as the first character,
> > split() returns what is between the first character and the beginning of
> > the string; which is null.
> >
> > Note that there is also a trailing null field, between the last minus
> > sign, and the end of the string. But, by default, split() preserves
> > empty leading fields, and deletes empty trailing fields.
>
> True, but why didn't it preserve the leading field in line 7 above. As in
> the regexp's below, // should match the null string in front of the 'a'.
If there are no parentheses in the pattern of split(), then split() will
return whatever is between what is matched by the patterns. In
above, the beginning of the string matches the null pattern. But split()
doesn't start from there. It starts from the first character of the
string. In fact, the first time the pattern is matched is between the
'a' and the 'b'. So the 'a' will be the first element to be returned.
> > > 9
> > > 10 @a = split //, 'abc', -1; p @a; # 4 |a|b|c||
> >
> > perldoc -f split
> >
> > ....
> > If LIMIT is negative, it is
> > treated as if an arbitrarily large LIMIT had been specified.
> > ....
> >
> > > 11 @a = split /-/, '-a-b-c-', -1; p @a; # 5 ||a|b|c||
> >
> > Same as above.
>
> ... which is why I used it. It clearly shows that split is matching the
> null string after the 'c', but not before the 'a'.
There is a null field before the 'a' as the output that you show (in
comments) suggest. I don't understand what you mean there.
> > > 12
> > > 13 @a = split /()/, 'abc'; p @a; # 5 |a||b||c|
> >
> > This acts like line 7, but captures the nulls in between the characters,
> > and returns them.
>
> ... and does *not* preserve the leading field as it does in line 14 below.
>
> > > 14 @a = split /(-)/, '-a-b-c-'; p @a; # 8 ||-|a|-|b|-|c|-|
> >
> > Same as above.
> >
> > > 15
> > > 16 @a = split /()/, 'abc', -1; p @a; # 7 |a||b||c|||
> >
> > This is a tricky one. I can sort of see why split() returns two nulls at
> > the end, but it's not very obvious. When the split() reaches the end of
> > the string, it just found the 'c', so it returns it along with the null
> > (due to the brackets in the pattern). Due to the -1 limit, split() will
> > return one more null field.
> >
> > > 17 @a = split /(-)/, '-a-b-c-', -1; p @a; # 9 ||-|a|-|b|-|c|-||
> >
> > Same as above.
>
>
> ... and again, the leading field is preserved in one case but not the
> other.
Ok. I see where you are confused. I am not an expert in the internals of
how split() works, but I think I know how. Maybe some other guru can
correct me on this.
split() starts scanning from the first character of the string. Once it
finds a match for its pattern, it returns whatever it found between this
match and the previous one. If this is its first match, it returns
whatever is before its current position.
So, for the case of 16 above, split() starts from 'a', and hits the word
boundary between the 'a' and 'b', which is its first match. It then
returns 'a', and continues from where it stopped.
In the case of 17, split() starts from '-' which matches the pattern, so
it returns whatever is before it, which is null. Then it contiues.
> > > (This is perl, version 5.005_03)
> > >
> > > I'm not sure I follow why a "null delimiter" is treated differently
> > > than a non-null delimiter in every case. In particular, lines 10 and
> > > 16 show that a null delimiter was recognized after the 'c' but not
> > > before the 'a'. Hmmmm.
> >
> > It is not exactly trivial, but I hope I have somewhat helped you.
>
> Actually, as hinted in an earlier post, perhaps splitting nulls is the
> height of triviality. :-)
Even trivial things can be very confusing, especially after a couple of
beers :-)
> > > 1 #!/usr/local/bin/perl -w
> > > 2 use strict;
> > > 3
> > > 4 $_ = 'abc';
> > > 5 my ( $x, $y, $z ) = /( *)(abc)( *)/;
> > > 6 print defined( $_ ), "\n" for $x, $y, $z;
> > > 7 print "{$x} {$y} {$z}\n";
> > >
> > > Output:
> > >
> > > 1
> > > 1
> > > 1
> > > {} {abc} {}
> > >
> > > This code simply shows that a null string is matched both at the
> > > beginning and at the end of a string.
> >
> > Yep. Nulls also match in between characters:
> >
> > #!/usr/bin/perl -wl
> > use strict;
> >
> > $_ = 'abc';
> > my @x = /( *)(.)( *)(.)( *)(.)( *)/;
> > print join '|' => @x;
> > __END__
> > |a||b||c|
>
>
> 1 #!/usr/local/bin/perl -w
> 2 use strict;
> 3
> 4 $_ = 'abc';
> 5 my @x = /( *)(.)( *)(.)( *)(.)( *)/;
> 6 print '|', join( '|' => @x ), '|';
> 7 __END__
> 8 ||a||b||c||
>
> Compare this to the output from the original line 16:
>
> 16 @a = split /()/, 'abc', -1; p @a; # 7 |a||b||c|||
>
> Not exactly the same, but demonstrative of the mysteriously disappearing
> leading fields.
This is because in this case, we explicitly asked for a match of the
leading null. But in line 16, we used split() which starts from the first
character of the string.
> This is fun, but it is pointless? :-)
Perl Golf is fun, but is it pointless? ;-)
--Ala
------------------------------
Date: 9 May 2000 20:59:51 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Split and "null delimiter" (was: BEGIN and use)
Message-Id: <8f9u87$2jj$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Brad Baxter
<bmb@ginger.libs.uga.edu>],
who wrote in article <Pine.A41.4.10.10005091409180.8776-100000@ginger.libs.uga.edu>:
> I'm not sure I follow why a "null delimiter" is treated differently
> than a non-null delimiter in every case.
Do not try to use split() except as in simplest possible situations,
or if you are absolutely sure you understand all the tiny
ramifications of the current API.
split() is an abomination. This is a very educative example what a
mindless application of DWIM principle leads to: you cannot reliably
predict how your program will behave.
I sent a patch for something like
use split 'strict';
which would replace the current API by a simple API, an API which
could be documented without three "except" in each sentence. People
know what happened to this patch.
Ilya
------------------------------
Date: Tue, 9 May 2000 17:59:18 -0400
From: Brad Baxter <bmb@ginger.libs.uga.edu>
Subject: Re: Split and "null delimiter" (was: BEGIN and use)
Message-Id: <Pine.A41.4.10.10005091747570.8776-100000@ginger.libs.uga.edu>
On Tue, 9 May 2000, Ala Qumsieh wrote:
...
> Ok. I see where you are confused. I am not an expert in the internals of
> how split() works, but I think I know how. Maybe some other guru can
> correct me on this.
>
> split() starts scanning from the first character of the string. Once it
> finds a match for its pattern, it returns whatever it found between this
> match and the previous one. If this is its first match, it returns
> whatever is before its current position.
>
> So, for the case of 16 above, split() starts from 'a', and hits the word
> boundary between the 'a' and 'b', which is its first match. It then
> returns 'a', and continues from where it stopped.
from perldoc -f split:
A pattern matching the null string (not to be confused
with a null pattern `//', which is just one member of
the set of patterns matching a null string) will split
the value of EXPR into separate characters at each point
it matches that way. For example:
I took "at each point it matches that way" to mean that it would be
analogous to a regular expression match, which starts at the null
string in front of the first character.
Perhaps this is best explained by Ilya's statement, "split() is an abomination."
I'll accept that :-) Time for that beer.
Thanks,
--
Brad
------------------------------
Date: Tue, 9 May 2000 18:01:12 -0400
From: Brad Baxter <bmb@ginger.libs.uga.edu>
Subject: Re: Split and "null delimiter" (was: BEGIN and use)
Message-Id: <Pine.A41.4.10.10005091759300.8776-100000@ginger.libs.uga.edu>
On 9 May 2000, Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to Brad Baxter
> <bmb@ginger.libs.uga.edu>],
> who wrote in article <Pine.A41.4.10.10005091409180.8776-100000@ginger.libs.uga.edu>:
>
> > I'm not sure I follow why a "null delimiter" is treated differently
> > than a non-null delimiter in every case.
>
> Do not try to use split() except as in simplest possible situations,
> or if you are absolutely sure you understand all the tiny
> ramifications of the current API.
>
> split() is an abomination. This is a very educative example what a
> mindless application of DWIM principle leads to: you cannot reliably
> predict how your program will behave.
>
> I sent a patch for something like
>
> use split 'strict';
>
> which would replace the current API by a simple API, an API which
> could be documented without three "except" in each sentence. People
> know what happened to this patch.
>
> Ilya
I can accept that. Thanks for the advice. :-)
--
Brad
------------------------------
Date: Tue, 09 May 2000 18:24:25 GMT
From: Ala Qumsieh <aqumsieh@hyperchip.com>
Subject: Re: Syntax for passing parameters from command line, then interpreting them?
Message-Id: <7a1z3bsht1.fsf@Merlin.i-did-not-set--mail-host-address--so-shoot-me>
"Sean Scannell" <news@access-management.com> writes:
> I found examples of passing parameters to a subroutine, and passing file
> names using argv, but not straight passing of parameters from a command
> line. GetOpts looks like overkill.
They are not really overkill. But, personally, I don't use them. The
reason is that I developped my own Parse::Args module that I think is
cuter, and more useful.
> I figured passing :
>
> Test.pl -parm1 - parm2
>
> Then interpreting
>
> $str1 = @_[0];
> $str2 = @_[1];
>
> but I guess I have it wrong.
Command line arguments automagically appear in the @ARGV array, not in
@_. Moreover, you are not accessing the individual elements of the array
correctly:
my $arg1 = $ARGV[0];
my $arg2 = $ARGV[1];
Note that I used '$', not '@', as the prefix of ARGV. If you don't
understand why, then checkout perlfaq4:
What is the difference between $array[1] and @array[1]?
--Ala
------------------------------
Date: Tue, 9 May 2000 16:27:56 -0500
From: "spurcell" <skpurcell@hotmail.com>
Subject: system(@args) command
Message-Id: <391882c5$0$25103@wodc7nh1.news.uu.net>
Hello,
I am still a rookie, and have picked up some code that has the following
syntax in it.
system(@args);
# where @args is a large string (for Blat email, consisting of c:\blat
filetoget -t someone@bla blat bla);
Anyway, I see that they are calling Blat in this @args array and all the
other stuff that blat needs to send a file.
My question:
I am thinking that system(@args) should return either a true or false, or a
1 or 0. I don't like the way it is just hanging there with no checks whether
it was successful or not.
Does anyone have a good way of checking if this was good or bad?
Thanks
Scott
------------------------------
Date: 9 May 2000 21:36:35 GMT
From: abigail@foad.org (Abigail)
Subject: Re: trying to access elements of a scalar variable
Message-Id: <slrn8hh173.efl.abigail@ucan.foad.org>
On Wed, 26 Apr 2000 10:14:37 -0700, Larry Rosler <lr@hpl.hp.com> wrote:
++ In article <87itx4kf43.fsf@shleppie.uh.edu> on 26 Apr 2000 11:21:16 -
++ 0500, Tony Curtis <tony_curtis32@yahoo.com> says...
++ > >> On Wed, 26 Apr 2000 12:17:53 -0400,
++ > >> "Martin Trautmann" <matst90@katz.pitt.edu> said:
++ >
++ > > hi, i'm trying to access a specific character (the first
++ > > one) of a scalar variable. i don't really want to use
++ > > chop several times till i have it...
++ >
++ > perldoc -f substr
++ > perldoc perlre
++
++ But he could also do 'chop reverse $scalar', as he doesn't seem to mind
++ using 'chop several times'. One chop will do it. :-)
++
++ I recall from some benchmarks posted here a while ago that that was the
++ fastest approach of all, believe it or not!
That would be very odd, as reverse doesn't return an lvalue, and hence
the approach wouldn't work at all. Furthermore, reverse would have a
run time linear in the size of the argument, while chop() ought to have
a constant time running time.
Abigail
------------------------------
Date: Tue, 09 May 2000 19:57:19 GMT
From: JagMan <jagman98@home.com>
Subject: Unix command as other user
Message-Id: <39186E6D.A0E268F5@home.com>
How do I execute unix command as user joe in perl? I am running perl
with root id.
Example: this is a user joe with preloaded env vars.
JOE_HOME=/home/joe
JOE_BIN=/home/joe/bin
$> su - joe
% joe > connect
% joe > search object objx
name type
objx PC
% joe > disconnect
How do I sudo to user joe and run multiple commands without loosing
environment.
Thank in Advance.
Manny
------------------------------
Date: Tue, 9 May 2000 15:14:37 -0400
From: "Brian Luethke" <luethke@msr.epm.ornl.gov>
Subject: using perl to rsync
Message-Id: <8f9o1i$ps$1@sws1.ctd.ornl.gov>
hi, i am trying to use rsync to effeciently transfer files inside a perl
script. When the perl script is running iterativly everyhitng goes fine but
when i run a threaded version it hangs, this error is either caused by PERL
or by rsync and i can not determine which one. below is the code, i am using
perl 5.60. Rsync actually transfers the file but then hangs. temp_501_$ip is
small, not over 2 or three k. When i run ps -A it has rsync still running
and ssh( defunct ) in the process list ( same thing if i just use rsh so i
don't think it is ssh ). when i run netstat it shows the socket having a
time_wait flag. I have let this sit for a long time and it never finishes. I
have to go through and manually kill each process. I think i have done
something wrong in perl as the iterative version works.
#!/usr/bin/perl
use Thread;
#this works fine
$ip = "node2";
$command = "rsync -avz --rsh=ssh $ip:/tmp/temp_501_$ip $ENV{HOME}/temp_$ip";
system( $command );
$ip = "node3";
$command = "rsync -avz --rsh=ssh $ip:/tmp/temp_501_$ip $ENV{HOME}/temp_$ip";
system( $command );
#fails
$threads[0] = new Thread \&test, node2;
$threads[1] = new Thread \&test, node3;
sub test {
my $ip = $_[0];
#fails
my $command = "rsync -avz --rsh=ssh $ip:/tmp/temp_501_$ip
$ENV{HOME}/temp_$ip";
system( $command );
------------------------------
Date: Tue, 9 May 2000 11:31:07 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: vec and bitwise or ?
Message-Id: <MPG.1381f9487bd5429c98aa30@nntp.hpl.hp.com>
In article <Pine.GSO.4.10.10005090811110.3921-100000@user2.teleport.com>
on Tue, 9 May 2000 08:19:05 -0700, Tom Phoenix <rootbeer@redcat.com>
says...
...
> This may be a bug in perl; I'm not sure. Maybe I'm overlooking something.
> It looks to me as if vec() failed to clear out the (now-invalid) numeric
> value of $rin and $win. That means that perl thinks that you're doing a
> numeric (rather than bitwise) 'or' there. Worse, it's using the old values
> of 0 for both.
>
> If this still happens with 5.6.0, file a bug report with perlbug. Thanks!
I believe the situation is worse than you think.
This bug was *introduced* in 5.6.0. I filed a bug report ID
20000425.009, and got a response criticizing my characterization of its
severity as 'medium'. Evidently is is more severe than that, as it
leads to silent incorrect answers that were correct in previous
versions.
But I don't know what the current status is.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
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 2996
**************************************
