New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PATCH] misleading example in perldoc -f flock #6767
Comments
From nick@cleaton.netCreated by nick@cleaton.netThe output of "perldoc -f flock" includes the following example Here's a mailbox appender for BSD systems. use Fcntl ':flock'; # import LOCK_* constants sub lock { sub unlock { open(MBOX, ">>/usr/spool/mail/$ENV{'USER'}") lock(); ... which appears to have been written by someone under the This is not the case. When a file is opened in append mode, all ``a'' Open for writing. The file is created if it does not and the corresponding extract from open(2): Opening a file with O_APPEND set causes each write on the I've confirmed this behavior on FreeBSD by adding a sleep to the Reading this example a couple of years ago left me with a false Perl Info
|
From @mjdominus
If memory serves me correctly, on old unix systems, it *was* the same; Whether any systems with the old semantics still exist, or, of they |
From @mjdominusRochkind (_Advanced Unix Programming_) says that O_APPEND was The example in question does specify that it's "a mailbox appender for I said:
|
From @gisle"nick@cleaton.net (via RT)" <perlbug-followup@perl.org> writes:
The lock is still needed here since a single print might result in It also seems like this example need to make sure to flush the MBOX Regards, |
From nick@cleaton.netOn Mon, Sep 22, 2003 at 11:59:33AM -0000, Gisle Aas wrote:
Either that or adjust the comment so that it notes that the seek isn't flock(MBOX,LOCK_EX);
Yes. -- |
From @mjdominusGisle Aas <gisle@ActiveState.com>:
I believe that Nick was suggesting that the seek could be removed.
I thought so too, but the manual says that that is now longer necessary: To avoid the possibility of miscoordination, Perl now flushes |
From @gisleMark Jason Dominus <mjd@plover.com> writes:
Cool. In what version can we depend on this behaviour? Regards, |
From rick@bort.caOn Mon, Sep 22, 2003 at 07:07:12AM -0700, Gisle Aas wrote:
IIRC, 5.004. perl5004delta.pod confirms my recollection: =item flock is now supported on more platforms, prefers fcntl to lockf when -- |
From @mjdominusGisle Aas <gisle@ActiveState.com>:
Starting in 5.005_03. |
From @mjdominusMark Jason Dominus <mjd@plover.com>:
Rick Delaney said 5.004. He is probably right. I based my conclusion |
From @RandalSchwartz
Nick@Cleaton> ... which appears to have been written by someone under the Nick@Cleaton> This is not the case. When a file is opened in append mode, all It was *indeed* precisely the case on V7 Unix. The example probably However, I'd be hard-pressed to find a modern Unix on which append-mode -- |
From @jkeenanOn Mon Sep 22 10:01:30 2003, merlyn@stonehenge.com wrote:
The example found in Perl 5.16.0 under 'perldoc -f flock' (excerpt Could Nick@Cleaton and the other commenters review this and see where we Thank you very much. |
From @jkeenanHere's a mailbox appender for BSD systems. use Fcntl qw(:flock SEEK_END); # import LOCK_* and SEEK_END constants sub lock { # and, in case someone appended while we were waiting... sub unlock { open(my $mbox, ">>", "/usr/spool/mail/$ENV{'USER'}") lock($mbox); |
From tchrist@perl.comSo I think what that's saying is that the seek is immaterial --tom |
From @jkeenanOn Sat May 26 19:44:41 2012, tom christiansen wrote:
Tom, does that mean that this nearly ten-year-old RT is closable? (It Thank you very much. |
From @dcollinsnI agree with Nick's complaint and with the other observations in this thread. The seek may not be necessary, but this comment at least explains why, whereas removing the seek doesn't teach anyone anything. Patch attached. |
From @dcollinsn0001-RT-23813-perlfunc.pod-explain-seek-in-O_APPEND.patchFrom c2bde2eb1618d5608461cb065d688f7dc76a5d0e Mon Sep 17 00:00:00 2001
From: Dan Collins <dcollinsn@gmail.com>
Date: Tue, 5 Jul 2016 19:02:12 -0400
Subject: [PATCH] [RT #23813] perlfunc.pod: explain seek in O_APPEND
In all modern systems, seek has no effect in O_APPEND. As explained
by Nick Cleaton at that RT, the comment was written in a time when:
...opening a file for append [was] the same as opening for
write and then seeking to the end.
This is not the case. When a file is opened in append mode,
all writes are appended to the then end of file, irrespective
of the current file position.
Corrected comment was contributed by him.
---
pod/perlfunc.pod | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 5c778f1..36eb96b 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -2653,8 +2653,8 @@ Here's a mailbox appender for BSD systems.
sub lock {
my ($fh) = @_;
flock($fh, LOCK_EX) or die "Cannot lock mailbox - $!\n";
-
- # and, in case someone appended while we were waiting...
+ # and, in case we're running on a very old UNIX
+ # variant without the modern O_APPEND semantics...
seek($fh, 0, SEEK_END) or die "Cannot seek - $!\n";
}
--
2.8.1
|
From @jkeenanOn Tue, 05 Jul 2016 23:13:20 GMT, dcollinsn@gmail.com wrote:
List: Is the documentation change to perlfunc proposed by Dan Collins acceptable? If so, is this 13-year-old ticket closable? Thank you very much. |
From @iabynOn Sun, Feb 26, 2017 at 02:58:55PM -0800, James E Keenan via RT wrote:
Yes, but lets apply it after 5.26....
...and then close the ticket. -- |
From @jkeenanOn Wed, 29 Mar 2017 11:14:36 GMT, davem wrote:
Pushed to blead in commit 5c3085e. Marking ticket Resolved. (It only took 13 years!) Thank you very much. -- |
@jkeenan - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#23813 (status was 'resolved')
Searchable as RT23813$
The text was updated successfully, but these errors were encountered: