[23655] in Perl-Users-Digest
Perl-Users Digest, Issue: 5862 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 26 18:10:39 2003
Date: Wed, 26 Nov 2003 15:10:12 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 26 Nov 2003 Volume: 10 Number: 5862
Today's topics:
Re: Regex Question <krahnj@acm.org>
Re: Regex Question (Bill)
Re: Regex Question <xx087@freenet.carleton.ca>
Re: Regex Question <usenet@morrow.me.uk>
Re: rename hash-key ? <abigail@abigail.nl>
Repost - Set header in SOAP::Lite - how? (James Richardson)
Re: script works from prompt but not through telnet (Eric Lewton)
store password in a module ? (Qiang)
Re: store password in a module ? <nobull@mail.com>
Re: trying to understand fork and wait (John)
Re: trying to understand fork and wait <nobull@mail.com>
Re: trying to understand fork and wait <jwillmore@remove.adelphia.net>
Re: trying to understand fork and wait <usenet@morrow.me.uk>
Re: trying to understand fork and wait (Tad McClellan)
Re: trying to understand fork and wait (Tad McClellan)
Re: Unexpected tell() result <dwilga-MUNGE@mtholyoke.edu>
Re: Unexpected tell() result <nobull@mail.com>
Re: Unexpected tell() result <usenet@morrow.me.uk>
Re: Unexpected tell() result <nobull@mail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 26 Nov 2003 17:37:22 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: Regex Question
Message-Id: <3FC4E4CD.BE17CCA0@acm.org>
Chip wrote:
>
> I'm trying to parse the following :
>
> Customer[Smith,John]Type[New]Source[Phone]Phone[5551212]
>
> Since the brackets are metacharacters in perl I thought I
> could just escape them with the following:
>
> if (/Customer\[(.+),(.+)\]/) { # parse out values
> $last = $1;
> $first = $2;
> }
>
> But this does not work. How should I escape the '[' and ']'
> characters
You could always use a hash and do something like this:
$ perl -e'use Data::Dumper;
my $string = "Customer[Smith,John]Type[New]Source[Phone]Phone[5551212]";
my %data = map {
my $x;
/,/ ? { map { ( $x++ ? "First" : "Last" ), $_ } split /,/, $_, 2 }
: $_
} split /[\[\]]/, $string;
print Dumper( \%data );
'
$VAR1 = {
'Customer' => {
'Last' => 'Smith',
'First' => 'John'
},
'Phone' => '5551212',
'Source' => 'Phone',
'Type' => 'New'
};
:-)
John
--
use Perl;
program
fulfillment
------------------------------
Date: 26 Nov 2003 11:09:52 -0800
From: wherrera@lynxview.com (Bill)
Subject: Re: Regex Question
Message-Id: <239ce42f.0311261109.19e1a5e@posting.google.com>
Glenn Jackman <xx087@freenet.carleton.ca> wrote in message news:<slrnbs9e0l.cfe.xx087@smeagol.ncf.ca>...
>
> my $s = 'Customer[Smith,John]Type[New]Source[Phone]Phone[5551212]';
>
> You might also try:
> my %data = split /[][]/, $s;
> my ($last, $first) = split /,/, $data{Customer};
I am a bit surprised by this, since I would have written the regex
bracket expression like this:
/[\]\[]/
And would like to know why your way does not split on two empty
character classes?
Is this just Perl DWIW?
------------------------------
Date: 26 Nov 2003 19:44:40 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: Regex Question
Message-Id: <slrnbsa0ml.cfe.xx087@smeagol.ncf.ca>
Bill <wherrera@lynxview.com> wrote:
> Glenn Jackman <xx087@freenet.carleton.ca> wrote in message news:<slrnbs9e0l.cfe.xx087@smeagol.ncf.ca>...
> > my %data = split /[][]/, $s;
>
> I am a bit surprised by this, since I would have written the regex
> bracket expression like this:
>
> /[\]\[]/
>
> And would like to know why your way does not split on two empty
> character classes?
Because inside a character class, [ is not special, and if ] is the
first character (or second char if you want to negate the char.class
with ^), then it's the literal ] and not the end of the class.
--
Glenn Jackman
NCF Sysadmin
glennj@ncf.ca
------------------------------
Date: Wed, 26 Nov 2003 19:52:28 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Regex Question
Message-Id: <bq309s$eu5$2@wisteria.csv.warwick.ac.uk>
wherrera@lynxview.com (Bill) wrote:
> Glenn Jackman <xx087@freenet.carleton.ca> wrote in message
> news:<slrnbs9e0l.cfe.xx087@smeagol.ncf.ca>...
> >
> > my $s = 'Customer[Smith,John]Type[New]Source[Phone]Phone[5551212]';
> >
> > You might also try:
> > my %data = split /[][]/, $s;
> > my ($last, $first) = split /,/, $data{Customer};
>
> I am a bit surprised by this, since I would have written the regex
> bracket expression like this:
>
> /[\]\[]/
>
> And would like to know why your way does not split on two empty
> character classes?
> Is this just Perl DWIW?
Well... if ] is the first thing after a [, it is taken a part of the
class rather than as closing it. It wouldn't work with, say, /[[]]/,
which matches [ followed by ].
Ben
--
If you put all the prophets, | You'd have so much more reason
Mystics and saints | Than ever was born
In one room together, | Out of all of the conflicts of time.
ben@morrow.me.uk |----------------+---------------| The Levellers, 'Believers'
------------------------------
Date: 26 Nov 2003 23:01:13 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: rename hash-key ?
Message-Id: <slrnbsac5p.gqd.abigail@alexandra.abigail.nl>
Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMDCCXXXIX
September MCMXCIII in <URL:news:bq2bov$eo5$2@mamenchi.zrz.TU-Berlin.DE>:
''
'' The order of hash keys is unpredictable. It is still unpredictable after
'' the operation.
While the order of hash keys is unpredictable, it's *documented* to
be *repeatable* if you don't modify the hash.
If the order wasn't repeatable, then
@keys = keys %hash;
@values = values %hash;
no longer will match up.
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
.qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
.qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'
------------------------------
Date: 26 Nov 2003 00:36:15 -0800
From: james@time4tea.demon.co.uk (James Richardson)
Subject: Repost - Set header in SOAP::Lite - how?
Message-Id: <274f94c.0311260036.680c1164@posting.google.com>
Hiya,
I'm using SOAP::Lite to try to access a SOAP server. In order to call
some functions, I need to set a header attribute to an authorization
token, but I can't for the life of me work out how to do it!
Heres the code:
my $soap = SOAP::Lite->new();
$soap->proxy ("http://" . $self->getHost() . ":" .
$self->getPort() . $self->getEndpoint() );
$soap->uri ( $self->getUri() );
Debug ( 4, "Calling $method" );
my $soap_response;
eval {
# Need to $soap->set_header ( "foo" => "bar" ) here...
$soap_response = $soap->call( $method => @args );
}
......
Would much appreciate any help!!!!
Thanks!
James
------------------------------
Date: 26 Nov 2003 11:30:04 -0800
From: lewtone@myfastmail.com (Eric Lewton)
Subject: Re: script works from prompt but not through telnet
Message-Id: <3df67682.0311261130.4b019a61@posting.google.com>
Great, that was it exactly, thanks guys.
There are some pretty weird shenanigans going on.
------------------------------
Date: 26 Nov 2003 09:32:46 -0800
From: shijialee@hotmail.com (Qiang)
Subject: store password in a module ?
Message-Id: <b1f13455.0311260932.132644ff@posting.google.com>
hello,
i have a module connect to a database and return some information for
user. the database name and password are stored in it.
now the user will run another perl file which use the module. however,
i don't know how do i pretect the database password from user?
i heard about setuid, but it seems to have it's own security problem.
can anyone recommend elegant way to solve this problem ?
thanks !
James.Q.L
------------------------------
Date: 26 Nov 2003 17:50:16 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: store password in a module ?
Message-Id: <u9he0rdnon.fsf@wcl-l.bham.ac.uk>
shijialee@hotmail.com (Qiang) writes:
> i have a module connect to a database and return some information for
> user. the database name and password are stored in it.
>
> now the user will run another perl file which use the module. however,
> i don't know how do i pretect the database password from user?
Aggghhhhh! Didn't we have this thread already this week.
> i heard about setuid, but it seems to have it's own security problem.
>
> can anyone recommend elegant way to solve this problem ?
This is the perpetual motion machine of computer programming.
It has very little to do with the specific lanuage.
You cannot do this with a module or library that loads into the
user-space of your program. Some operating systems (eg VMS) have a
concept of a priviledged library that you can call rather like an OS
call. (IIRC Solaris has something called "doors" which may apply).
In general the only way to do it is a helper process. The helper
process runs under a different UID an accepts connections from clients
(using a UNIX domain socket or whatever) and forwards them to the
database.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 26 Nov 2003 09:43:11 -0800
From: jguad98@hotmail.com (John)
Subject: Re: trying to understand fork and wait
Message-Id: <a964da31.0311260943.ec5a2ef@posting.google.com>
Commentary from various posters:
>
> I surely _did_ imply however that you are not yet making the best
> use of the std docs.
>
> The docs for $! in perlvar.pod for instance, describe when the
> value of the variable is meaningless.
>
>
>
> Good programmers don't need to know everything, they just need to
> know where to go to find out anything that they need to know.
>
> The docs that came with the software you are using are pretty
> much universally a good first place to try.
>> > So did you then read the docs for fork() ?
>>
>> Yes, and I saw nothing new from when I read the docs before. It's
>> that whole issue with the doco being farking vague and incomplete
> The documentation for fork states quite explicitly in the first
> paragraph what fork returns. I take it you realise that 0 is false?
>> I did not know that "$!" could have a "stale" message ...
>
> Again, it says so quite clearly in perlvar under $!.
>
>>... I'm learning as I'm doing.
>
>*How* are you learning by doing?
>
back to square one ... I'm not a programmer. Until I started
researching "fork" in this newsgroup, I didn't even know of the
existance of "perldoc" and still don't know which terms can only be
looked up with "perldoc -f [term]" versus "perldoc [term]". And then
there's some terms that can be looked up with both "man" and
"perldoc", and may be described differently and I don't necessarily
know which description is the one that is "true" for my purposes
(especially when books and other newsgroup postings actually refer to
man instead of perldoc!).
My complaint about farking vague doco is precisely and exactly about
the perldoc for fork ... if you refer back to all the questions I was
asking in my first 2 posts this thread, you will see that none of
those questions were expressly or explicitly answered in the perldoc;
it took explanation from somebody with experience in the subject to
actually answer my questions.
So ... I muddle along, write Perl in the primitive manner that I know
and turn to the doco only if I need understanding on a function that
is not working as expected or if I need a new function to do work that
I don't know how to do otherwise -- hence my investigation into fork
and wait. I didn't read up on die as I did not see it as important
(my error), and now I am fairly certain that I will not be using it on
a regular basis. I'm still wary of the logic behind the fact that die
is invoked via a truth test (if not true then die or whatever) ... I
am not interested in testing the 'truth' of an operation, only in
testing the success or failure of an operation. Am I crazy, or just
not 'Perlish' enough?
ANYWAY ... thanks ... y'all have been helpful.
------------------------------
Date: 26 Nov 2003 19:00:20 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: trying to understand fork and wait
Message-Id: <u93ccbdkfv.fsf@wcl-l.bham.ac.uk>
jguad98@hotmail.com (John) writes:
> ...[I] still don't know which terms can only be
> looked up with "perldoc -f [term]" versus "perldoc [term]".
perldoc perldoc
> And then there's some terms that can be looked up with both "man"
> and "perldoc", and may be described differently and I don't
> necessarily know which description is the one that is "true" for my
> purposes (especially when books and other newsgroup postings
> actually refer to man instead of perldoc!).
Some or all of the perldoc pages get mirrored into the "man" system.
I always stick to perldoc for Perl.
>I'm still wary of the logic behind the fact that die
> is invoked via a truth test (if not true then die or whatever) ... I
> am not interested in testing the 'truth' of an operation, only in
> testing the success or failure of an operation.
In many computer languages operations that can fail often indicate
whether or not they have done so by returning a value that can be
treated as true/false. Usually true means they succeded and false
means they failed. Note that in many languages a zero is treated as
false and a non zero number is treated as false - this is however not
universally the case (in Bourne shell for example it's the other way).
> Am I crazy, or just not 'Perlish' enough?
I don't think it's specifically Perlishness you lack. Your mindset
would be equally alien in C, Pascal, Bourne shell or any language in
which exceptions were not the normal way to report a failure.
Note that Perl does use exceptions (die) too. If you try to fork on a
platform on which fork is not implemented it will report this failure
using an exception rather than an error code.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Wed, 26 Nov 2003 19:24:17 GMT
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: trying to understand fork and wait
Message-Id: <20031126142416.0aa35750.jwillmore@remove.adelphia.net>
On 26 Nov 2003 09:43:11 -0800
jguad98@hotmail.com (John) wrote:
> back to square one ... I'm not a programmer. Until I started
> researching "fork" in this newsgroup, I didn't even know of the
> existance of "perldoc" and still don't know which terms can only be
> looked up with "perldoc -f [term]" versus "perldoc [term]". And
> then there's some terms that can be looked up with both "man" and
> "perldoc", and may be described differently and I don't necessarily
> know which description is the one that is "true" for my purposes
> (especially when books and other newsgroup postings actually refer
> to man instead of perldoc!).
perldoc is a utility that is *portable*. Meaning, it can be used to
access Perl documentation on many platforms. man is a *NIX utility.
Perl is a portable language and the reason (I think) you're using it
versus the flurry of other languages out there. So, if you write a
script that runs on *NIX, you *should* be able to run it on, say,
Windows *without* having to alter the code. That's why it is
*suggested* that you use perldoc versus man to view the documentation.
But, you can do it either way.
Some who post here are not programmers by trade either. Most have no
desire to do much more than perform some task their boss wants done
and done quickly. So, you're not alone in that respect.
<snip>
> So ... I muddle along, write Perl in the primitive manner that I
> know and turn to the doco only if I need understanding on a function
> that is not working as expected or if I need a new function to do
> work that I don't know how to do otherwise -- hence my investigation
> into fork and wait. I didn't read up on die as I did not see it as
> important(my error), and now I am fairly certain that I will not be
> using it on a regular basis. I'm still wary of the logic behind the
> fact that die is invoked via a truth test (if not true then die or
> whatever) ... I am not interested in testing the 'truth' of an
> operation, only in testing the success or failure of an operation.
> Am I crazy, or just not 'Perlish' enough?
Truth is what *any* language tests for. Success/failure is just a
representation of truth in human terms. The machine sees only 1's and
0's (which, you probably already know, but just follow the logic for a
moment). It knows nothing about success or failure - just 1 or 0
(true or false - in mathmatical terms). So, in short, given the
choices of "crazy" or "Perlish", then "crazy" is the call - but I
don't think you are :-)
Just a suggestion - you may want to invest in a book if you're having
a tough go at the documentation. "Learning Perl" (O'Reilly) is a good
one. There are examples in the book to reinforce what the authors are
trying to show you. That is one failing, IMHO, of the documentation
that comes with Perl - no practical examples of what is being shown.
Not true in every case, but true enough IMHO to comment on.
Good luck to you in your future coding endeavors.
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
DeVries's Dilemma: If you hit two keys on the typewriter, the
one you don't want hits the paper.
------------------------------
Date: Wed, 26 Nov 2003 19:27:27 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: trying to understand fork and wait
Message-Id: <bq2uqv$dlr$1@wisteria.csv.warwick.ac.uk>
jguad98@hotmail.com (John) wrote:
> My complaint about farking vague doco is precisely and exactly about
> the perldoc for fork ... if you refer back to all the questions I was
> asking in my first 2 posts this thread, you will see that none of
> those questions were expressly or explicitly answered in the perldoc;
> it took explanation from somebody with experience in the subject to
> actually answer my questions.
I think the question of its return value is perfectly clear? I do not
see anything the least bit vague there. Your problem was actually with
'or': you had not realised that 0 was false, or you had not really
thought about it at all and just taken 'or die' as meaning 'shout if
this failed': something that it's easy to do when you're unfamiliar
with a language but which you should really resist the temptation to
do.
> turn to the doco only if I need understanding on a function that
> is not working as expected
This is the wrong order. You should *start* by reading the docs for
everything you use: especially in Perl, which has quite a few
non-obvious defaults.
> I didn't read up on die as I did not see it as important
> (my error), and now I am fairly certain that I will not be using it on
> a regular basis.
die had nothing to do with your problem. If your logic had been
fork or print "Fork failed!\n";
that would have been just as wrong. Do not let this put you off using
die: it is a pretty essential function. Also do not let this put you
off checking whether functions fail: that is a *must*.
> I'm still wary of the logic behind the fact that die
> is invoked via a truth test (if not true then die or whatever)
die is invoked however you invoke it: the truth test is your
'or'. What you wrote was exactly equivalent to
my $kid = fork;
if(not $kid) {
die "fork failed: $!";
}
whereas what you actually wanted was
my $kid = fork;
if(not defined $kid) {
die "fork failed: $!";
}
. I would suggest your next step is to read perldoc perlop.
> ... I
> am not interested in testing the 'truth' of an operation, only in
> testing the success or failure of an operation.
Unfortunately there is no one way to test for 'success' in Perl. Some
functions return undef if they fail, some return false, some return >
0, some throw an exception with die. The *only* way to find out what a
function will do if it fails is to read the docs: I do not know of any
instance of unclear documantation on this point. (If you find one,
please report it as a bug in the docs.) A lot of the time they fail by
returning false: this explains the prevalence of 'or die'; but this is
by no means universal.
This could be considered a misfeature of Perl, as opposed to a
language like, say, Java, where functions always fail in the same way
(throwing an exception); IMHO Perl usually fails in a 'useful' way,
once you know what it is.
> Am I crazy, or just not 'Perlish' enough?
Well... perhaps not used enough to Perl yet. C is the same, BTW, so
this is not in any way unique to Perl.
--
If I were a butterfly I'd live for a day, / I would be free, just blowing away.
This cruel country has driven me down / Teased me and lied, teased me and lied.
I've only sad stories to tell to this town: / My dreams have withered and died.
ben@morrow.me.uk <=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=> (Kate Rusby)
------------------------------
Date: Wed, 26 Nov 2003 15:57:43 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: trying to understand fork and wait
Message-Id: <slrnbsa8en.5tl.tadmc@magna.augustmail.com>
John <jguad98@hotmail.com> wrote:
> back to square one ... I'm not a programmer.
The docs teach how to use Perl, they do not teach how to program.
> My complaint about farking vague doco is precisely and exactly about
> the perldoc for fork ... if you refer back to all the questions I was
> asking in my first 2 posts this thread, you will see that none of
> those questions were expressly or explicitly answered in the perldoc;
And they shouldn't be answered in the std docs.
The std docs do not teach what forking is, it is assumed
that the programmer already knows that, its job it to tell you how
to do forking _using Perl_.
So, your complaint isn't really about the std docs, they are not
supposed to do what you need done (ie. teach what "forking" is).
> So ... I muddle along,
The docs are not at fault. Your background is at fault.
A trained programmer would know how forking works.
(There's nothing wrong with not being trained as a programmer.
Just don't blame the docs when the docs are not at fault.
)
> I'm still wary of the logic behind the fact that die
> is invoked via a truth test (if not true then die or whatever)
die() is a red herring. If you concentrate on that you will
miss the big lesson.
If you had used print() instead of die() you would have had the
same problem!
The problem was the with how the _or_ works, not how die() works.
> ... I
> am not interested in testing the 'truth' of an operation, only in
> testing the success or failure of an operation.
But the truthness of the return value is precisely how you detect
success or failure for many (most) Perl functions, so become
interested in testing the "truth" of return values.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 26 Nov 2003 15:59:51 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: trying to understand fork and wait
Message-Id: <slrnbsa8in.5tl.tadmc@magna.augustmail.com>
James Willmore <jwillmore@remove.adelphia.net> wrote:
> "Learning Perl" (O'Reilly) is a good
> one.
If you are already a programmer.
If you are not already a programmer, then this one might be
a better tutorial:
"Elements of Programming with Perl" by Andrew Johnson
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 26 Nov 2003 11:56:23 -0500
From: Dan Wilga <dwilga-MUNGE@mtholyoke.edu>
Subject: Re: Unexpected tell() result
Message-Id: <dwilga-MUNGE-1B901A.11562326112003@nap.mtholyoke.edu>
In article <3fc3e934@news.victoria.tc.ca>,
yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
> You've opend the file in append mode, so any write is supposed to go to
> the end of the file, whereever that happens to be. However, the size of
> the file could be changing due to another process, so the value of tell
> that you read at one moment doesn't really have any relation to where the
> data gets written.
My process is the only one writing to the file. It actually doesn't
matter if I reopen the file immediately after creating it or two days
later, the result is the same.
--
Dan Wilga dwilga-MUNGE@mtholyoke.edu
** Remove the -MUNGE in my address to reply **
------------------------------
Date: 26 Nov 2003 18:00:19 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: Unexpected tell() result
Message-Id: <u9brqzdn7w.fsf@wcl-l.bham.ac.uk>
Dan Wilga <dwilga-MUNGE@mtholyoke.edu> writes:
> Since the same version of Perl gives different results, I suspect a
> glibc bug. Can anyone confirm this?
Personally I'd expect the behaviour of tell() on a file handle that's
in append mode but to which the last operation was not a write() by
the current process to be undefined.
If the behaviour is undefined the fact that different libc give
different results does not imply that either has a bug.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Wed, 26 Nov 2003 19:02:51 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Unexpected tell() result
Message-Id: <bq2tcr$c03$1@wisteria.csv.warwick.ac.uk>
Brian McCauley <nobull@mail.com> wrote:
> Dan Wilga <dwilga-MUNGE@mtholyoke.edu> writes:
>
> > Since the same version of Perl gives different results, I suspect a
> > glibc bug. Can anyone confirm this?
>
> Personally I'd expect the behaviour of tell() on a file handle that's
> in append mode but to which the last operation was not a write() by
> the current process to be undefined.
>
> If the behaviour is undefined the fact that different libc give
> different results does not imply that either has a bug.
It seems that under glibc 2.3 a file opened in append mode will read
from the current file position, but writes always go to the end and do
not move that position. Even straight after a write, the file pointer
is still at the beginning: pointing at the next byte to be read.
Ben
--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] * ben@morrow.me.uk
------------------------------
Date: 26 Nov 2003 19:07:01 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: Unexpected tell() result
Message-Id: <u9u14rc5ka.fsf@wcl-l.bham.ac.uk>
Ben Morrow <usenet@morrow.me.uk> writes:
> Brian McCauley <nobull@mail.com> wrote:
> > Dan Wilga <dwilga-MUNGE@mtholyoke.edu> writes:
> >
> > > Since the same version of Perl gives different results, I suspect a
> > > glibc bug. Can anyone confirm this?
> >
> > Personally I'd expect the behaviour of tell() on a file handle that's
> > in append mode but to which the last operation was not a write() by
> > the current process to be undefined.
> >
> > If the behaviour is undefined the fact that different libc give
> > different results does not imply that either has a bug.
>
> It seems that under glibc 2.3 a file opened in append mode will read
> from the current file position, but writes always go to the end and do
> not move that position. Even straight after a write, the file pointer
> is still at the beginning: pointing at the next byte to be read.
Yeah, now you describe it that does sound like "the right thing". But
not so much so that all other behaviour could be considered "the wrong
thing".
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
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.
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 V10 Issue 5862
***************************************
