perl5 docu bug - utime is _not_ equivalent to touch

[p5pRT]

Migrated from rt.perl.org#31578 (status was 'resolved')

Searchable as RT31578$

[p5pRT]

From [email protected]

with the shell command "touch" i can specify any file i want
and it will mostly succeed for updating the file dates.

with the perl command "ulimit" i will only succeed for file dates
if the file belongs to me.

quote from the man page "perlfunc"
  The inode change time of each file is set to the current time.
  For example, this code has the same effect
  as the Unix touch(1) command when the files already exist.

When i am failing with perl but do succeed with touch,
then this looks a bit like either perl is buggy compared to the shell
or perl less featured than the shell. In the first case perl should
be fixed, in the latter this is a significant difference which does
need explicit documentation so that the perl behaviour is predictable.

Anyone knows about a workaround without invoking a subshell running touch?
Minor note​: I observed that habit on a system with NFS shares.

-Alex.

--
Superg???nstige DSL-Tarife + WLAN-Router f???r 0,- EUR*
Jetzt zu GMX wechseln und sparen http​://www.gmx.net/de/go/dsl

[p5pRT]

From @iabyn

On Wed, Sep 15, 2004 at 08​:03​:02AM -0000, Alexander Stohr wrote​:

with the perl command "ulimit" i will only succeed for file dates
if the file belongs to me.

(I presume you meant 'utime' rather than 'ulimit')

Can you show a concrete example of this failure, eg the full output
of a session like the following​:

  $ id
  $ touch file
  $ ls -l file
  $ sleep 5
  $ perl -e '$t=time; utime $t, $t, "file" or die "utime​: $!\n"'
  $ ls -l file
  $ sleep 5
  $ touch file
  $ ls -l file

Also, could you show the output of

  perlbug -d

Thanks,

Dave.

--
The Enterprise's efficient long-range scanners detect a temporal vortex
distortion in good time, allowing it to be safely avoided via a minor
course correction.
  -- Things That Never Happen in "Star Trek" #21

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From [email protected]

Alexander Stohr <perl5-porters@​perl.org> writes​:

# New Ticket Created by Alexander Stohr
# Please include the string​: [perl #31578]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org​:80/rt3/Ticket/Display.html?id=31578 >

with the shell command "touch" i can specify any file i want
and it will mostly succeed for updating the file dates.

with the perl command "ulimit" i will only succeed for file dates
if the file belongs to me.

quote from the man page "perlfunc"
The inode change time of each file is set to the current time.
For example, this code has the same effect
as the Unix touch(1) command when the files already exist.

When i am failing with perl but do succeed with touch,
then this looks a bit like either perl is buggy compared to the shell
or perl less featured than the shell. In the first case perl should
be fixed, in the latter this is a significant difference which does
need explicit documentation so that the perl behaviour is predictable.

Anyone knows about a workaround without invoking a subshell running touch?
Minor note​: I observed that habit on a system with NFS shares.

ExtUtils​::Command​::touch()
does​:
  my $t = time;
  open(FILE,">>$file") || die "Cannot write $file​:$!";
  close(FILE);
  utime($t,$t,$file);

The open for append "touches" files you don't own.

-Alex.

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'