[33051] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4327 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Dec 13 11:09:18 2014

Date: Sat, 13 Dec 2014 08:09:05 -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           Sat, 13 Dec 2014     Volume: 11 Number: 4327

Today's topics:
        Both substitute and filter (Tim McDaniel)
    Re: Both substitute and filter <news@todbe.com>
    Re: Both substitute and filter (Tim McDaniel)
    Re: Both substitute and filter <gamo@telecable.es>
    Re: Both substitute and filter <m@rtij.nl.invlalid>
    Re: Both substitute and filter <gravitalsun@hotmail.foo>
    Re: Both substitute and filter <marc.girod@gmail.com>
    Re: Date procedure? <rweikusat@mobileactivedefense.com>
    Re: Date procedure? <tuxedo@mailinator.com>
    Re: Date procedure? (Seymour J.)
    Re: Date procedure? (Seymour J.)
    Re: Date procedure? <hjp-usenet3@hjp.at>
    Re: Dedup script is finished and works. Critiques? <rweikusat@mobileactivedefense.com>
    Re: Dedup script is finished and works. Critiques? (Seymour J.)
    Re: Latest version of "dedup", and questions on open fi <whynot@pozharski.name>
    Re: Latest version of "dedup", and questions on open fi <m@rtij.nl.invlalid>
    Re: Latest version of "dedup", and questions on open fi <see.my.sig@for.my.address>
    Re: Latest version of "dedup", and questions on open fi <news@todbe.com>
    Re: Latest version of "dedup", and questions on open fi <hjp-usenet3@hjp.at>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 12 Dec 2014 23:49:56 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Both substitute and filter
Message-Id: <m6fuv4$kj1$1@reader1.panix.com>

I keep asking about idiomatic / readable / concise / cool Perl, and
here's my latest question.

@sources = ("hi", "there", "TARGET23", "hello", "TARGETblarg", "world");
@results = ()
for each member of @sources
    if s/^TARGET// matched
        push onto @results the result of the s///
    else
        do nothing

Is there a better way of doing that than a loop like the above?
Here are my initial thoughts.

(1) The attempt
    my @results = map { s/^TARGET//r || () } @sources;
didn't work because s///r returns the value unchanged, and since
(in my test data and in the real application) there would be no null
string in @sources, "|| ()" never happens.

(2) A solution involving things like
    map { s/.../.../ || () }
(no r modifier) would, I believe, be flagged by Perl::Critic because
the map expression isn't supposed to modify the argument.

(3) Is
    my @results = map { /^TARGET/ ? s///r : () } @sources;
just too weird?

(4) Alas,
    @results = @sources;
    s/^TARGET// || delete $_ for @results;
errors with "delete argument is not a HASH or ARRAY element or slice
at local/test/132.pl line 7" -- $_ isn't quite enough of an alias to
each array element.

-- 
Tim McDaniel, tmcd@panix.com


------------------------------

Date: Fri, 12 Dec 2014 18:35:34 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: Both substitute and filter
Message-Id: <548BA5F6.9010007@todbe.com>

On 12/12/2014 15:49, Tim McDaniel wrote:> I keep asking about idiomatic / readable / concise / cool Perl, and
> here's my latest question.
>
> @sources = ("hi", "there", "TARGET23", "hello", "TARGETblarg", "world");
> @results = ()
> for each member of @sources
>      if s/^TARGET// matched
>          push onto @results the result of the s///
>      else
>          do nothing
>
> Is there a better way of doing that than a loop like the above?

I like and would probably use:

	foreach (@sources) { push @results, $_ if /^TARGET/; }


------------------------------

Date: Sat, 13 Dec 2014 04:53:25 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Both substitute and filter
Message-Id: <m6ggo5$lu5$1@reader1.panix.com>

In article <548BA5F6.9010007@todbe.com>, $Bill <news@todbe.com> wrote:
>On 12/12/2014 15:49, Tim McDaniel wrote:
>> I keep asking about idiomatic / readable / concise / cool Perl, and
>> here's my latest question.
>>
>> @sources = ("hi", "there", "TARGET23", "hello", "TARGETblarg", "world");
>> @results = ()
>> for each member of @sources
>>      if s/^TARGET// matched
>>          push onto @results the result of the s///
>>      else
>>          do nothing

I should have mentioned that I want the results to be

    @results = ("23", "blarg")

>> Is there a better way of doing that than a loop like the above?
>
>I like and would probably use:
>
>	foreach (@sources) { push @results, $_ if /^TARGET/; }

Doesn't fit the spec, because @results would get the unsubstituted
element of @sources.  That would actually be equivalent to

    @results = grep { /^TARGET/ } @sources;

But that does make me think of something: using (...) in the regexp
to get the part I want, instead of s/// to discard the part I don't want.

My first thought was

    @results = map { /^TARGET(.*)$/ || () } @sources;

But that produced (1, 1), because that causes the m// to be evaluated
in scalar context, which returns true or false.  (The trailing "$" on
the regexp is not needed, of course; I like to use them even in such
cases just as documentation that I really want to match the whole
pattern.  I've not tested it to know whether it helps efficiency
here.)

I tried this just wondering what it would do:

    @results = map { /^TARGET(.*)$/ } @sources;

and it worked!  It took me a minute to remember why the result wasn't
("", "", "23", "", "blarg", ""):

    If the "/g" option is not used, "m//" in list context returns a
    list consisting of the subexpressions matched by the parentheses
    in the pattern, i.e., ($1, $2, $3...).  (Note that here $1
    etc. are also set, ...)  When there are no parentheses in the
    pattern, the return value is the list "(1)" for success.  With or
    without parentheses, an empty list is returned upon failure.

So it's as if it returns
    ((), (), ("23"), (), ("blarg"), ())
which evaluates to the desired
    ("23", "blarg")

That's not bad, and I don't think it could be bettered.  Even the loop
would, I think, be no more clear.

-- 
Tim McDaniel, tmcd@panix.com


------------------------------

Date: Sat, 13 Dec 2014 09:10:16 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Both substitute and filter
Message-Id: <m6gs97$j70$1@speranza.aioe.org>

El 13/12/14 a las 00:49, Tim McDaniel escribió:
> I keep asking about idiomatic / readable / concise / cool Perl, and
> here's my latest question.
>
> @sources = ("hi", "there", "TARGET23", "hello", "TARGETblarg", "world");
> @results = ()
> for each member of @sources
>      if s/^TARGET// matched
>          push onto @results the result of the s///
>      else
>          do nothing
>
> Is there a better way of doing that than a loop like the above?
> Here are my initial thoughts.

Try this:

for my $i (@sources) {
	my $j = ($i =~ s/^TARGET//);
	if ($j){
		push @results, $i;	
	}	
}

or this:

for (@sources) {
	if (/^TARGET/){
		s/^TARGET//;
		push @results;
	}
}	

or this:

for (@sources) {
	s/^TARGET//;
	if ($^N){
		push @results;
	}	
}	

Untested, some will work better.
HTH

-- 
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance


------------------------------

Date: Sat, 13 Dec 2014 12:45:12 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Both substitute and filter
Message-Id: <8fltlb-ndq.ln1@news.rtij.nl>

On Fri, 12 Dec 2014 23:49:56 +0000, Tim McDaniel wrote:

> I keep asking about idiomatic / readable / concise / cool Perl, and
> here's my latest question.
> 
> @sources = ("hi", "there", "TARGET23", "hello", "TARGETblarg", "world");
> @results = ()
> for each member of @sources
>     if s/^TARGET// matched
>         push onto @results the result of the s///
>     else
>         do nothing
> 
> Is there a better way of doing that than a loop like the above?
> Here are my initial thoughts.

I might use something like (untested)

@results = map s/^TARGET//, grep /^TARGET, @sources;

or even

@results = map substr($_,6), grep /^TARGET, @sources;

I would write your solution 3) as

@results = map {/^TARGET(.*)/ ? $1 : ()}  @sources;

M4


------------------------------

Date: Sat, 13 Dec 2014 14:07:24 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Both substitute and filter
Message-Id: <m6ha5t$1u1h$1@news.ntua.gr>

On 13/12/2014 01:49, Tim McDaniel wrote:
> @sources = ("hi", "there", "TARGET23", "hello", "TARGETblarg", "world");
> @results = ()
> for each member of @sources
>      if s/^TARGET// matched
>          push onto @results the result of the s///
>      else
>          do nothing


use strict;
use warnings;

/^TARGET(.*)$(?{print "$^N\n"})/ for  qw/hi there TARGET23 hello 
TARGETblarg world/


------------------------------

Date: Sat, 13 Dec 2014 07:18:20 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Both substitute and filter
Message-Id: <ecf54e37-8d44-4e3b-bff6-77c0575e971e@googlegroups.com>

~> perl -le 'push @r, grep {s/^TARGET//} @s=qw(hi there TARGET23 hello TARGETblarg world);print for @r'
23
blarg


------------------------------

Date: Thu, 11 Dec 2014 14:48:54 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Date procedure?
Message-Id: <87lhme6y3t.fsf@doppelsaurus.mobileactivedefense.com>

Tuxedo <tuxedo@mailinator.com> writes:
> Rainer Weikusat wrote:

[...]

>> -----------
>> my $d = '2014-12-08';
>> my @months = qw(January February March April May June July August
>> September October November December);
>> 
>> sub reformat
>> {
>>     my ($y, $m, $d) = split(/-/, $_[0]);
>>     return sprintf("%d %s %d", $d, $months[$m - 1], $y);
>> }
>> 
>> print(reformat($d), "\n");
>
> The above procedure is now both short and modular, quite perfect!

Well, but it looks as if the author had be exposed to an overdose of PHP
while being in a less-than-resistant mental state. Here's one making use
of facilities typically associated with Perl (Yes, this is sort-of
silly. But it makes a nice, simple example):

-----------
my @months = qw(January February March April May June July August September October November December);

sub reformat
{
    $_[0] =~ /(\d+)-(\d+)-0?(\d+)/ and "$3 $months[$2 - 1] $1";
}

print(reformat('2014-05-08'), "\n");
-----------


------------------------------

Date: Fri, 12 Dec 2014 00:32:08 +0100
From: Tuxedo <tuxedo@mailinator.com>
Subject: Re: Date procedure?
Message-Id: <m6d9hp$9s7$1@news.albasani.net>

Rainer Weikusat wrote:

> Tuxedo <tuxedo@mailinator.com> writes:
> > Rainer Weikusat wrote:
> 
> [...]
> 
> >> -----------
> >> my $d = '2014-12-08';
> >> my @months = qw(January February March April May June July August
> >> September October November December);
> >> 
> >> sub reformat
> >> {
> >>     my ($y, $m, $d) = split(/-/, $_[0]);
> >>     return sprintf("%d %s %d", $d, $months[$m - 1], $y);
> >> }
> >> 
> >> print(reformat($d), "\n");
> >
> > The above procedure is now both short and modular, quite perfect!
> 
> Well, but it looks as if the author had be exposed to an overdose of PHP
> while being in a less-than-resistant mental state. Here's one making use
> of facilities typically associated with Perl (Yes, this is sort-of
> silly. But it makes a nice, simple example):
> 
> -----------
> my @months = qw(January February March April May June July August
> September October November December);
> 
> sub reformat
> {
>     $_[0] =~ /(\d+)-(\d+)-0?(\d+)/ and "$3 $months[$2 - 1] $1";
> }
> 
> print(reformat('2014-05-08'), "\n");
> -----------

Thanks for this mentally enhanced solution under the influence of perl :-)

Tuxedo

 


------------------------------

Date: Fri, 12 Dec 2014 04:18:00 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Date procedure?
Message-Id: <548ab2c8$4$fuzhry+tra$mr2ice@news.patriot.net>

In <87a92wd0js.fsf@doppelsaurus.mobileactivedefense.com>, on
12/09/2014
   at 08:35 PM, Rainer Weikusat <rweikusat@mobileactivedefense.com>
said:

>People who are less keen on baffling others with funny characters 
>and pointless byzantinisms might feel inclined to use something 
>like this instead:

People who are more concerned with a dialog than with baseless charges
of elitismr might note that the characters used by the OP are bog
standard and that you code is equally hard to read, in a different
way. Why not simply suggest that he use existing routines without
inventing ludicrous motives for the code he wrote?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Fri, 12 Dec 2014 03:56:29 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Date procedure?
Message-Id: <548aadbd$1$fuzhry+tra$mr2ice@news.patriot.net>

In <m65b5k$5j1$1@news.albasani.net>, on 12/09/2014
   at 12:10 AM, Tuxedo <tuxedo@mailinator.com> said:

>Yes, and there are many ways to do the same. Naturally it's easy 
>to take the string apart and apply some REs to each part and piece 
>it together in  some new format but it's surely not the most 
>efficient way.

Shirley it *is* the most efficient, especially if you want to check
the input for validity; it may not be the most appropriate. I'd use
something from CPAN that is locale aware rather than generating a
fixed format.

BTW, are semantic constraints still experimental?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Fri, 12 Dec 2014 23:50:22 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Date procedure?
Message-Id: <slrnm8ms9e.2ff.hjp-usenet3@hrunkner.hjp.at>

On 2014-12-09 08:16, Helmut Richter <hhr-m@web.de> wrote:
> Am 09.12.2014 00:36, schrieb Tuxedo:
>> People in different cultures may still see the 2014-12-08 a bit odd

Yes.

>> and even mean different dates in some minds,

Hardly.

>> much like the British vs US conventions.

s/much /un/


> Is there anyone in any country who would give the date 2014-12-08 
> another meaning than 8 DEC 2014? In comparison: the British vs US 
> conventions allow 10/12/14 to mean any of 12 OCT 2014, 10 DEC 2014, or 
> 14 DEC 2010.

At least two of these possibilities are can also be encountered in
Austria, as demonstrated by this partial scan of a train ticket:
http://www.hjp.at/kuriosa/datum.rxml

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: Thu, 11 Dec 2014 13:41:42 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Dedup script is finished and works. Critiques?
Message-Id: <87y4qe717t.fsf@doppelsaurus.mobileactivedefense.com>

Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-12-11, Robbie Hatley <see.my.sig@for.my.address> wrote:

[...]

>> I do now test with -f so that I'm only considering erasing
>> "regular files", not symbolic links or directories.
>
> But hard links are regular files.

Not really. They're directory entries pointing to the same filesystem
object. This will usually be a regular file although 'some systems' also
allow other hardlinks to a directory than . and .. . (this is a
punctuation character). At least on Linux/ ext4, this works, too:

[rw@doppelsaurus]/tmp#mkdir links
[rw@doppelsaurus]/tmp#cd links/
[rw@doppelsaurus]/tmp/links#echo a >a
[rw@doppelsaurus]/tmp/links#ln -s a b
[rw@doppelsaurus]/tmp/links#ln -n b c
[rw@doppelsaurus]/tmp/links#ls -li
total 4
51380239 -rw-r--r-- 1 rw rw 2 Dec 11 13:40 a
51380240 lrwxrwxrwx 2 rw rw 1 Dec 11 13:40 b -> a
51380240 lrwxrwxrwx 2 rw rw 1 Dec 11 13:40 c -> a


------------------------------

Date: Fri, 12 Dec 2014 04:24:21 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Dedup script is finished and works. Critiques?
Message-Id: <548ab445$5$fuzhry+tra$mr2ice@news.patriot.net>

In <6d2dneGULulzexXJnZ2dnUVZ572dnZ2d@giganews.com>, on 12/10/2014
   at 04:36 PM, Robbie Hatley <see.my.sig@for.my.address> said:

>symbolic links (what windows would call "shortcuts")

Aren't "shortcuts" in windoze actual files, rather than alias links
understood by the file system?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Thu, 11 Dec 2014 10:19:43 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Latest version of "dedup", and questions on open files, unlink, and rm.
Message-Id: <slrnm8iksv.8ct.whynot@orphan.zombinet>

with <s5qdnfHJ2dzUeRXJnZ2dnUVZ572dnZ2d@giganews.com> Robbie Hatley wrote:

*SKIP*
> 1. When an "open" statement is set up to autovivify a file handle
>     variable, and the open fails, is the file handle variable supposed
>     to be set to "undef"?  In my tests, sometimes it is, sometimes it
>     isn't.  Is that a Perl bug? Or is supposed to do that?

No, a bug is with you (quoting 'perldoc -f open'):

	Open returns nonzero on success, the undefined value otherwise.

Quick swipe through the perldoc doesn't reveal anything, I assume
behaviour, in regard of a variable passed to open(), is undefined.
Those interested (I'm not) should probably invoke RTSL.  Those
uninterested always open-or-die.

> 2. Since just testing to see if a $filehandle variable is "defined" is
>     apparently NOT a good way to determine whether a file is open...
>     what is? Is there some kind of "is_open()" function in Perl?

	$ perldoc IO::Handle

then grep for 'opened'.  However, I've tried this way once or twice and
failed.  I assume, testing filehandle for openedness is a mark of Bad
Design(TM).  That's why we have lexical filehandles.

> 3. Is the "read pointer" always set to 0 when a file is opened for
>     reading? Or can there be cases when it's not?

There's no such thing as 'read pointer'.  Now, if a file is opened for
reading, and a pointer is placed anywhere else then at start of a file,
then it would be a kill-them-with-fire surprise.  I don't think any sane
OS would joke like this.

*CUT*

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom


------------------------------

Date: Thu, 11 Dec 2014 20:55:12 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Latest version of "dedup", and questions on open files, unlink, and rm.
Message-Id: <0e9plb-kc9.ln1@news.rtij.nl>

On Wed, 10 Dec 2014 16:24:43 -0800, Robbie Hatley wrote:

> 
> 4. My dedup script is using "unlink" to "erase" files. On
>     windows, this is doing what it should, because "shortcuts"
>     or "links" point to the main directory entry for a file,
>     not the file data. But from what I've read, on Linux,
>     if symbolic links to a file exist anywhere, those links will still
>     remain valid even if the main file entry is "unlinked" from its
>     directory. Perhaps something like "system rm $filename" or even `rm
>     $filename` might be a better way, if I want to actually get rid of a
>     file completely (and invalidate any links to it)?

You are confusing symbolic and hard links here. If you delete a file and 
there is still a symbolic link to that directory entry, the symlink  will 
become dangling. There is not much you can do about that, and I doubt it 
would come up in practice. I.o.w. don't worry about it.

Hard links are simply multiple directory entries pointing to the same 
file (inode). (Windows has these too, but they are very rare in 
practice). It may pay for you to compare inode numbers before comparing 
contents. If the inode numbers are the same, don't bother comparing, you 
already know the files are the same (file). What to do in this situationn 
is up to you.

M4


------------------------------

Date: Thu, 11 Dec 2014 14:47:04 -0800
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Latest version of "dedup", and questions on open files, unlink, and rm.
Message-Id: <tcGdncUbR8B0gxfJnZ2dnUVZ57ydnZ2d@giganews.com>


On 12/11/2014 12:19 AM, Eric Pozharski wrote:

> There's no such thing as 'read pointer'.

Oh, don't be silly; of course there is.

I suppose I could have written:

3. Is (Perl's byte counter which it uses to keep track of
    (the next byte of (a file which is open for reading) to be
    accessed by read())) always set to 0 when a file is opened
    for reading? Or can there be cases when it's not?

But I prefer human-readable English:

3. Is the "read pointer" always set to 0 when a file is opened
    for reading? Or can there be cases when it's not?

> Now, if a file is opened for reading, and a pointer is placed
> anywhere else then at start of a file, then it would be a
> kill-them-with-fire surprise.

I don't see why. Say you have a file known to contain 5000 bytes
of data, and you want to read 50 bytes starting at position 2250.

seek ($fh, 2250, 0);      # set read pointer to 2250
read ($fh, $buffer, 50);  # read 50 bytes starting from there

English usage of "pointer", not C usage. Perl isn't C.
The word "pointer" has no special, technical, or jargon meaning
in Perl, so if I use it in a Perl-related forum, it just means
"something which points".

With that in mind...

Is the "read pointer" always set to 0 when a file is opened
for reading? Or can there be cases when it's not?



-- 
RH
lonewolf [at] well [dot] com



------------------------------

Date: Fri, 12 Dec 2014 07:59:53 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: Latest version of "dedup", and questions on open files, unlink, and rm.
Message-Id: <m6f3de$9k5$1@dont-email.me>

On 12/11/2014 14:47, Robbie Hatley wrote:
>
> On 12/11/2014 12:19 AM, Eric Pozharski wrote:
>
>> Now, if a file is opened for reading, and a pointer is placed
>> anywhere else then at start of a file, then it would be a
>> kill-them-with-fire surprise.
>
> I don't see why. Say you have a file known to contain 5000 bytes
> of data, and you want to read 50 bytes starting at position 2250.
>
> seek ($fh, 2250, 0);      # set read pointer to 2250
> read ($fh, $buffer, 50);  # read 50 bytes starting from there

That's not what he has intimating.  All he was saying is that the
file *MUST BE* 'rewound' by the system when you open it to put it
at the proper position for reading - basically the file has to be
positioned at byte 0 upon return from the open call.

> English usage of "pointer", not C usage. Perl isn't C.
> The word "pointer" has no special, technical, or jargon meaning
> in Perl, so if I use it in a Perl-related forum, it just means
> "something which points".
>
> With that in mind...
>
> Is the "read pointer" always set to 0 when a file is opened
> for reading? Or can there be cases when it's not?

Simple logic tells you it has to be.


------------------------------

Date: Sat, 13 Dec 2014 00:36:32 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Latest version of "dedup", and questions on open files, unlink, and rm.
Message-Id: <slrnm8mv00.2ff.hjp-usenet3@hrunkner.hjp.at>

On 2014-12-11 22:47, Robbie Hatley <see.my.sig@for.my.address> wrote:
> On 12/11/2014 12:19 AM, Eric Pozharski wrote:
>> There's no such thing as 'read pointer'.
>
> Oh, don't be silly; of course there is.
>
> I suppose I could have written:
>
> 3. Is (Perl's byte counter which it uses to keep track of
>     (the next byte of (a file which is open for reading) to be
>     accessed by read())) always set to 0 when a file is opened
>     for reading? Or can there be cases when it's not?
>
> But I prefer human-readable English:
>
> 3. Is the "read pointer" always set to 0 when a file is opened
>     for reading? Or can there be cases when it's not?

Straight from the horse's mouth:

| For each open file there is a pointer, maintained inside the system,
| that indicates the next byte to be read or written. If n bytes are read
| or written, the pointer advances by n bytes. 

    -- D. M. Ritchie and K. Thompson: The UNIX Time-Sharing System; 1978

If Dennis and Ken can call it a pointer, so can you ;-).

The C standard calls it the "file position indicator", Linux manuals
call it the "offset". 


>> Now, if a file is opened for reading, and a pointer is placed
>> anywhere else then at start of a file, then it would be a
>> kill-them-with-fire surprise.
>
> I don't see why. Say you have a file known to contain 5000 bytes
> of data, and you want to read 50 bytes starting at position 2250.
>
> seek ($fh, 2250, 0);      # set read pointer to 2250
> read ($fh, $buffer, 50);  # read 50 bytes starting from there

Here you explicitely seek to position 2250. But if you just opened the
file for reading, why should the system assume that you want to read
from position 2250 (or any position other than 0)? 


> Is the "read pointer" always set to 0 when a file is opened for
> reading?

Yes.

> Or can there be cases when it's not?

Even when a file is opened in append mode, it is initially positioned at
the start. Only when you write to it, the file pointer jumps to the end.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

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:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#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 V11 Issue 4327
***************************************


home help back first fref pref prev next nref lref last post