Re: tail -f: --pid *and* inotify
Pádraig Brady wrote: Pádraig Brady wrote: I'm not able to compile/test/push at the moment due to gnulib submodule weirdness. I was playing around with submodules today and thought I had messed up something. But I think the issue is that you synced to a private gnulib version? Hi Pádraig, Thanks for the heads up! I did indeed make a mistake. In testing prior to the move-update-copyright-to-gnulib change I committed a trail change in coreutils/gnulib, and never went back and fixed it. This calls for another syntax-check test. FYI, this is what I had: $ g show 29a35cf5baff3fa063a995e91c28986859ad865f commit 29a35cf5baff3fa063a995e91c28986859ad865f Merge: b53ff7b 5dac040 Author: Jim Meyering meyer...@redhat.com Date: Wed Jul 29 19:30:35 2009 +0200 Merge branch 'master' of /gnulib into HEAD I've just sync'd and pushed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BTRFS file clone support for cp
Pádraig Brady p...@draigbrady.com writes: +#expensive_ That comment is just for testing I presume? Note you can run a single expensive test like: (cd tests make check TESTS=cp/file-clone VERBOSE=yes RUN_EXPENSIVE_TESTS=yes) sorry, yes I commented it out only for testing purpose. If you think the rest is fine and want to push it, can you please amend my commit? Thanks, Giuseppe ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BTRFS file clone support for cp
Giuseppe Scrivano wrote:
Pádraig Brady p...@draigbrady.com writes:
+#expensive_
That comment is just for testing I presume?
Note you can run a single expensive test like:
(cd tests make check TESTS=cp/file-clone VERBOSE=yes
RUN_EXPENSIVE_TESTS=yes)
sorry, yes I commented it out only for testing purpose. If you think
the rest is fine and want to push it, can you please amend my commit?
Sure I'll fix it up from here.
I'll not push yet though, until the interface settles down.
I.E. we'll probably need to be calling {cp,ln} --reflink instead.
cheers,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] fallocate utility
Eric Sandeen wrote: Pádraig Brady wrote: Eric Sandeen wrote: TBH I think truncate --allocate sounds a little odd. (Now that I think back, I think I mentioned this before). truncate(1) and truncate(2) specifically refer to i_size, which to fs people like me, has nothing to do with the actual blocks allocated to a file. Well truncate(2) does, but I think truncate(1) is higher level and is used to set the size of a file. But size of a file in the truncate sense only means set the EOF offset. I don't see a problem in extending the meaning of the truncate command. Now truncate isn't the best name for the command but that name already existed in BSD and so I thought it best to align with that. So what about also having an fallocate command in coreutils? Well it would benefit from all the existing options of the truncate command, I.E. would share most of the code, so I'm not convinced. I guess I don't -really- care if truncate grows an --allocate option, but I'd still like to see a nice fallocate in util-linux-ng ;) A reason to have this functionality in coreutils is that the core functionality of posix_fallocate() is not linux specific. Also fallocate() like functionality is exposed on solaris for example through fcntl(fd, F_ALLOCSP, ...). BTW I think your fallocate util might benefit from calling truncate(2) to allow one to shrink files also? cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] cp: preserve time stamps on symlinks, too
Jim Meyering wrote: This patch may not be ready for prime time. I wrote it and the test a few days ago, but haven't gone back and looked closely. There are just too many branches and use cases, and I'm sure I haven't considered all of them. However, all tests do pass, at least on recent gnu/linux systems. If anyone feels like giving this a try or reviewing it, I'd appreciate any feedback. Wow, what a hairball of a function :) I spent 30 mins looking at it and can't see any issues. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new module: update-copyright [Re: copyright years: mass-update every January 1
On Thu, 30 Jul 2009, Joel E. Denny wrote:
On Thu, 30 Jul 2009, Jim Meyering wrote:
There remains at least one infelicity: if someone discusses
the Copyright (C) notation (e.g., as on this line), and later
has the copyright-with-dates line, the prefixes may not match.
We could require that the Copyright...holder (and hence prefix)
are all in proximity, but that may not be worth the trouble.
In the first patch below, I ended up documenting that limitation instead
of fixing it. It should be very straightforward to add a proximity check
in the initial search for the copyright. However, I haven't yet found a
real-world test case, so I'm waiting. For now, the worst case is that an
affected file just won't be updated, and we'll be warned.
The current behavior is a little unintuitive in other similar ways as
well. For example, if Copyright (C) isn't recognized anywhere and thus
no comment sequence is recognized, the script still looks for an
occurrence of the copyright year and holder to adjust. Thus, the script
handles Copyright @copyright{} only when it's not in comments. I'd
rather it be consistent by not handling it at all or handling it
completely.
Also, it bothered me that 2009 might be added to the phrase 98 Free
Software Foundation, for example, even if it had nothing to do with a
copyright statement. I've fixed this in the first patch below.
I'm working on a patch to fix all of the above and to automatically format
the result to 72 columns. I'll try to post a patch soon.
I've also implemented reformatting in the first patch.
In the next two patches below, I've added handling for DOS EOLs and for
leading tabs in, for example, ChangeLogs. These are helpful in Bison, at
least.
From 2727188acb1f45b83f5072bfdac740715c78444c Mon Sep 17 00:00:00 2001
From: Joel E. Denny jde...@clemson.edu
Date: Fri, 31 Jul 2009 09:11:53 -0400
Subject: [PATCH] update-copyright: automatically format copyright statements
* build-aux/update-copyright: Implement that.
Also, be a little more predictable and safer by always failing
when the full copyright format is not perfectly recognized as an
unbroken whole. Discussed at
http://lists.gnu.org/archive/html/bug-gnulib/2009-07/msg00131.html.
Rewrite documentation.
---
ChangeLog | 10 +++
build-aux/update-copyright | 160 +---
2 files changed, 130 insertions(+), 40 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 239faa6..a9e8cfc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2009-07-31 Joel E. Denny jde...@clemson.edu
+
+ update-copyright: automatically format copyright statements
+ * build-aux/update-copyright: Implement that.
+ Also, be a little more predictable and safer by always failing
+ when the full copyright format is not perfectly recognized as an
+ unbroken whole. Discussed at
+ http://lists.gnu.org/archive/html/bug-gnulib/2009-07/msg00131.html.
+ Rewrite documentation.
+
2009-07-29 Matt Kraai mkr...@beckman.com
getloadavg: check whether n_name is a pointer, for QNX 6.4.1
diff --git a/build-aux/update-copyright b/build-aux/update-copyright
index e35d51b..59ce6b6 100755
--- a/build-aux/update-copyright
+++ b/build-aux/update-copyright
@@ -1,7 +1,7 @@
#!/usr/bin/perl -0777 -pi
# Update an FSF copyright year list to include the current year.
-my $VERSION = '2009-07-30.13:24'; # UTC
+my $VERSION = '2009-07-31.12:44'; # UTC
# Copyright (C) 2009 Free Software Foundation
#
@@ -20,63 +20,114 @@ my $VERSION = '2009-07-30.13:24'; # UTC
# Written by Jim Meyering
-# In the copyright statement in each file, Copyright (C) must appear
-# at the beginning of the line except that it may be preceded by any
-# sequence (e.g., a comment) of no more than 5 characters. Iff that
-# prefix is present, the same prefix should appear at the beginning
-# of each remaining line within the copyright statement so that it
-# can be parsed correctly.
+# The arguments to this script should be names of files that contain FSF
+# copyright statements to be updated. For example, you may wish to
+# place a target like the following in your top-level makefile in your
+# project:
#
-# For example, these are fine:
+# .PHONY: update-copyright
+# update-copyright:
+# if test -d .git; then \
+# git grep -l -w Copyright \
+# | grep -v -E '(^|/)(COPYING|ChangeLog)' \
+# | xargs $(srcdir)/build-aux/$@; \
+# fi
+#
+# In the second grep, you can build a list of files to skip within your
+# project.
+#
+# Iff an FSF copyright statement is discovered in a file and the final
+# year is not the current year, the statement is updated for the new
+# year and reformatted to fit within 72 columns. A warning is printed
+# for every file for which no FSF copyright statement is discovered.
+#
Re: [RFC] fallocate utility
Pádraig Brady wrote: Eric Sandeen wrote: Pádraig Brady wrote: Eric Sandeen wrote: TBH I think truncate --allocate sounds a little odd. (Now that I think back, I think I mentioned this before). truncate(1) and truncate(2) specifically refer to i_size, which to fs people like me, has nothing to do with the actual blocks allocated to a file. Well truncate(2) does, but I think truncate(1) is higher level and is used to set the size of a file. But size of a file in the truncate sense only means set the EOF offset. I don't see a problem in extending the meaning of the truncate command. Now truncate isn't the best name for the command but that name already existed in BSD and so I thought it best to align with that. So what about also having an fallocate command in coreutils? Well it would benefit from all the existing options of the truncate command, I.E. would share most of the code, so I'm not convinced. Well, truncate is indeed a great name for a command that truncates. :) Does truncate do more than that in bsd? I guess I don't -really- care if truncate grows an --allocate option, but I'd still like to see a nice fallocate in util-linux-ng ;) A reason to have this functionality in coreutils is that the core functionality of posix_fallocate() is not linux specific. Also fallocate() like functionality is exposed on solaris for example through fcntl(fd, F_ALLOCSP, ...). Ok, having an aptly-named block-allocation-tool in coreutils sounds reasonable, if it the core functionality that can be supported across several OSes. BTW I think your fallocate util might benefit from calling truncate(2) to allow one to shrink files also? No, that's what truncate(1) is for IMHO. Do one thing and do it well, right? :) -Eric cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] fallocate utility
Tilman Schmidt wrote: Pádraig Brady schrieb: I don't see a problem in extending the meaning of the truncate command. Now truncate isn't the best name for the command but that name already existed in BSD and so I thought it best to align with that. So what about also having an fallocate command in coreutils? Well it would benefit from all the existing options of the truncate command, I.E. would share most of the code, so I'm not convinced. Why not make it, in the best Unix tradition, a single executable whose action depends on the name it is run as? Hmm. Good idea. There is precedent for that already in coreutils. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] fallocate utility
Hello, Pádraig Brady p...@draigbrady.com writes: Tilman Schmidt wrote: Pádraig Brady schrieb: I don't see a problem in extending the meaning of the truncate command. Now truncate isn't the best name for the command but that name already existed in BSD and so I thought it best to align with that. So what about also having an fallocate command in coreutils? Well it would benefit from all the existing options of the truncate command, I.E. would share most of the code, so I'm not convinced. Why not make it, in the best Unix tradition, a single executable whose action depends on the name it is run as? Hmm. Good idea. There is precedent for that already in coreutils. What do you think about having two separate executables? Considering fallocate and truncate will share almost all code, these differences can be separed at compilation-time. It seems that the same approach is already used by md5sum and shaXXXsum. IMHO, it is a bit cleaner than depend from the argv[0] value at run-time (Tilman, is it what you meant?). Cheers, Giuseppe ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] fallocate utility
Giuseppe Scrivano wrote: Hello, Pádraig Brady p...@draigbrady.com writes: Tilman Schmidt wrote: ... Why not make it, in the best Unix tradition, a single executable whose action depends on the name it is run as? Hmm. Good idea. There is precedent for that already in coreutils. What do you think about having two separate executables? Considering fallocate and truncate will share almost all code, these differences can be separed at compilation-time. It seems that the same approach is already used by md5sum and shaXXXsum. I'm curious - how much code will be shared, really? in terms of functionality, truncate currently has: -c, --no-create do not create any files -o, --io-blocks Treat SIZE as number of IO blocks instead of bytes -r, --reference=FILE use this FILE’s size -s, --size=SIZE use this SIZE --help display this help and exit --version output version information and exit the_util_previously_known_as_fallocate would have something like: -c, --no-create do not create any files -o, --offset=OFFSET start allocation at this OFFSET (0 default) -l, --length=LENGTH allocate this LENGTH starting at OFFSET (or 0) -n, --no-size-update do not change i_size (allow blocks past EOF) --help display this help and exit --version output version information and exit I suppose -c might be shared between the two; it's a question of O_CREAT or not, right. But that's just a line or two. the k/m/g/t/p/e parsing would be shared, but hopefully that's in a library somewhere? the allocation tool, if done portably, would have a whole whack of configure-time options, I'd expect, based on which OS it's trying to allocate on, and what interface the OS provides. AFAIK, truncate(2) is truncate(2) just about everywhere. If it really makes sense to share, fine, but I'm surprised that it'd be a lot of common code. Maybe after it gets written it'd be more obvious. Thanks, -Eric ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] fallocate utility
Pádraig Brady schrieb: I don't see a problem in extending the meaning of the truncate command. Now truncate isn't the best name for the command but that name already existed in BSD and so I thought it best to align with that. So what about also having an fallocate command in coreutils? Well it would benefit from all the existing options of the truncate command, I.E. would share most of the code, so I'm not convinced. Why not make it, in the best Unix tradition, a single executable whose action depends on the name it is run as? -- Tilman SchmidtE-Mail: til...@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] fallocate utility
Tilman Schmidt wrote: Why not make it, in the best Unix tradition, a single executable whose action depends on the name it is run as? That can cause problems in various cases. So much so that it was written into the GNU Coding Standards to be avoided: http://www.gnu.org/prep/standards/html_node/User-Interfaces.html#User-Interfaces Please don't make the behavior of a utility depend on the name used to invoke it. It is useful sometimes to make a link to a utility with a different name, and that should not change what it does. Instead, use a run time option or a compilation switch or both to select among the alternate behaviors. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [RFC] fallocate utility
Eric Sandeen wrote: Giuseppe Scrivano wrote: Hello, Pádraig Brady p...@draigbrady.com writes: Tilman Schmidt wrote: ... Why not make it, in the best Unix tradition, a single executable whose action depends on the name it is run as? Hmm. Good idea. There is precedent for that already in coreutils. What do you think about having two separate executables? Considering fallocate and truncate will share almost all code, these differences can be separed at compilation-time. It seems that the same approach is already used by md5sum and shaXXXsum. I'm curious - how much code will be shared, really? in terms of functionality, truncate currently has: -c, --no-create do not create any files -o, --io-blocks Treat SIZE as number of IO blocks instead of bytes -r, --reference=FILE use this FILE’s size -s, --size=SIZE use this SIZE --help display this help and exit --version output version information and exit the_util_previously_known_as_fallocate would have something like: -c, --no-create do not create any files -o, --offset=OFFSET start allocation at this OFFSET (0 default) -l, --length=LENGTH allocate this LENGTH starting at OFFSET (or 0) -n, --no-size-update do not change i_size (allow blocks past EOF) --help display this help and exit --version output version information and exit I was thinking the new fallocate util would have the same options as the existing truncate util. I.E. -n or -o would not be needed or supportable in all situations. If you think that users would need those, then I suggest adding the linux specific fallocate util to util-linux-ng, and we'll add the more generic `truncate --allocate` (or separate command) to coreutils. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
