cut accepts a new option, --complement
The copyright paperwork just went through,
so I've checked in this change:
2004-10-01 Paolo Bonzini [EMAIL PROTECTED]
* cut.c (complement, COMPLEMENT_OPTION): New.
(longopts): Add --complement.
(usage): Say not that -b, -c, and -f `print' fields,
but rather that they `select' fields for printing.
Describe the new --complement option.
(mark_range_start): Extracted from set_fields.
(print_kth): Support --complement.
(compare_ranges): New function.
(set_fields): Rewrite the part that populates range_start_ht,
merging it with the part that populates printable_field.
(main): Handle --complement.
in doc/ChangeLog:
2004-12-04 Jim Meyering [EMAIL PROTECTED]
* coreutils.texi (cut invocation): Say when --complement is useful.
2004-10-01 Paolo Bonzini [EMAIL PROTECTED]
* coreutils.texi (cut invocation): Document --complement and
adjust the documentation of -b, -c, -f.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.251
retrieving revision 1.252
diff -u -p -u -r1.251 -r1.252
--- NEWS20 Nov 2004 08:55:22 - 1.251
+++ NEWS4 Dec 2004 14:15:46 - 1.252
@@ -182,6 +182,9 @@ GNU coreutils NEWS
copying or moving multiple times to the same destination in a file
system with a coarse time stamp resolution.
+ cut accepts a new option, --complement, to complement the set of
+ selected bytes, characters, or fields.
+
dd now also prints the number of bytes transferred, the time, and the
transfer rate. The new status=noxfer operand suppresses this change.
Index: src/cut.c
===
RCS file: /fetish/cu/src/cut.c,v
retrieving revision 1.116
retrieving revision 1.117
diff -u -p -u -r1.116 -r1.117
--- src/cut.c 16 Nov 2004 20:47:28 - 1.116
+++ src/cut.c 4 Dec 2004 13:32:48 - 1.117
@@ -126,6 +126,10 @@ static enum operating_mode operating_mod
with field mode. */
static bool suppress_non_delimited;
+/* If nonzero, print all bytes, characters, or fields _except_
+ those that were specified. */
+static bool complement;
+
/* The delimeter character for field mode. */
static unsigned char delim;
@@ -155,7 +159,8 @@ static Hash_table *range_start_ht;
non-character as a pseudo short option, starting with CHAR_MAX + 1. */
enum
{
- OUTPUT_DELIMITER_OPTION = CHAR_MAX + 1
+ OUTPUT_DELIMITER_OPTION = CHAR_MAX + 1,
+ COMPLEMENT_OPTION
};
static struct option const longopts[] =
@@ -166,6 +171,7 @@ static struct option const longopts[] =
{delimiter, required_argument, 0, 'd'},
{only-delimited, no_argument, 0, 's'},
{output-delimiter, required_argument, 0, OUTPUT_DELIMITER_OPTION},
+ {complement, no_argument, 0, COMPLEMENT_OPTION},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{0, 0, 0, 0}
@@ -191,17 +197,21 @@ Print selected parts of lines from each
Mandatory arguments to long options are mandatory for short options too.\n\
), stdout);
fputs (_(\
- -b, --bytes=LISToutput only these bytes\n\
- -c, --characters=LIST output only these characters\n\
+ -b, --bytes=LISTselect only these bytes\n\
+ -c, --characters=LIST select only these characters\n\
-d, --delimiter=DELIM use DELIM instead of TAB for field delimiter\n\
), stdout);
fputs (_(\
- -f, --fields=LIST output only these fields; also print any line\n\
+ -f, --fields=LIST select only these fields; also print any line\n\
that contains no delimiter character, unless\n\
the -s option is specified\n\
-n (ignored)\n\
), stdout);
fputs (_(\
+ --complementcomplement the set of selected bytes, characters\n\
+or fields.\n\
+), stdout);
+ fputs (_(\
-s, --only-delimiteddo not print lines not containing delimiters\n\
--output-delimiter=STRING use STRING as the output delimiter\n\
the default is to use the input delimiter\n\
@@ -228,6 +238,19 @@ With no FILE, or when FILE is -, read st
}
static inline void
+mark_range_start (size_t i)
+{
+ /* Record the fact that `i' is a range-start index. */
+ void *ent_from_table = hash_insert (range_start_ht, (void*) i);
+ if (ent_from_table == NULL)
+{
+ /* Insertion failed due to lack of memory. */
+ xalloc_die ();
+}
+ assert ((size_t) ent_from_table == i);
+}
+
+static inline void
mark_printable_field (size_t i)
{
size_t n = i / CHAR_BIT;
@@ -272,15 +295,25 @@ is_range_start_index (size_t i)
static bool
print_kth (size_t k, bool *range_start)
{
- if ((0 eol_range_start eol_range_start = k)
- || (k = max_range_endpoint is_printable_field (k)))
-{
- if (range_start)
- *range_start
Re: [coreutils: tr] \55 \133 \135 taken as syntax tokens
Stephane Chazelas [EMAIL PROTECTED] wrote: (coreutils 5.2.1, on Debian Linux, C locale). $ echo mmm | tr 'a\55z' a aaa (expected mmm) $ echo abcd | tr 'abcd' '\133m*\135' (expected [m*]) If I understand http://www.opengroup.org/onlinepubs/009695399/utilities/tr.html correctly, \55, \133, \135 should be treated as values to placed into the arrays and shouldn't have the special meaning they have once expanded. Thanks for the nice bug report. That's been fixed `upstream' for six months. Yep, we're overdue for a new release. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail.c: 836: recheck: Assertion `valid_file_spec (f)' failed (linux, kernel 2.4.x, coreutils 5.2.1)
Roberto Nibali [EMAIL PROTECTED] wrote: ... Oh. I see that this has been fixed since 5.2.1. ... Hmmm, has it really? Could you show me the changeset, please? My use of `since' was misleading. This was fixed *after* coreutils-5.2.1. You can find the development version here: http://savannah.gnu.org/cvs/?group=coreutils Here's one of the related ChangeLog entries: 2004-07-23 Paul Eggert [EMAIL PROTECTED] Fix bug with tail -f reported by Rob Holland in http://lists.gnu.org/archive/html/bug-coreutils/2004-07/msg00054.html. Also, remove the undocumented and unsupported-since-2000 --max-consecutive-size-changes options. Fix another related bug: tail got confused if stdin, stdout, or stderr were closed. Also, use output buffering even with tail -f. * NEWS: Document this, plus yesterday's patch. * doc/coreutils.texi (tail invocation): size has remained the same - file has not changed, which is more accurate for fifos. * src/tail.c: Include fcntl-safer.h. (COPY_TO_EOF): Set to UINTMAX_MAX, not OFF_T_MAX (which was wrong). (COPY_A_BUFFER): New macro. (struct File_spec): New members mtime, mode, blocking. Remove member n_consecutive_size_changes. (DEFAULT_MAX_N_CONSECUTIVE_SIZE_CHANGES, max_n_consecutive_size_changes_between_opens, MAX_CONSECUTIVE_SIZE_CHANGES_OPTION): Remove. (long_options, tail_forever, parse_options): Remove (non-)support for --max-consecutive-size-changes. (record_open_fd): New function. (recheck, tail_file): Use it. Don't assume that stdin is open. (dump_remainder): Add support for new COPY_A_BUFFER special value. Treat errno==EAGAIN like EOF, since it might be a nonblocking read. (recheck): New arg BLOCKING, specifying whether to use blocking reads. All uses changed. (n_live_files): Remove, replacing with... (any_live_files): New function. All uses changed. (tail_forever): Use nonblocking I/O unless we know that blocking I/O is safe; this avoids some hangs when reading from a fifo. Avoid invoking fstat or sleep when using blocking I/O. Do not check for changes to size if the file is not a regular file, as the size is undefined in that case. Check for changes to mtime or mode, too; this works for non-regular files. (tail_forever, main): Redo fflush strategy to work even when input is nonblocking. Don't use unbuffered output; just flush when needed. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tr doesn't work for multibyte encodings
Tim Waugh [EMAIL PROTECTED] wrote: In 5.2.1, tr doesn't work for multibyte encodings such as UTF-8. Are there any plans to fix this? It's most certainly on the list, (hmm.. it's been on the list in my head for years, but wasn't listed in the TODO file -- I've just added it there) The same applies to many of the other word/line/character-based programs, like wc, fmt, cut, sort, etc. Here's what I've added to TODO: Adapt tools like wc, tr, fmt, etc. (most of the textutils) to be multibyte aware. The problem is that I want to avoid duplicating significant blocks of logic, yet I also want to incur only minimal (preferably `no') cost when operating in single-byte mode. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#286605: csplit help and manual page uses misleading file names
Matt Kraai [EMAIL PROTECTED] wrote: Package: coreutils Version: 5.2.1-2 $ csplit --help | head -3 Usage: csplit [OPTION]... FILE PATTERN... Output pieces of FILE separated by PATTERN(s) to files `xx01', `xx02', ..., and output byte counts of each piece to standard output. When I run csplit, however, the output goes to xx00, xx01, ... Thank you! I've just fixed that upstream. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I: coreutils-20041123: src/touch.c regression
Dmitry V. Levin [EMAIL PROTECTED] wrote: ... According to documentation, futimes() may also fail with ENOSYS; in this case, falling back on utimes() also looks reasonable: + if (errno != ENOENT) + if (errno != ENOSYS errno != ENOENT) Thanks. I've made that change. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I: coreutils-20041123: src/touch.c regression
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Dmitry V. Levin [EMAIL PROTECTED] wrote:
+ if (errno != ENOSYS errno != ENOENT)
Thanks.
I've made that change.
On further thought, this looks like a classic example where we should
be testing for known valid error numbers rather than adding bogus
error numbers as reports come in from the field. So I installed this:
Either way is fine with me, as long as we get it right :-)
I have a slight preference for the approach that uses the smaller,
set of errno values, on the assumption that it's easier to
verify completeness. Also, I suspect it is more likely that the
larger set will grow, in this case.
Your switch statement should probably handle EBADF, too,
to avoid an unnecessary utimes call after such a failure.
2005-01-03 Paul Eggert [EMAIL PROTECTED]
* utimens.c (futimens): Robustify the previous patch, by checking
for known valid error numbers rather than observed invalid ones.
...
+ switch (errno)
+ {
+ case EACCES:
+ case EIO:
+ case EPERM:
+ case EROFS:
+ return -1;
+ }
}
# endif
return utimes (file, t);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort -nu treatment of 0 empty lines
Ulrich Hermisson [EMAIL PROTECTED] wrote: Hello, the following behaviour of sort -nu needs not necessarily be considered a bug: $ echo ,2,0,1,-2,3,-4 | tr , \n | sort -nu -4 -2 1 2 3 Thanks for the report. POSIX requires sort, with -n or `-kM,Nn', to interpret an empty field as 0. The documentation (info sort) already says that an empty field is valid but doesn't specify how it's interpreted. I've just added a sentence saying that. Here's the new description: `--numeric-sort' Sort numerically: the number begins each line; specifically, it consists of optional blanks, an optional `-' sign, and zero or more digits possibly separated by thousands separators, optionally followed by a decimal-point character and zero or more digits. A string of zero digits is interpreted as `0'. The `LC_NUMERIC' locale specifies the decimal-point character and thousands separator. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort -nu treatment of 0 empty lines
Jim Meyering [EMAIL PROTECTED] wrote:
A string of zero digits is interpreted as `0'.
That sounds to me like it's talking about 00. Maybe A string
of no digits? Or A line that ends or has has nondigit characters
where the number would be?
Good point.
Thanks.
by a decimal-point character and zero or more digits. A string of
no digits is interpreted as @samp{0}. The @env{LC_NUMERIC}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test Failures in coreutils-5.3.0 on SunOS-5.5.1
Vin Shelton [EMAIL PROTECTED] wrote: To whom it may concern: Thanks for the quick testing and report! What compiler did you use? On a SunOS-5.5.1 system (uname -a reports: SunOS boise 5.5.1 Generic_103640-40 sun4u sparc SUNW,Ultra-5_10 Solaris) I'm getting the following test failures: FAIL: basic FAIL: time-1 The first two (above) are due to the fact that you built and ran the tests on a file system of type tmpfs that is particularly deficient. Please try to avoid it. Here's a relevant comment from the test output: failed ls ctime test -- this failure is expected at least for SunOS4.1.4 and for tmpfs file systems on Solaris 5.5.1. FAIL: nl I don't know about the above. Can you debug it to see where/how nl is getting the segfault? FAIL: printf It looks like the above is failing because this command ./printf '5 % +d\n' 234 outputs this: 5 +0 rather than the expected: 5 +234 Can you find out why? FAIL: x8 This od test failure is probably due to trouble involving the PRI*MAX macros or to the values of ULONG_MAX or ULLONG_MAX. It is probably using %l rather than %ll as the LONGEST_MODIFIER. You can investigate further by checking config.h for ULLONG_MAX. If that shows nothing defined, then please preprocess od.c with cpp and look for definitions there. E.g., do this: cd src rm -f od.o make AM_CFLAGS='-E -dD' od.o mv od.o od.i Then search od.i for those symbols: grep -E 'PRI.MAX|ULLONG_MAX' od.i I'll look at the following later. FAIL: pr-tests FAIL: ignore FAIL: uniq-tests ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test report coreutils-5.3.0 on Solaris 7
Eric Blake [EMAIL PROTECTED] wrote: I have access to an old Solaris 7 box at work, which has gcc 2.8.1. When compiled with CFLAGS='', all non-root tests pass or are skipped. But with the default CFLAGS='-g -O2', gcc miscompiles putchar() (basically, it replaces '\n' with '\0'). This breaks, among other things, the `yes' executable, and led to a runaway process in the testsuite that consumed my entire disk quota. A truss log of a stripped-down yes.c is attached, to show how putchar() is miscompiled when optimized. Is it worth putting a workaround into coreutils to accomodate this old platform/gcc combination, or should I just try again using the system cc or else upgrading gcc to the 3.x series? Thanks for the report. gcc-3.0 has been out for over 3 years, so I think it's not worth much trouble to work around that bug. But if you're interested, an autoconf run-test is probably the way to go. It'd make the configure script detect the problem and exit nonzero. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error occurred through 'make check'
Engel, Christian [EMAIL PROTECTED] wrote: ... gmake[3]: Entering directory `/home/cre/coreutils-5.2.1/tests/stty' FAIL: row-col-1 Thanks for the report. FYI, that was not a problem with stty, but rather with how one of Solaris' ioctls worked when rows or columns was set to zero. So that test should no longer fail in the latest test release. Here's the announcement: http://lists.gnu.org/archive/html/bug-coreutils/2005-01/msg00041.html ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.3.0: make check fails on NetBSD/sparc-1.5
Adrian Bunk [EMAIL PROTECTED] wrote:
...
FAIL: tail-tests
[test f-1 failed]
Thanks for the report.
Here's the fix I checked in yesterday:
(I'll update the comment)
2005-01-14 Jim Meyering [EMAIL PROTECTED]
The test, tests/tail/f-1, failed on powerpc-apple-darwin7.7.0.
* src/tail.c (IS_TAILABLE_FILE_TYPE): Adjust definition also to include
sockets, since that's what you get when reading from a command-line-
supplied pipe on Darwin 7.7.
(IS_PIPE_LIKE_FILE_TYPE): Define.
(main): Use new IS_PIPE_LIKE_FILE_TYPE rather than simply S_ISFIFO.
Reported by Nelson Beebe.
Index: src/tail.c
===
RCS file: /fetish/cu/src/tail.c,v
retrieving revision 1.231
retrieving revision 1.232
diff -u -p -u -r1.231 -r1.232
--- src/tail.c 4 Dec 2004 07:02:35 - 1.231
+++ src/tail.c 14 Jan 2005 16:30:15 - 1.232
@@ -1,5 +1,5 @@
/* tail -- output the last part of file(s)
- Copyright (C) 1989, 90, 91, 1995-2004 Free Software Foundation, Inc.
+ Copyright (C) 1989, 90, 91, 1995-2005 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -79,9 +79,14 @@ enum Follow_mode
Follow_descriptor = 2
};
+/* On Darwin 7.7, when reading from a command-line pipe, standard
+ input is of type S_ISSOCK. Everywhere else it's S_ISFIFO. */
+#define IS_PIPE_LIKE_FILE_TYPE(Mode) \
+ (S_ISFIFO (Mode) || S_ISSOCK (Mode))
+
/* The types of files for which tail works. */
#define IS_TAILABLE_FILE_TYPE(Mode) \
- (S_ISREG (Mode) || S_ISFIFO (Mode) || S_ISCHR (Mode))
+ (S_ISREG (Mode) || IS_PIPE_LIKE_FILE_TYPE (Mode) || S_ISCHR (Mode))
static char const *const follow_mode_string[] =
{
@@ -1650,7 +1655,8 @@ main (int argc, char **argv)
if (forever)
{
struct stat stats;
- if (fstat (STDIN_FILENO, stats) == 0 S_ISFIFO (stats.st_mode))
+ if (fstat (STDIN_FILENO, stats) == 0
+ IS_PIPE_LIKE_FILE_TYPE (stats.st_mode))
forever = false;
}
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BUG: cp command stops at 2,097,152KB
Bryan Rood [EMAIL PROTECTED] wrote: I am in dire straights. No matter what file I copy to my samba share, cp won't copy more than 2,097,152KB. Can you help me with this or point me to somewhere that explains why? Your coreutils package may have been built without largefile support or your destination file system may have a maximum file size of 2GB. Providing more details would help: the type of system you are running the `cp' command on: if the destination disk is not on the same machine, then what type of system hosts the remote disk: the destination disk uses what file system: version of cp (cp --version): Please try using rsync instead of cp and report the result. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: more 5.3.0 issues on cygwin
Eric Blake [EMAIL PROTECTED] wrote:
...
* src/od.c (OPENMODE): New macro.
(open_next_file): Use OPENMODE in fopen call.
...
Index: src/od.c
===
RCS file: /cvsroot/coreutils/coreutils/src/od.c,v
retrieving revision 1.152
diff -u -p -r1.152 od.c
--- src/od.c 28 Sep 2004 01:09:03 - 1.152
+++ src/od.c 17 Jan 2005 13:09:07 -
@@ -70,6 +70,12 @@ typedef unsigned long long int ulonglong
typedef unsigned long int ulonglong_t;
#endif
+#ifdef O_BINARY
+# define OPENMODE rb
+#else
+# define OPENMODE r
+#endif
+
enum size_spec
{
NO_SIZE,
@@ -906,7 +912,7 @@ open_next_file (void)
}
else
{
- in_stream = fopen (input_filename, r);
+ in_stream = fopen (input_filename, OPENMODE);
if (in_stream == NULL)
{
error (0, errno, %s, input_filename);
Why is that needed?
od.c already does this:
SET_BINARY (fileno (in_stream));
where that macro is defined in system.h:
#if O_BINARY
# ifndef __DJGPP__
# define setmode _setmode
# define fileno(_fp) _fileno (_fp)
# endif /* not DJGPP */
# define SET_MODE(_f, _m) setmode (_f, _m)
# define SET_BINARY(_f) do {if (!isatty(_f)) setmode (_f, O_BINARY);} while (0)
Maybe those #if directives don't work on your system?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failures in coreutils-5.3.0 on cygwin
Eric Blake [EMAIL PROTECTED] wrote: ... Also, I noticed some other tests in the suite that were sensitive to group names. At the moment, I'm not on the machine where I noticed all the problems, but off the top of my head, I remember that at least chown/separator was calling `id' directly rather than relying on group-names, and failing when id returned a space-separated name. If it is easy to fix the test, then let's do that. Otherwise, I'd welcome a change that makes it so affected tests are simply skipped when the only selected/found group name contains a space. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp --help
Johan Boule [EMAIL PROTECTED] wrote: in the output of cp --help, the line of --no-dereferrence should be merged with the line of -P, like: -P, --no-dereferrence never follow symbolic links Thanks for pointing that out. Now cp's --help output looks like this: Usage: ./cp [OPTION]... [-T] SOURCE DEST or: ./cp [OPTION]... SOURCE... DIRECTORY or: ./cp [OPTION]... -t DIRECTORY SOURCE... Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY. Mandatory arguments to long options are mandatory for short options too. -a, --archivesame as -dpR --backup[=CONTROL] make a backup of each existing destination file -b like --backup but does not accept an argument --copy-contents copy contents of special files when recursive -d same as --no-dereference --preserve=link -f, --force if an existing destination file cannot be opened, remove it and try again -i, --interactiveprompt before overwrite -H follow command-line symbolic links -l, --link link files instead of copying -L, --dereferencealways follow symbolic links -P --no-dereference never follow symbolic links -p same as --preserve=mode,ownership,timestamps --preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: links, all --no-preserve=ATTR_LIST don't preserve the specified attributes --parentsappend source path to DIRECTORY -R, -r, --recursive copy directories recursively ... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: more 5.3.0 issues on cygwin
Eric Blake [EMAIL PROTECTED] wrote: ... However, the Makefile.am patches are still important to allow the tests/help-version script to succeed without filling the disk (otherwise, you eval `args=$yes.exe_args', then run `yes.exe .exe_args' which runs away, rather than the intended `yes --version'). Likewise, the system.h patch is necessary for df (NTFS uses 1k blocks as captured in S_BLKSIZE, but without the patch, ST_NBLOCKSIZE defaults to 512, so sizes were 50% of their correct value). Thanks. I've applied those. 2005-01-17 Eric Blake [EMAIL PROTECTED] (tiny change) * src/Makefile.am (all_programs.list): Strip $(EXEEXT) and remove duplicates. * man/Makefile.am (all_programs): Revert previous patch; updated all_programs.list fixes this. (.x.1): No need to add $(EXEEXT). 2005-01-03 Corinna Vinschen [EMAIL PROTECTED] (tiny change) * src/system.h: Use S_BLKSIZE value for ST_NBLOCKSIZE where available. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 5.3.0: cp --parents broken
Andreas Schwab [EMAIL PROTECTED] wrote: $ ./cp --parents /bin/cp /tmp ./cp: failed to get attributes of `bin': No such file or directory Thanks for the report. I can't reproduce that: $ ./cp --parents /bin/cp /tmp $ find /tmp/bin /tmp/bin /tmp/bin/cp $ Would you please investigate it? Does your /bin have unusual permissions or attributes (a la lsattr or ACLs)? For example, what does strace -o log ./cp --parents /bin/cp /tmp put into the `log' file? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 5.3.0: cp --parents broken
Andreas Schwab [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Andreas Schwab [EMAIL PROTECTED] wrote:
$ ./cp --parents /bin/cp /tmp
./cp: failed to get attributes of `bin': No such file or directory
Thanks for the report.
I can't reproduce that:
Please make sure that /tmp/bin does not exist.
Ahh...
I should have known better.
I *can* reproduce it.
Here's the fix.
Thanks again for reporting that!
I'll add a test of `cp --parents' to exercise this.
2005-01-25 Jim Meyering [EMAIL PROTECTED]
* path-concat.c (path_concat): Set *BASE_IN_RESULT
properly when ABASE is an absolute file name.
Correct the description of this function.
Include assert.h.
Add an assertion and a test driver.
This fixes a bug introduced on 2004-07-02.
Andreas Schwab reported the resulting failure in cp --parents:
http://lists.gnu.org/archive/html/bug-coreutils/2005-01/msg00130.html
Index: lib/path-concat.c
===
RCS file: /fetish/cu/lib/path-concat.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -p -u -r1.21 -r1.22
--- path-concat.c 5 Jul 2004 08:41:13 - 1.21
+++ path-concat.c 25 Jan 2005 09:07:49 - 1.22
@@ -1,6 +1,6 @@
/* path-concat.c -- concatenate two arbitrary pathnames
- Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free
+ Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
Free
Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
@@ -22,6 +22,7 @@
#if HAVE_CONFIG_H
# include config.h
#endif
+# include assert.h
/* Specification. */
#include path-concat.h
@@ -54,7 +55,7 @@ longest_relative_suffix (char const *f)
Arrange for a directory separator if necessary between DIR and BASE
in the result, removing any redundant separators.
In any case, if BASE_IN_RESULT is non-NULL, set
- *BASE_IN_RESULT to point to the copy of BASE in the returned
+ *BASE_IN_RESULT to point to the copy of ABASE in the returned
concatenation.
Report an error if memory is exhausted. */
@@ -78,10 +79,49 @@ path_concat (char const *dir, char const
p += needs_separator;
if (base_in_result)
-*base_in_result = p;
+*base_in_result = p - IS_ABSOLUTE_FILE_NAME (abase);
p = mempcpy (p, base, baselen);
*p = '\0';
+ assert (!base_in_result
+ || strcmp (*base_in_result, abase) == 0);
+
return p_concat;
}
+
+#ifdef TEST_PATH_CONCAT
+#include stdlib.h
+#include stdio.h
+int
+main ()
+{
+ static char const *const tests[][3] =
+{
+ {a, b, a/b},
+ {a/, b, a/b},
+ {a/, /b, a/b},
+ {a, /b, a/b},
+
+ {/, b, /b},
+ {/, /b, /b},
+ {/, /, /},
+ {a, /, a/}, /* this might deserve a diagnostic */
+ {/a, /, /a/}, /* this might deserve a diagnostic */
+};
+ size_t i;
+ bool fail = false;
+ for (i = 0; i sizeof tests / sizeof tests[0]; i++)
+{
+ char *base_in_result;
+ char const *const *t = tests[i];
+ char *res = path_concat (t[0], t[1], base_in_result);
+ if (strcmp (res, t[2]) != 0)
+ {
+ printf (got %s, expected %s\n, res, t[2]);
+ fail = true;
+ }
+}
+ exit (fail ? EXIT_FAILURE : EXIT_SUCCESS);
+}
+#endif
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] bug in cygwin sys/termios.h?
Eric Blake [EMAIL PROTECTED] wrote: After further googling, it looks like there are several systems which have VSWTC instead of VSWTCH, but still initialize mode-c_cc[VSWTC] with CSWTCH [1]. The following patch fixes this situation for coreutils. It also silences some annoyances from cvs updates. 2005-01-29 Eric Blake [EMAIL PROTECTED] (tiny change) * .cvsignore: Ignore config.cache and config.status.lineno. * src/stty.c [VSWTCH]: Some systems, like Cygwin, use VSWTC instead of VSWTCH, for use with CSWTCH. Thanks. I've applied that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp command - problem with sparse
Eric Blake [EMAIL PROTECTED] wrote: ... According to the cygwin mailing list, http://sources.redhat.com/ml/cygwin/2005-02/msg00013.html, cygwin already supports sparse files when you do lseek beyond EOF during writes. The trick, however, is that NTFS on Windows XP does not create a hole until 128k. Therefore, this patch is needed in the testsuite to turn a SKIP into a PASS on cygwin: 2005-02-01 Eric Blake [EMAIL PROTECTED] (tiny change) * tests/du/8gb: Detect sparse files on NTFS under cygwin. Thanks. I've applied that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp command - problem with sparse
Andreas Schwab [EMAIL PROTECTED] wrote: Eric Blake [EMAIL PROTECTED] writes: Index: tests/du/8gb === RCS file: /cvsroot/coreutils/coreutils/tests/du/8gb,v retrieving revision 1.6 diff -u -p -r1.6 8gb --- tests/du/8gb 3 May 2003 14:24:37 - 1.6 +++ tests/du/8gb 2 Feb 2005 03:19:31 - @@ -26,7 +26,8 @@ fi # If this file system doesn't support sparse files, # don't try to create a file that'd end up consuming 8GB. # This happens on Darwin6.5 with a file system of type `hfs'. -dd bs=1 seek=64K of=t /dev/null 2 /dev/null +# NTFS requires 128K before a hole appears in a sparse file. +dd bs=1 seek=128K of=t /dev/null 2 /dev/null set x `du -sk t` if test $2 = 64; then ^^ Doesn't that need to be changed to 128 as well? Yes. Thanks. Fixed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp command - problem with sparse
Eric Blake [EMAIL PROTECTED] wrote: According to James Youngman on 2/1/2005 3:17 AM: Unix systems automatically generate sparse files when programs seek forwards on their output file. There is no need to have a sparse attribute. This is what coreutils' cp does. Right now, the tests/du/8gb test uses dd to try to create a sparse file; and strace'ing that on cygwin shows that it uses just lseek() followed by ftruncate() (no intervening write()). But the code in src/copy.c goes to great lengths to write() before calling ftruncate(), with the comment that the kernel would truncate the file at the end of the last write operation. Which is it? Is copy doing more work than it should, or should dd also be doing a write before truncate? POSIX does say that ftruncate shall increase the size of the file in XSI systems, but allows it return an error and keep the size unchanged on non-XSI systems. Well, to make that test case stop skipping on cygwin, we could apply the band-aid of simply using cp --sparse=always to copy the dd-created file. I'm reluctant to modify dd solely to accommodate Cygwin when it may be jumping on the XSI bandwagon soon anyhow, but if the change is not too ugly, I'll consider it. I ask, because at the moment, cygwin's implementation only makes a sparse file on write() after lseek(), although the developers are considering making ftruncate() after lseek() also create a sparse file. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I think I found a bug in the mv command
Ian MacGregor [EMAIL PROTECTED] wrote: I think I found a bug in the mv command. ... When I change line #9 in the bash script from mv /home/storage/backup.tar.gz /home/storage/`date +%Y%m%d-%k%M`-backup.tar.gz to mv /home/storage/backup.tar.gz /home/storage/`date +%Y%m%d-%I%M`-backup.tar.gz the command runs fine and the only output is below, and as a cronjob, it runs Thanks for the report, but that's not a bug in mv. Your date command is printing a space in the expansion of %k when the hour is a single digit number. That space makes it so `mv' sees three arguments, and provokes the diagnostic you reported. $ date --date='2005-02-04 02:00' +%Y%m%d-%k%M 20050204- 200 Use a format like %H that has zero-filled numbers. $ date --date='2005-02-04 02:00' +%Y%m%d-%H%M 20050204-0200 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#294206: stat(1) unclear about block size
Jeroen van Wolffelaar [EMAIL PROTECTED] wrote:
I've done a bit more reading and googling, and I found statvfs(2):
struct statvfs {
unsigned long f_bsize;/* file system block size */
unsigned long f_frsize; /* fragment size */
fsblkcnt_t f_blocks; /* size of fs in f_frsize units */
fsblkcnt_t f_bfree;/* # free blocks */
fsblkcnt_t f_bavail; /* # free blocks for non-root */
...
So, since statfs seems deprecated, and statvfs more informative (it
actually carries the units in which free and total size of filesystems
is written), I think it would be useful for stat to support statvfs,
which provides a superset of the functionality of statfs(2).
Does stat's --file-system (-f) option do what you want?
$ stat -f /
File: /
ID: 0Namelen: 255 Type: ext2/ext3
Blocks: Total: 1032080Free: 887328 Available: 834894 Size: 4096
Inodes: Total: 525312 Free: 490241
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#294206: stat(1) unclear about block size
Paul Eggert [EMAIL PROTECTED] wrote: This introduces a new format %S to stat -f -c. ... Jim, this is an incompatible change to the output of stat -f, since it changes the default format to output both block sizes. I think the change is useful, but if you think that's too drastic right now please let me know and I'll back this change out for now. It seems safe enough; I doubt many applications depend on the default output format. Thanks for doing that, and for the clean-up. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test fails on darwin
Sébastien Maret [EMAIL PROTECTED] wrote: I am trying to install coreutils-5.3.0 on my PowerBook. I am running MacOSX 10.3.8 (Darwin Kernel Version 7.8.0). The compilation goes well, but one of the test fails with the following message: make check [...] ... FAIL: nice PASS: pathchk1 Thanks for the report. If you could provide more detail, that'd help. Please rerun it like this cd tests/misc env VERBOSE=yes make check TESTS=nice and post the results. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in rm -rf
Geoffrey Odhner [EMAIL PROTECTED] wrote: I have encountered a bug with the rm command. If I unpack the coreutils-5.0 in a directory named .temp (I haven't tried any other names for this bug) and then from the parent of the .temp directory say: rm -rf .temp/ then I get the following message: rm: cannot remove directory `.temp//coreutils-5.0/lib': Directory not empty Then I say: rm -rf .temp/coreutils-5.0/ and it succeeds. On the other hand, if I initially say: rm -rf .temp then it works sometimes. I am running MacOS X 10.3.8 on a 667MHz PPC 15 Titanium PowerBook. Let me know if there is any other information I can provide to assist. Thanks for the report. That's due to a bug in their implementation of readdir. With the work-around in the latest test release, GNU rm works fine even there: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in pwd
Eric Blake [EMAIL PROTECTED] wrote: POSIX now requires pwd(1) to support -L and -P, that -L is the default, and that -L reads $PWD to verify that it is a name (possibly with symbolic links) of the current directory. Coreutils pwd currently implements none of this, and behaves as though -P is the default without ever reading $PWD. Thanks for reporting that. Do you feel like working on the parts that are possible? Furthermore, POSIX requires that when -P is specified, that $PWD be updated in the calling environment to scrub all symlinks from the environment variable that were previously set by a `cd -L' command. I see no possible way to implement that without relying on pwd(1) being a shell builtin. Bash 3.0 does not do this, I'm filing an additional bug in that direction. Is it worth coreutils even maintaining pwd(1) if it can't be fully POSIX-compliant? Until all shells provide a robust implementation of pwd, it is most certainly worth it to me. Try changing to a directory whose absolute name is longer than PATH_MAX, and then see what your favorite shell's built-in pwd functions does. zsh's implementation works. Bash's does not. Bash-3.00 gets this: shell-init: error retrieving current directory: getcwd: cannot access parent directories: File name too long pwd: error retrieving current directory: getcwd: cannot access parent directories: File name too long ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: avoiding unnecessary dependency on -lrt and -lpthread
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
gethrxtime uses clock_gettime on Linux systems (and any other system
without nanouptime), so such systems will get link errors for
clock_gettime if it's in a separate library like -lrt.
Sorry, I didn't test with new-enough GNU/Linux systems. I installed
this further patch to work around the problem. This is make check
tested with Debian GNU/Linux 3.0 and 3.1-beta (x86), Solaris 8 64-bit
sparc (Forte 6 cc), Solaris 9 32-bit sparc (Forte 7 c89), and OpenBSD
3.4 x86.
2005-02-21 Paul Eggert [EMAIL PROTECTED]
* m4/xnanosleep.m4: New file.
* lib/Makefile.am (libfetish_a_SOURCES): Remove xnanosleep.c,
xnanosleep.h; now done by ../m4/xnanosleep.m4 automatically.
* m4/gethrxtime.m4 (gl_PREREQ_GETHRXTIME): Require gl_CLOCK_TIME,
gl_USE_SYSTEM_EXTENSIONS. Check whether CLOCK_MONOTONIC is
defined, and set LIB_GETHRXTIME accordingly. This is needed
for newer GNU/Linux systems that have clock_gettime, so that they
link in the appropriate library for it when needed.
* m4/prereq.m4 (gl_PREREQ): Require gl_XNANOSLEEP.
* src/Makefile.am (dd_LDADD, shred_LDADD): Add $(LIB_GETHRXTIME).
(nanosec_libs): Add $(LIB_XNANOSLEEP). Needed for newer GNU/Linux
hosts with clock_gettime.
Hi Paul,
Thanks for doing that.
This all started with the lament, http://bugs.debian.org/122639,
that sleep(1) require linking with librt and hence libpthread
on a system with a Linux kernel.
Currently, coreutils' lib/xnanosleep.c needs -lrt solely to work
around a bug in the Linux kernel's implementation of nanosleep.
/* POSIX.1-2001 requires that when a process is suspended, then
resumed, nanosleep (A, B) returns -1, sets errno to EINTR, and sets
*B to the time remaining at the point of resumption. However, some
versions of the Linux kernel incorrectly return the time remaining
at the point of suspension. Work around this bug on GNU/Linux
hosts by computing the remaining time here after nanosleep returns,
rather than by relying on nanosleep's computation. */
#ifdef __linux__
enum { NANOSLEEP_BUG_WORKAROUND = true };
#else
enum { NANOSLEEP_BUG_WORKAROUND = false };
#endif
But it looks like that bug was fixed sometime between linux-2.6.8
(which has the bug) and linux-2.6.10, which apparently does not.
So if configure automatically detects whether xnanosleep needs the
workaround, binaries built for the newer systems won't have to use
the work-around code or -lrt.
I've written a test program to do that and will post it separately, to
[EMAIL PROTECTED] That exercise led me to discover that a variant of
this Linux kernel bug makes sleep malfunction, at least on linux-2.6.8.1
systems. Sleep fails when suspended and then resumed on such systems:
$ sleep 9 pid=$!
[1] 6451
$ kill -TSTP $pid; kill -CONT $pid
sleep: cannot read realtime clock
[1]+ Exit 1 sleep 9
We can fix it with this patch:
2005-02-27 Jim Meyering [EMAIL PROTECTED]
* xnanosleep.c (xnanosleep): Work around bug in Linux-2.6.8.1's
nanosleep whereby it fails without setting errno upon being resumed
after being suspended.
Index: lib/xnanosleep.c
===
RCS file: /fetish/cu/lib/xnanosleep.c,v
retrieving revision 1.11
diff -u -p -r1.11 xnanosleep.c
--- lib/xnanosleep.c21 Feb 2005 08:10:47 - 1.11
+++ lib/xnanosleep.c25 Feb 2005 23:46:23 -
@@ -123,9 +123,10 @@ xnanosleep (double seconds)
ts_sleep.tv_nsec = BILLION - 1;
}
+ errno = 0;
if (nanosleep (ts_sleep, NULL) == 0)
break;
- if (errno != EINTR)
+ if (errno != EINTR errno != 0)
return -1;
if (NANOSLEEP_BUG_WORKAROUND)
I'll probably check that in. The alternative is to provide
a nanosleep wrapper that sets errno in this case. But the
only uses of nanosleep in coreutils are through xnanosleep,
so it's probably not worth it, there.
If any of you know of a package that uses nanosleep where
this would matter, please provide details.
Jim
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
¤´Æ [EMAIL PROTECTED] wrote:
Hello. I have a question for cp tools.
CP tool is so convenient for make processing, but I¡¯ve had trouble with
copying some files.
cp: will not overwrite just-created `../../1H/uimdrv.h' with
`../../services/uim/uimdrv.h'
cp: will not overwrite just-created `../../1H/sisdecoder.h' with
`../../midp/sisdecoder.h'
That is a feature of cp that is designed to prevent
accidental data loss in a case like yours:
$ mkdir a b c
$ touch {a,b}/important.h
$ cp a/*.h b/*.h c
cp: will not overwrite just-created `c/important.h' with `b/important.h'
So, you have at least two pairs of header files with the same name
but in different directories.
If you really want to use only one copy of such a file (maybe they're
identical), you can use cp's --backup option, and you'll find important.h
and important.h~ in the destination directory. However, it's almost
always better to avoid having identically-named files.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
$ mkdir a b c
$ touch {a,b}/important.h
$ cp a/*.h b/*.h c
cp: will not overwrite just-created `c/important.h' with `b/important.h'
Hmm, does POSIX allow this behavior? I just visited
http://www.opengroup.org/onlinepubs/95399/utilities/cp.html and
it gives a pretty-specific algorithm that requires cp A B D/. to be
equivalent to cp A D/.; cp B D/..
Similarly for mv.
I assume that behavior is in there because somebody got burned one
day, and it seems like a nice feature to have. But if it doesn't
conform to POSIX, we need to either fix POSIX or change the code
somehow.
Right. My motivation for adding this `feature' was to prevent
`mv a/* b/* dir' from destroying (silently!) user data. By the
same token, a successful invocation of `cp a/* b/* dir' might well
be followed by rm -rf a b.
It's be nice to fix POSIX.
Here's the NEWS item from fileutils-4.1.1 (November 3, 2001):
* mv (likewise for cp), now fails rather than silently clobbering one of
the source files in the following example:
rm -rf a b c; mkdir a b c; touch a/f b/f; mv a/f b/f c
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Hi Bob, I've noticed that my use of `source' below might be misunderstood. Here's a snippet from the documentation that should help: mv [OPTION]... SOURCE DEST mv [OPTION]... SOURCE... DIRECTORY [EMAIL PROTECTED] (Bob Proulx) wrote: ... I know this is one of the features that you really like. Hmm... I wouldn't go that far :) I think it's a worthwhile feature, since it can help naive or careless users avoid accidentally destroying their SOURCE files. I often have cases where I have duplicate files here and there in a directory tree. For various reasons I want to move them to the archive. If they are named the same they have the same contents so I only want to keep exactly one copy of them. So I want mv */*/foo ../ARCHIVE/ mv $(find . -name foo -print)../ARCHIVE/ to move those files to the target directory. But of course with the duplicate check in place that fails. So then I started using a for loop so that it would be different mv commands. for f in */*/foo; do mv $f ../ARCHIVE/ In general, you can add mv's --backup option: mv --backup=numbered */*/foo ../ARCHIVE/ then you'll find like-named files with suffixes like .~1~, .~2~, etc. in your ARCHIVE directory. Personally, I've been happy to have mv aliased to `mv --backup=numbered' for as long as GNU mv has had that option. Of course, if they're really all the same, you won't want to archive the ~-backup files. That works but is a lot of typing. If the -f option forced the move then I would be happy with that. The documentation explicitly says it will overwrite files. -f, --force do not prompt before overwriting (equivalent to --reply=yes) Well, we can't really use -f/--force, because -f has POSIX-specified behavior controlling whether mv prompts -- not whether it refuses to do something that might be confusing. Besides, --force applies to *destination* files, which is a little ambiguous in this case, since a SOURCE file is moved to its destination, and later mv sees that renamed SOURCE file as the destination for another move. * mv (likewise for cp), now fails rather than silently clobbering one of the source files in the following example: rm -rf a b c; mkdir a b c; touch a/f b/f; mv a/f b/f c (Don't read too much sarcasm into this next statement.) I am hoping there are no plans to make this fail. touch foo bar mv foo bar Because currently that also silently clobbers files. But that is just the way I like it! :-) The key phrase above is `clobbering one of the *SOURCE* files'. The difference is that `mv foo bar' unlinks a *destination* file, which is what everyone expects mv to do. Few realize that a POSIX-compliant mv can sometimes clobber *SOURCE* files, too. Jim ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
[EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: I've noticed that my use of `source' below might be misunderstood. Here's a snippet from the documentation that should help: mv [OPTION]... SOURCE DEST mv [OPTION]... SOURCE... DIRECTORY I can see that you are emphasizing the difference between the set of source and the set of destination files and the rules applied to those two difference sets. However, fundamentally why are they different? I don't think they should be treated differently. People just `know' that preexisting destination files may be modified or removed. The manual says that, too :) The manual doesn't warn about the possibility of `mv' removing SOURCE files in some unusual cases, and doing so would seem too much like breaking an implicit contract. Note that I have never heard discussion of this with 'cp' but only with 'mv'. Fundamentally I think 'mv' and 'cp' are conceptually different. True, but sometimes people perform a move-like operation via commands like cp SOURCE... dest ... rm -rf SOURCE..., so the same logic applies. In general, you can add mv's --backup option: mv --backup=numbered */*/foo ../ARCHIVE/ So, why does --backup=numbered work but --backup=simple fail? Because detecting when --backup=simple would be safe looked like it'd be too much trouble to be worthwhile, and besides, adding code to do that would impact the usual case by increasing the size of the F_triple struct. Or we could add more code and a separate, much smaller, table just to remember names of files that are overwritten two or more times -- but that would be overkill, even if you ignored the complications of the fourth backup type (`existing' can lead to simple or numbered backups) and the fact that the new table would have to be initialized in every caller of copy (mv, cp, install). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Paul Eggert [EMAIL PROTECTED] writes: OK, I've just submitted an Aardvark for this to the POSIX folks (my reference number 20050304a). ... https://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-review-lid=1907 Thanks for doing that! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp: .snapshot/xxx and xxx are identical'
Tim Waugh [EMAIL PROTECTED] wrote: A Netapp NFS server containing a file (xxx) and a snapshot of the file (.snapshot/xxx) will give them the same inode number. Unfortunately, 'cp .snapshot/xxx xxx' (in order to recover the snapshot version) fails with '... are identical' due to the inode check. Is there some way of bypassing this check? Yes. Use cp's --backup (-b) option. Then, cp can be sure that opening the destination file (for writing) will not destroy the source file. Using --backup has the added advantage that the destination file is replaced atomically (via rename), rather than being rewritten in place. More importantly, is there something in POSIX which says that this check is allowed in the first place? Yes. NetApp's doing that (letting two different files have the same dev/inode numbers) is not POSIX compliant. Quoting from http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html: The st_ino and st_dev fields taken together uniquely identify the file within the system. That said, it might be worthwhile to change the SAME_INODE checks in copy.c to also check same_file_attributes, where that macro is defined like this (from diffutils/src/system.c): /* Do struct stat *S, *T have the same file attributes? POSIX says that two files are identical if st_ino and st_dev are the same, but many filesystems incorrectly assign the same (device, inode) pair to two distinct files, including: - GNU/Linux NFS servers that export all local filesystems as a single NFS filesystem, if a local device number (st_dev) exceeds 255, or if a local inode number (st_ino) exceeds 16777215. - Network Appliance NFS servers in snapshot directories; see Network Appliance bug #195. - ClearCase MVFS; see bug id ATRia04618. Check whether two files that purport to be the same have the same attributes, to work around instances of this common bug. Do not inspect all attributes, only attributes useful in checking for this bug. It's possible for two distinct files on a buggy filesystem to have the same attributes, but it's not worth slowing down all implementations (or complicating the configuration) to cater to these rare cases in buggy implementations. */ #ifndef same_file_attributes # define same_file_attributes(s, t) \ ((s)-st_mode == (t)-st_mode \ (s)-st_nlink == (t)-st_nlink \ (s)-st_uid == (t)-st_uid \ (s)-st_gid == (t)-st_gid \ (s)-st_size == (t)-st_size \ (s)-st_mtime == (t)-st_mtime \ (s)-st_ctime == (t)-st_ctime) #endif ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp: .snapshot/xxx and xxx are identical'
Jim Meyering [EMAIL PROTECTED] wrote:
...
That said, it might be worthwhile to change the SAME_INODE checks
in copy.c to also check same_file_attributes, where that macro
is defined like this (from diffutils/src/system.c):
Can someone make sure this patch works and let me know?
Just apply it, build cp, and then run a command like
./cp .snapshot/F F
for some file F, on a NetApp-backed file system.
The above command should succeed, while using an
unpatched `cp' should fail.
2005-03-07 Jim Meyering [EMAIL PROTECTED]
Work around POSIX non-compliance of certain file systems so that
using e.g., an Network Appliance server via NFS, cp .snapshot/F F
no longer fails with a diagnostic that the files are the same,
even though the device and inode numbers of .snapshot/F and F are
identical.
* src/copy.c (same_file_ok): Use a stricter test for whether
two stat buffers correspond to the same file system object.
* src/system.h (SAME_FILE_ATTRIBUTES): New macro, from diffutils.
(SAME_INODE_AND_ATTRS): New macro.
Index: src/system.h
===
RCS file: /fetish/cu/src/system.h,v
retrieving revision 1.100
diff -u -p -r1.100 system.h
--- src/system.h3 Feb 2005 21:34:34 - 1.100
+++ src/system.h7 Mar 2005 13:44:41 -
@@ -566,6 +566,45 @@ uid_t getuid ();
((Stat_buf_1).st_ino == (Stat_buf_2).st_ino \
(Stat_buf_1).st_dev == (Stat_buf_2).st_dev)
+/* Do struct stat *S, *T have the same file attributes?
+
+ POSIX says that two files are identical if st_ino and st_dev are
+ the same, but many filesystems incorrectly assign the same (device,
+ inode) pair to two distinct files, including:
+
+ - GNU/Linux NFS servers that export all local filesystems as a
+ single NFS filesystem, if a local device number (st_dev) exceeds
+ 255, or if a local inode number (st_ino) exceeds 16777215.
+
+ - Network Appliance NFS servers in snapshot directories; see
+ Network Appliance bug #195.
+
+ - ClearCase MVFS; see bug id ATRia04618.
+
+ Check whether two files that purport to be the same have the same
+ attributes, to work around instances of this common bug. Do not
+ inspect all attributes, only attributes useful in checking for this
+ bug.
+
+ It's possible for two distinct files on a buggy filesystem to have
+ the same attributes, but it's not worth slowing down all
+ implementations (or complicating the configuration) to cater to
+ these rare cases in buggy implementations. */
+
+#ifndef SAME_FILE_ATTRIBUTES
+# define SAME_FILE_ATTRIBUTES(s, t) \
+ ((s)-st_mode == (t)-st_mode \
+ (s)-st_nlink == (t)-st_nlink \
+ (s)-st_uid == (t)-st_uid \
+ (s)-st_gid == (t)-st_gid \
+ (s)-st_size == (t)-st_size \
+ (s)-st_mtime == (t)-st_mtime \
+ (s)-st_ctime == (t)-st_ctime)
+#endif
+
+#define SAME_INODE_AND_ATTRS(SB1, SB2) \
+ (SAME_INODE (SB1, SB2) SAME_FILE_ATTRIBUTES ((SB1), (SB2)))
+
#define DOT_OR_DOTDOT(Basename) \
(Basename[0] == '.' (Basename[1] == '\0' \
|| (Basename[1] == '.' Basename[2] == '\0')))
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.175
diff -u -p -r1.175 copy.c
--- src/copy.c 1 Mar 2005 12:27:47 - 1.175
+++ src/copy.c 7 Mar 2005 13:42:50 -
@@ -449,7 +449,7 @@ same_file_ok (const char *src_path, cons
struct stat tmp_src_sb;
bool same_link;
- bool same = SAME_INODE (*src_sb, *dst_sb);
+ bool same = SAME_INODE_AND_ATTRS (*src_sb, *dst_sb);
*return_now = false;
*unlink_src = false;
@@ -490,7 +490,7 @@ same_file_ok (const char *src_path, cons
src_sb_link = tmp_src_sb;
dst_sb_link = tmp_dst_sb;
- same_link = SAME_INODE (*src_sb_link, *dst_sb_link);
+ same_link = SAME_INODE_AND_ATTRS (*src_sb_link, *dst_sb_link);
/* If both are symlinks, then it's ok, but only if the destination
will be unlinked before being opened. This is like the test
@@ -583,7 +583,7 @@ same_file_ok (const char *src_path, cons
hard links to the same file. */
if (!S_ISLNK (src_sb_link-st_mode) !S_ISLNK (dst_sb_link-st_mode))
{
- if (!SAME_INODE (*src_sb_link, *dst_sb_link))
+ if (!SAME_INODE_AND_ATTRS (*src_sb_link, *dst_sb_link))
return true;
/* If they are the same file, it's ok if we're making hard links. */
@@ -613,7 +613,7 @@ same_file_ok (const char *src_path, cons
else if (stat (dst_path, tmp_dst_sb))
return true;
- if ( ! SAME_INODE (tmp_src_sb, tmp_dst_sb))
+ if ( ! SAME_INODE_AND_ATTRS (tmp_src_sb, tmp_dst_sb))
return true;
/* FIXME: shouldn't this be testing whether we're making symlinks? */
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo
Re: 'cp: .snapshot/xxx and xxx are identical'
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Can someone make sure this patch works and let me know? Just apply it, build cp, and then run a command like ./cp .snapshot/F F for some file F, on a NetApp-backed file system. The above command should succeed, while using an unpatched `cp' should fail. I just tried it on a Solaris 8 host with a remote NetApp filesystem, and it sort of worked, but it had problems. Thanks for the quick work! 1. Patched GNU cp .snapshot/weekly.1/F F fails if F has not been changed since the snapshot. It succeeds only if F has changed. This is pretty weird, especially if you do cp .snapshot/weekly.1/* . and get a bunch of error messages for your unchanged files. 2. Solaris 8 cp .snapshot/weekly.1/F F fails regardless of whether F has changed, with these symptoms: $ /bin/cp -p .snapshot/weekly.1/rcs-5.7.tar.gz rcs-5.7.tar.gz cp: .snapshot/weekly.1/rcs-5.7.tar.gz and rcs-5.7.tar.gz are identical So if we make this change to GNU cp, it won't be compatible with Solaris cp. If you are motivated, you might be able to find a solution yourself. You could try comparing the entire `struct stat's of two file/snapshot pairs, one where the snapshot is the same, the other where it differs, in the hopes that there will be something obvious that distinguishes the two cases. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chown fails to ignore symbolic links during recursive directory transversals
Mark Brand [EMAIL PROTECTED] wrote: [This is a correction of my last e-mail that incorrectly referred to chmod instead of chown in a couple of places. This report is about chown. Sorry about that.] I hope I'm not making a fool of myself, but here we go: version: coreutils-5.2.1-3.rpm (from SuSE 9.2). Linux kernel 2.6.11.1. reiserfs. Thanks for the report. However, I cannot reproduce that behavior with unmodified coreutils-5.2.1 built and run on a Debian/GNU unstable system with Linux kernel 2.6.11. Here's a small example: $ mkdir a b $ ln -s ../b a/sub $ sudo /bin/chown -R --verbose root a changed ownership of `a' to root changed ownership of `a/sub' to root $ ls -od a b drwxr-xr-x 2 root 60 Mar 9 19:36 a drwxr-xr-x 2 meyering 40 Mar 9 19:36 b Maybe SuSE's version has changes that make it work differently? Or (more likely) SuSE configured/built using a kernel/libc with different chown/lchown semantics than what you're currently using. That is one of the risks of using pre-compiled packages (with configure-time run-tests) on newer versions of an OS. Recompile it on your current system, and it may well work as documented. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: factored integer properties into intprops.h
Paul Eggert [EMAIL PROTECTED] wrote: I factored out various places in gnulib that refer to integer properties like TYPE_MAXIMUM and INT_STRLEN_BOUND, and put them into a common file intprops.h. I installed this patch into gnulib and will do the same to coreutils shortly. The only developer-visible change should be the new file lib/intprops.h. I used 146/485 by popular request. However, I didn't have INT_STRLEN_BOUND refer to TYPE_SIGNED, as that broke some code in coreutils that applied INT_STRLEN_BOUND to a value, not to a type. I think this usage is useful enough that we should continue to support it, so I documented it. Thanks for all of that. I've made the following additional changes (only in coreutils for now), any one of which would have been enough to ensure that intprops.h is included in the coreutils distribution: 2005-03-10 Jim Meyering [EMAIL PROTECTED] * human.m4 (gl_HUMAN): Add intprops.h. * inttostr.m4 (gl_INTTOSTR): Likewise * sig2str.m4 (gl_FUNC_SIG2STR): Likewise. * userspec.m4 (gl_USERSPEC): Likewise. * utimecmp.m4 (gl_UTIMECMP): Likewise. * xnanosleep.m4 (gl_XNANOSLEEP): Likewise. * xstrtol.m4 (gl_XSTRTOL): Use AC_LIBSOURCES and AC_LIBOBJ to list the required files. Index: m4/human.m4 === RCS file: /fetish/cu/m4/human.m4,v retrieving revision 1.6 retrieving revision 1.7 diff -u -p -u -r1.6 -r1.7 --- m4/human.m4 29 Jan 2005 00:16:39 - 1.6 +++ m4/human.m4 9 Mar 2005 23:02:25 - 1.7 @@ -1,4 +1,4 @@ -# human.m4 serial 8 +#serial 9 dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -6,7 +6,7 @@ dnl with or without modifications, as lo AC_DEFUN([gl_HUMAN], [ - AC_LIBSOURCES([human.c, human.h]) + AC_LIBSOURCES([human.c, human.h, intprops.h]) AC_LIBOBJ([human]) dnl Prerequisites of lib/human.h. Index: m4/inttostr.m4 === RCS file: /fetish/cu/m4/inttostr.m4,v retrieving revision 1.4 retrieving revision 1.5 diff -u -p -u -r1.4 -r1.5 --- m4/inttostr.m4 11 Feb 2005 20:27:16 - 1.4 +++ m4/inttostr.m4 9 Mar 2005 23:03:42 - 1.5 @@ -1,4 +1,4 @@ -# inttostr.m4 serial 4 +#serial 5 dnl Copyright (C) 2004, 2005 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -6,7 +6,7 @@ dnl with or without modifications, as lo AC_DEFUN([gl_INTTOSTR], [ - AC_LIBSOURCES([inttostr.c, inttostr.h]) + AC_LIBSOURCES([inttostr.c, inttostr.h, intprops.h]) dnl We don't technically need to list the following .c files, since their dnl functions are named in the AC_LIBOBJ calls, but this is an unusual Index: m4/sig2str.m4 === RCS file: /fetish/cu/m4/sig2str.m4,v retrieving revision 1.3 retrieving revision 1.4 diff -u -p -u -r1.3 -r1.4 --- m4/sig2str.m4 29 Jan 2005 00:16:39 - 1.3 +++ m4/sig2str.m4 9 Mar 2005 23:04:47 - 1.4 @@ -1,4 +1,4 @@ -# sig2str.m4 serial 3 +#serial 4 dnl Copyright (C) 2002, 2005 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -6,7 +6,7 @@ dnl with or without modifications, as lo AC_DEFUN([gl_FUNC_SIG2STR], [ - AC_LIBSOURCES([sig2str.c, sig2str.h]) + AC_LIBSOURCES([sig2str.c, sig2str.h, intprops.h]) AC_REPLACE_FUNCS(sig2str) if test $ac_cv_func_sig2str = no; then Index: m4/userspec.m4 === RCS file: /fetish/cu/m4/userspec.m4,v retrieving revision 1.5 retrieving revision 1.6 diff -u -p -u -r1.5 -r1.6 --- m4/userspec.m4 29 Jan 2005 00:16:39 - 1.5 +++ m4/userspec.m4 9 Mar 2005 23:05:32 - 1.6 @@ -1,4 +1,4 @@ -# userspec.m4 serial 6 +#serial 7 dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -6,7 +6,7 @@ dnl with or without modifications, as lo AC_DEFUN([gl_USERSPEC], [ - AC_LIBSOURCES([userspec.c, userspec.h]) + AC_LIBSOURCES([userspec.c, userspec.h, intprops.h]) AC_LIBOBJ([userspec]) dnl Prerequisites of lib/userspec.c. Index: m4/utimecmp.m4 === RCS file: /fetish/cu/m4/utimecmp.m4,v retrieving revision 1.3 retrieving revision 1.4 diff -u -p -u -r1.3 -r1.4 --- m4/utimecmp.m4 29 Jan 2005 00:16:39 - 1.3 +++ m4/utimecmp.m4 9 Mar 2005 23:06:16 - 1.4 @@ -1,3 +1,4 @@ +#serial 1 dnl Copyright (C) 2004, 2005 Free Software
Re: [bug-grep] Re: length of dec. representation of a number
[EMAIL PROTECTED] (Paul Jarc) wrote: Paul Eggert [EMAIL PROTECTED] wrote: /* Bound on length of the string representing an integer value or type T. Subtract 1 for the sign bit if t is signed; log10 (2.0) 146/485; add 1 for integer division truncation; add 1 more for a minus sign if needed. */ #define INT_STRLEN_BOUND(t) \ ((sizeof (t) * CHAR_BIT - 1) * 146 / 485 + 2) I guess that should be: #define INT_STRLEN_BOUND(t) \ ((sizeof (t) * CHAR_BIT - TYPE_SIGNED(t)) * 146 / 485 + TYPE_SIGNED(t) + 1) Technically, yes, but that would prohibit applying that macro to variables, which is useful. Currently there are uses like that in the coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
FYI: fix stack overflow in pr
FYI, I found that making pr use a very long date string in its
header would overflow the stack:
2005-03-10 Jim Meyering [EMAIL PROTECTED]
Don't segfault for a long header date string, e.g.,
echo a|pr -D +%999A
* src/pr.c (init_header): Use x2nrealloc, rather than alloca.
Don't bother with fixed-sized initial buffer; always use x*alloc.
Index: src/pr.c
===
RCS file: /fetish/cu/src/pr.c,v
retrieving revision 1.128
retrieving revision 1.129
diff -u -p -u -r1.128 -r1.129
--- src/pr.c10 Mar 2005 07:58:34 - 1.128
+++ src/pr.c10 Mar 2005 08:51:49 - 1.129
@@ -1657,8 +1657,7 @@ print_files (int number_of_files, char *
static void
init_header (char *filename, int desc)
{
- char *buf;
- char initbuf[MAX (256, INT_BUFSIZE_BOUND (long int))];
+ char *buf = NULL;
struct stat st;
struct tm *tm;
@@ -1668,25 +1667,27 @@ init_header (char *filename, int desc)
if (desc 0 || fstat (desc, st) != 0)
st.st_mtime = time (NULL);
- buf = initbuf;
tm = localtime (st.st_mtime);
- if (! tm)
-sprintf (buf, %ld, (long int) st.st_mtime);
+ if (tm == NULL)
+{
+ buf = xmalloc (INT_BUFSIZE_BOUND (long int));
+ sprintf (buf, %ld, (long int) st.st_mtime);
+}
else
{
- size_t bufsize = sizeof initbuf;
+ size_t bufsize = 0;
for (;;)
{
+ buf = x2nrealloc (buf, bufsize, sizeof *buf);
*buf = '\1';
- if (strftime (buf, bufsize, date_format, tm) || ! *buf)
+ if (strftime (buf, bufsize, date_format, tm) || *buf == '\0')
break;
- buf = alloca (bufsize *= 2);
}
}
if (date_text)
free (date_text);
- date_text = xstrdup (buf);
+ date_text = buf;
file_text = custom_header ? custom_header : desc 0 ? : filename;
header_width_available = (chars_per_line
- mbswidth (date_text, 0)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
FYI: format string can cause stack overflow in ls
A mischievously chosen format string can make ls overflow its stack.
Format strings can come from the command line, or via gettext.
Note however, that the new code below will rarely be used in practice,
since the initial, non-malloc'd, array sizes are so conservatively sized.
On one system I checked, sizeof init_bigbuf is over 2600.
2005-03-10 Jim Meyering [EMAIL PROTECTED]
Don't segfault for a very long date format string, e.g.,
ls -ld --time-style=+%H .
* src/ls.c (long_time_expected_width): Use x2nrealloc, not alloca,
so format string abuse cannot provoke stack overflow.
(print_long_format): Likewise.
Index: ls.c
===
RCS file: /fetish/cu/src/ls.c,v
retrieving revision 1.375
diff -u -p -r1.375 ls.c
--- ls.c6 Mar 2005 16:31:51 - 1.375
+++ ls.c10 Mar 2005 12:06:42 -
@@ -3059,12 +3059,20 @@ long_time_expected_width (void)
len = nstrftime (buf, bufsize, fmt, tm, 0, 0);
if (len || ! *buf)
break;
- buf = alloca (bufsize *= 2);
+ if (buf == initbuf)
+ {
+ buf = NULL;
+ bufsize *= 2;
+ }
+ buf = x2nrealloc (buf, bufsize, sizeof *buf);
}
width = mbsnwidth (buf, len, 0);
if (width 0)
width = 0;
+
+ if (buf != initbuf)
+ free (buf);
}
return width;
@@ -3349,8 +3357,16 @@ print_long_format (const struct fileinfo
when_local, 0, when_ns);
if (s || ! *p)
break;
- newbuf = alloca (bufsize *= 2);
- memcpy (newbuf, buf, p - buf);
+ if (buf == init_bigbuf)
+ {
+ bufsize *= 2;
+ newbuf = xmalloc (bufsize);
+ memcpy (newbuf, buf, p - buf);
+ }
+ else
+ {
+ newbuf = x2nrealloc (buf, bufsize, sizeof *buf);
+ }
p = newbuf + (p - buf);
buf = newbuf;
}
@@ -3374,6 +3390,8 @@ print_long_format (const struct fileinfo
}
DIRED_FPUTS (buf, stdout, p - buf);
+ if (buf != init_bigbuf)
+free (buf);
print_name_with_quoting (f-name, FILE_OR_LINK_MODE (f), f-linkok,
dired_obstack);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-grep] Re: length of dec. representation of a number
[EMAIL PROTECTED] (Paul Jarc) wrote: Jim Meyering [EMAIL PROTECTED] wrote: Technically, yes, but that would prohibit applying that macro to variables, which is useful. Currently there are uses like that in the coreutils. Ah - well, it's easy enough to factor, so you'd have to specify the signedness explicitly for variables, but it would be automatically detected for types. #define INT_STRLEN_BOUND_VAR(t, signedness) ... #define INT_STRLEN_BOUND_TYPE(t) INT_STRLEN_BOUND_VAR(t, TYPE_SIGNED(t)) I don't see the benefit. Having to specify signedness makes it unmaintainable. It'd be too easy to get wrong, or (more likely) to render incorrect with a subsequent variable type change. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv and hard links
[EMAIL PROTECTED] (Eric Blake) wrote:
This may be worthy of raising an issue with the austin group, but I
thought I'd ask here first. A complaint was raised on the cygwin list
that the following sequence had no interactive prompt:
$ uname
CYGWIN_NT-5.0
$ touch a
$ ln a b
$ mv -i a b
$ echo $?
0
$ mv --version | head -n 1
mv (GNU coreutils) 5.3.0
Thanks for forwarding that.
It's a bug.
Here's a patch:
Prompt once again for `mv -i A B' when A and B are hard links
to the same file. This fixes a bug introduced by my 2003-04-04
(coreutils-5.0.1) change.
* src/copy.c (abandon_move): New function, factored out of
copy_internal, now that this code is being used from two places.
(copy_internal): Perform the same interactive-related test for
whether it's alright to proceed and (usually) overwrite the
destination file.
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.175
diff -u -p -r1.175 copy.c
--- src/copy.c 1 Mar 2005 12:27:47 - 1.175
+++ src/copy.c 10 Mar 2005 21:20:51 -
@@ -792,6 +792,28 @@ record_file (Hash_table *ht, char const
}
}
+/* When effecting a move (e.g., for mv(1)), and given the name DST_PATH
+ of the destination and a corresponding stat buffer, DST_SB, return
+ true if the logical `move' operation should not proceed.
+ Return true if it may proceed.
+ Depending on options specified in X, this code may issue an
+ interactive prompt asking whether it's ok to overwrite DST_PATH. */
+static bool
+abandon_move (const struct cp_options *x,
+ char const *dst_path,
+ struct stat const *dst_sb)
+{
+ assert (x-move_mode);
+ return ((x-interactive == I_ALWAYS_NO
+UNWRITABLE (dst_path, dst_sb-st_mode))
+ || ((x-interactive == I_ASK_USER
+ || (x-interactive == I_UNSPECIFIED
+x-stdin_tty
+UNWRITABLE (dst_path, dst_sb-st_mode)))
+ (overwrite_prompt (dst_path, dst_sb), 1)
+ ! yesno ()));
+}
+
/* Copy the file SRC_PATH to the file DST_PATH. The files may be of
any type. NEW_DST should be true if the file DST_PATH cannot
exist because its parent directory was just created; NEW_DST should
@@ -887,7 +909,8 @@ copy_internal (const char *src_path, con
x, return_now, unlink_src);
if (unlink_src)
{
- if (unlink (src_path))
+ if (!abandon_move (x, dst_path, dst_sb)
+ unlink (src_path))
{
error (0, errno, _(cannot remove %s), quote (src_path));
return false;
@@ -980,14 +1003,7 @@ copy_internal (const char *src_path, con
/* cp and mv treat -i and -f differently. */
if (x-move_mode)
{
- if ((x-interactive == I_ALWAYS_NO
- UNWRITABLE (dst_path, dst_sb.st_mode))
- || ((x-interactive == I_ASK_USER
- || (x-interactive == I_UNSPECIFIED
- x-stdin_tty
- UNWRITABLE (dst_path, dst_sb.st_mode)))
- (overwrite_prompt (dst_path, dst_sb), 1)
- ! yesno ()))
+ if (abandon_move (x, dst_path, dst_sb))
{
/* Pretend the rename succeeded, so the caller (mv)
doesn't end up removing the source file. */
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: a memory bug in stat.c
Guochun Shi [EMAIL PROTECTED] wrote:
I ran stat -c %s filename and get segmentation fault. I found there is a
bug, here is a patch to fix it.
diff -u stat.c.old stat.c
--- stat.c.old 2003-03-22 16:32:02.0 -0600
+++ stat.c 2005-03-11 16:51:37.0 -0600
@@ -554,7 +554,7 @@
/* create a working copy of the format string */
char *format = xstrdup (masterformat);
- char *dest = xmalloc (strlen (format) + 1);
+ char *dest = xmalloc (strlen (format) + 3);
b = format;
Thank you for the report and patch.
I've applied it, along with the following separate patch that
should make it harder to introduce such bugs in the future.
2005-03-12 Jim Meyering [EMAIL PROTECTED]
Add a little infrastructure to help prevent future bugs like the
one fixed below.
* src/stat.c (xstrcat): New function.
(print_statfs, print_stat): Add buf_len parameter and convert all
uses of strcat to xstrcat. Update callers.
(print_it): Call print_func with buf_len parameter.
Invoking stat -c FMT with a lone format directive of %s, %f, %h, %s,
etc. could cause a buffer overrun error.
* src/stat.c (print_it): Allocate 2 more bytes, to accommodate our
conversion of the stat %s format string to the longer printf %llu one.
Patch from Guochun Shi.
Index: src/stat.c
===
RCS file: /fetish/cu/src/stat.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -p -u -r1.81 -r1.82
--- src/stat.c 12 Mar 2005 10:54:20 - 1.81
+++ src/stat.c 12 Mar 2005 10:59:23 - 1.82
@@ -295,9 +295,22 @@ human_time (time_t t, int t_ns)
return str;
}
+/* Like strcat, but don't return anything and do check that
+ DEST_BUFSIZE is at least a long as strlen (DEST) + strlen (SRC) + 1.
+ The signature is deliberately different from that of strncat. */
+static void
+xstrcat (char *dest, size_t dest_bufsize, char const *src)
+{
+ size_t dest_len = strlen (dest);
+ size_t src_len = strlen (src);
+ if (dest_bufsize dest_len + src_len + 1)
+abort ();
+ memcpy (dest + dest_len, src, src_len + 1);
+}
+
/* print statfs info */
static void
-print_statfs (char *pformat, char m, char const *filename,
+print_statfs (char *pformat, size_t buf_len, char m, char const *filename,
void const *data)
{
STRUCT_STATVFS const *statfsbuf = data;
@@ -305,28 +318,28 @@ print_statfs (char *pformat, char m, cha
switch (m)
{
case 'n':
- strcat (pformat, s);
+ xstrcat (pformat, buf_len, s);
printf (pformat, filename);
break;
case 'i':
#if HAVE_STRUCT_STATXFS_F_FSID___VAL
- strcat (pformat, x %-8x);
+ xstrcat (pformat, buf_len, x %-8x);
printf (pformat, statfsbuf-f_fsid.__val[0], /* u_long */
statfsbuf-f_fsid.__val[1]);
#else
- strcat (pformat, Lx);
+ xstrcat (pformat, buf_len, Lx);
printf (pformat, statfsbuf-f_fsid);
#endif
break;
case 'l':
- strcat (pformat, NAMEMAX_FORMAT);
+ xstrcat (pformat, buf_len, NAMEMAX_FORMAT);
printf (pformat, SB_F_NAMEMAX (statfsbuf));
break;
case 't':
#if HAVE_STRUCT_STATXFS_F_TYPE
- strcat (pformat, lx);
+ xstrcat (pformat, buf_len, lx);
printf (pformat,
(unsigned long int) (statfsbuf-f_type)); /* no equiv. */
#else
@@ -334,23 +347,23 @@ print_statfs (char *pformat, char m, cha
#endif
break;
case 'T':
- strcat (pformat, s);
+ xstrcat (pformat, buf_len, s);
printf (pformat, human_fstype (statfsbuf));
break;
case 'b':
- strcat (pformat, PRIdMAX);
+ xstrcat (pformat, buf_len, PRIdMAX);
printf (pformat, (intmax_t) (statfsbuf-f_blocks));
break;
case 'f':
- strcat (pformat, PRIdMAX);
+ xstrcat (pformat, buf_len, PRIdMAX);
printf (pformat, (intmax_t) (statfsbuf-f_bfree));
break;
case 'a':
- strcat (pformat, PRIdMAX);
+ xstrcat (pformat, buf_len, PRIdMAX);
printf (pformat, (intmax_t) (statfsbuf-f_bavail));
break;
case 's':
- strcat (pformat, lu);
+ xstrcat (pformat, buf_len, lu);
printf (pformat, (unsigned long int) (statfsbuf-f_bsize));
break;
case 'S':
@@ -358,21 +371,21 @@ print_statfs (char *pformat, char m, cha
unsigned long int frsize = STATFS_FRSIZE (statfsbuf);
if (! frsize)
frsize = statfsbuf-f_bsize;
- strcat (pformat, lu);
+ xstrcat (pformat, buf_len, lu);
printf (pformat, frsize);
}
break;
case 'c':
- strcat (pformat, PRIdMAX);
+ xstrcat (pformat, buf_len, PRIdMAX);
printf (pformat, (intmax_t) (statfsbuf-f_files));
break;
case 'd':
- strcat (pformat, PRIdMAX);
+ xstrcat (pformat, buf_len, PRIdMAX);
printf (pformat, (intmax_t) (statfsbuf-f_ffree));
break;
default
Re: binary mode copies
Eric Blake [EMAIL PROTECTED] wrote: The following patch, first proposed for cygwin, is needed on systems like cygwin where not copying in binary mode can lead to data corruption. This affects mv, cp, and install. 2005-03-15 Corinna Vinschen [EMAIL PROTECTED] (tiny change) * src/copy.c (copy_reg): Copy regular files in binary mode. Thanks. I've applied that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp -lL' behaviour conflicts with documentation
Tim Waugh [EMAIL PROTECTED] wrote: coreutils-5.2.1: $ mkdir /tmp/foo $ cp -lL /lib/libc.so.6 /tmp/foo $ ls -l /tmp/foo total 4 lrwxrwxrwx 2 root root 13 Mar 8 10:59 libc.so.6 - libc-2.3.4.so The man page says that -L always dereferences symbolic links, but when used in conjuction with -l (link files instead of copying) this is not honoured. (Originally RH bug #150951.) Thanks for the report. I suppose this is a documentation bug, since making hard links to symlinks is not portable. I suppose -L and -l should mention that when they are used together, cp may try to make hard links to symbolic links. Would you like to do that? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp -lL' behaviour conflicts with documentation
Tim Waugh [EMAIL PROTECTED] wrote: On Tue, Mar 15, 2005 at 04:38:03PM +0100, Jim Meyering wrote: ... Thanks for the report. I suppose this is a documentation bug, since making hard links to symlinks is not portable. I suppose -L and -l should mention that when they are used together, cp may try to make hard links to symbolic links. It isn't obvious to me that a hardlink to a symbolic link would be created. Why isn't a hard link to the referent created? The --help output says: -L, --dereferencealways follow symbolic links so it's quite surprising that an operation occurs on the link itself rather than the referent, regardless of whether the operation is to copy or to make a hard link to. Surely the non-portability of making hard links to symlinks would only occur if -L was _omitted_ from the argument list? But the actual referent (as opposed to the symlink value) may be another symlink, which may point to another, etc. The final non-symlink value -- assuming there is one -- is the referent. It'd be easy if there were an flink syscall. Then you'd just open the symlink (which would open the referent) and use flink to create a hard link to the file behind the descriptor. Is it worth it to make cp manually follow a sequence of symlinks when given both -L and --link? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp -lL' behaviour conflicts with documentation
Hi Bob, [EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: Is it worth it to make cp manually follow a sequence of symlinks when given both -L and --link? That would certainly be a nice capability. If it is not worth it could that case be made an invalid case? That way there is no doubt. Because I agree that I would not have expected a hard link to a symlink when using -L,--dereference. In case anyone is interested in implementing this, be careful to detect symlink cycles (use cycle-check.[ch]). You'll have to specify what happens when there is no referent, either because of a dangling symlink or because of a cycle. If that happens for a command line argument, then it should provoke a non-zero exit. If it happens for a non-command-line-argument (e.g., during a recursive traversal), then what? In any case, it deserves a diagnostic. Whether it should exit nonzero... I could go either way. I'm leaning towards making it fail. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: pr -D FORMAT fixes, to match date +FORMAT
Paul Eggert [EMAIL PROTECTED] wrote:
...
if (tm == NULL)
{
- buf = xmalloc (INT_BUFSIZE_BOUND (long int));
- sprintf (buf, %ld, (long int) st.st_mtime);
+ buf = xmalloc (INT_BUFSIZE_BOUND (long int)
+ + MAX (10, INT_BUFSIZE_BOUND (int)));
+ sprintf (buf, %ld.9d, (long int) s, ns);
I've just corrected this:
It looks non-trivial to exercise this one. Of course, it's easy to
exercise in a debugger, but do you know how to create a file with
e.g. 64-bit st_mtime so that makes localtime fails? I tried using a
very large value on Solaris 5.9, but utime fails with EOVERFLOW (which
isn't mentioned in Solaris man pages as one of the ways utime may fail).
utimes works the same way.
2005-03-20 Jim Meyering [EMAIL PROTECTED]
* src/pr.c (init_header): Add missing `%' in new format string.
(init_header): Use zero-filled `.%09d' format, not space-filled `.%9d'.
Index: src/pr.c
===
RCS file: /fetish/cu/src/pr.c,v
retrieving revision 1.132
retrieving revision 1.134
diff -u -p -r1.132 -r1.134
--- src/pr.c20 Mar 2005 18:40:40 - 1.132
+++ src/pr.c20 Mar 2005 19:53:30 - 1.134
@@ -1693,7 +1693,7 @@ init_header (char *filename, int desc)
{
buf = xmalloc (INT_BUFSIZE_BOUND (long int)
+ MAX (10, INT_BUFSIZE_BOUND (int)));
- sprintf (buf, %ld.9d, (long int) s, ns);
+ sprintf (buf, %ld.%09d, (long int) s, ns);
}
else
{
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sync from gnulib to coreutils
Paul Eggert [EMAIL PROTECTED] wrote: I installed the following patches to sync from gnulib. The only change that wasn't simply a file-copy was to lib/vasnprintf.c. One of these days I should sync from coreutils to gnulib. The biggest hassle will be all those AC_LIBSOURCES and AC_LIBOBJ changes in m4/*.m4. I remember that Bruno didn't like that change but I don't recall why. Initially, it was because using this approach would cause a build failure in gettext. I looked into it and came up with a small, though slightly ugly patch that makes everything work in gettext's unusual case. He objected to the patch, since it seemed a little too tricky. A `proper' fix would require automake changes to provide a family of AC_LIBSOURCES and AC_LIBOBJ macros supporting multiple lib/m4 hierarchies. Perhaps there's a compromise that would make this change only conditionally? E.g., they could invoke new macros gl_LIBSOURCES and gl_LIBOBJ instead, where these macros default to AC_LIBSOURCES and AC_LIBOBJ but Bruno could redefine them? That sounds like a fine idea. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: color support for TERM=cygwin
Paul Eggert [EMAIL PROTECTED] wrote: Also, for those who prefer British spellings, should we be looking at supporting colour synonyms (dircolours, LS_COLOURS, ls --colour, etc.)? No, option and environment variable names are American English. If we wanted to localize them (I'm dubious), we should support French, Chinese, etc., not just British English. I agree. The original patch that added this feature also had British spellings, and I removed them, for just those reasons. Jim, what do you think? Is the following minor patch worth the hassle? It does save a couple of hundred bytes in the dircolors executable, but its main advantage to my mind is that it shortens the code by about 30 lines and removes some casts. Sure. That's an improvement. Thanks, Paul. In any case, Eric, you're right. There's a marked lack of documentation in this area. Any patches to remedy that would be welcome. I applied your tiny ls --help change. I too prefer to put documentation in --help output and/or coreutils.texi. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
FYI: don't let pr treat +1:-1 like +1:18446744073709551615
I was surprised to see that pr didn't reject as invalid a
negative page number. I've checked this in:
2005-04-01 Jim Meyering [EMAIL PROTECTED]
Don't let pr treat +1:-1 like +1:18446744073709551615.
* src/pr.c (strtoumax): Remove declaration.
(first_last_page): Use xstrtoumax in place of strtoumax,
so we don't interpret a negative page number (e.g., in an option
like --pages=1:-1) as valid.
* tests/pr/Test.pm (neg-page): Add a test for this.
Index: src/pr.c
===
RCS file: /fetish/cu/src/pr.c,v
retrieving revision 1.136
diff -u -p -r1.136 pr.c
--- src/pr.c28 Mar 2005 19:29:54 - 1.136
+++ src/pr.c1 Apr 2005 07:39:07 -
@@ -324,10 +324,6 @@
#include timespec.h
#include xstrtol.h
-#if ! (HAVE_DECL_STRTOUMAX || defined strtoumax)
-uintmax_t strtoumax ();
-#endif
-
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME pr
@@ -806,20 +802,19 @@ first_last_page (char const *pages)
char *p;
uintmax_t first;
uintmax_t last = UINTMAX_MAX;
- int err;
+ strtol_error err = xstrtoumax (pages, p, 10, first, );
+ if (err != LONGINT_OK err != LONGINT_INVALID_SUFFIX_CHAR)
+_STRTOL_ERROR (EXIT_FAILURE, pages, _(page range), err);
- errno = 0;
- first = strtoumax (pages, p, 10);
- err = errno;
if (p == pages || !first)
return false;
if (*p == ':')
{
char const *p1 = p + 1;
- errno = 0;
- last = strtoumax (p1, p, 10);
- err |= errno;
+ err = xstrtoumax (p1, p, 10, last, );
+ if (err != LONGINT_OK)
+ _STRTOL_ERROR (EXIT_FAILURE, pages, _(page range), err);
if (p1 == p || last first)
return false;
}
@@ -827,9 +822,6 @@ first_last_page (char const *pages)
if (*p)
return false;
- if (err)
-error (EXIT_FAILURE, err, _(Page range `%s'), pages);
-
first_page_number = first;
last_page_number = last;
return true;
Index: tests/pr/Test.pm
===
RCS file: /fetish/cu/tests/pr/Test.pm,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -u -r1.19 -r1.20
--- tests/pr/Test.pm15 Mar 2005 18:09:05 - 1.19
+++ tests/pr/Test.pm1 Apr 2005 07:40:33 - 1.20
@@ -355,6 +355,10 @@ my @tv = (
# Make sure these fail.
['col-0', '-0', '', '', 1],
['col-inval', '-'.'9'x100, '', '', 1],
+
+# Before coreutils-5.3.1, --pages=1:-1 would be treated like
+# --pages=1:18446744073709551615.
+['neg-page', '--pages=1:-1', '', '', 1],
);
#']]);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
FYI: --help now warns about built-in conflicts
FYI, Before, 3 man pages (echo, printf, pwd) included a warning like this: NOTE: your shell may have its own version of printf, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. I've put that warning in the --help output of 7 commands (actually, it's 8.5 if you count `[' and `false'), so it will now appear automatically in the generated man/*.1 files. If anyone knows of any other coreutils commands that are built-in, please let me know. I noticed only recently that some versions of zsh provide a builtin-like `stat' module. I've just done this: * src/echo.c (usage): Mention that some shells provide a built-in function by the same name. * src/kill.c (usage): Likewise * src/printf.c (usage): Likewise. * src/pwd.c (usage): Likewise. * src/stat.c (usage): Likewise. * src/test.c (usage): Likewise. * src/true.c (usage): * src/system.h (USAGE_BUILTIN_WARNING): New macro. * man/echo.x: Remove `DESCRIPTION' section, now that --help includes it. * man/printf.x: Likewise. * man/pwd.x: Likewise. Initially, I added those three lines at the very top (between the Usage line(s) and the short description), since mistaking the man-page as a reference for the built-in is such a common problem. But I didn't like that. Now it's at the end, e.g.: Usage: ./echo [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline -e enable interpretation of backslash escapes -E disable interpretation of backslash escapes (default) --help display this help and exit --version output version information and exit If -e is in effect, the following sequences are recognized: \0NNN the character whose ASCII code is NNN (octal) \\ backslash \a alert (BEL) \b backspace \c suppress trailing newline \f form feed \n new line \r carriage return \t horizontal tab \v vertical tab NOTE: your shell may have its own version of echo, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to bug-coreutils@gnu.org. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Patch] Adding examples to the man pages
P.S. Which type of copyright thing do I need for this? If someone can point me at the relevant stuff I'll try and get it sorted. I'll send it separately. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I: tee doesn't handle dash properly
Dmitry V. Levin [EMAIL PROTECTED] wrote: According to NEWS file, tee - now writes to standard output instead of to a file named -. However, tee closes stdout more than once if file is named -: $ env -i tee - /dev/null; echo rc=$? tee: write error rc=1 Proposed fix and testcases for tee could be found at ftp://ftp.altlinux.org/pub/people/ldv/coreutils/coreutils-5.3.1-alt-tee.patch Thank you for the fine report and patch. Especially for the test cases. I've applied those changes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Patch] Adding examples to the man pages
Paul Eggert [EMAIL PROTECTED] wrote: Dr. David Alan Gilbert [EMAIL PROTECTED] writes: OK, here is a handful of stuff against the CVS checkout. Is this OK? ... The examples need to be written up in doc/coreutils.texi as well. Jim, do you think they should be before or after the exit-status documentation? The patch below puts it before (since ln invocation already does this), but after might make sense too. I could go either way when the single sentence of exit-status documentation is all that follows the option descriptions. But when there's more than that one sentence, I have a slight preference for putting the examples at the end. Of course, if there are many examples, it might make sense to put them in their own section. Here is a proposed patch illustrating the sort of format I was thinking of. Jim, is this worth installing as-is as an example of how to do examples, or... Yes. Please do. Thanks for working on this. 2005-04-03 Paul Eggert [EMAIL PROTECTED] * doc/coreutils.texi (cat invocation, chown invocation) (chgrp invocation, basename invocation, dirname invocation): Add examples. (ln invocation): Use same format as other examples above, for consistency. * man/Makefile.am (.x.1): Remove COMMAND.td/ from examples. * src/basename.c (usage): Add examples. * src/cat.c (usage): Likewise. * src/chgrp.c (usage): Likewise. * src/chown.c (usage): Likewise. * src/dirname.c (usage): Likewise. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: FYI: --help now warns about built-in conflicts
[EMAIL PROTECTED] (Eric Blake) wrote:
...
If anyone knows of any
other coreutils commands that are built-in, please let me know.
tcsh provides nice, nohup, and printenv. Not that csh-variants are
POSIX-compliant, but they are often a user's default shell, so these three
should also get the warning.
Thanks. I've done that.
Initially, I added those three lines at the very top (between the Usage
line(s)
and the short description), since mistaking the man-page as a reference
for the built-in is such a common problem. But I didn't like that.
Now it's at the end, e.g.:
Is there any way to get the --help output to put the warning at the end, but
the man page to list it at the front? With --help, the last thing printed is
most
important, but in man pages, the first screenful is most important. What does
help2man offer to help us acheive this? Do we need a new section name?
That sounds worthwhile.
I didn't see anything in help2man that looked like it'd be appropriate.
Maybe Brendan O'Dea (help2man author) can suggest something -- or even
add the feature.
In case anyone is interested, here's a patch that would add a new
section name, `WARNING' to help2man. But calling it `WARNING' is
probably too extreme. Besides, I suppose adding a new section is
not something to do lightly.
Index: help2man
===
RCS file: /fetish/cu/man/help2man,v
retrieving revision 1.28
diff -u -p -r1.28 help2man
--- help2man25 Nov 2004 22:17:55 - 1.28
+++ help2man5 Apr 2005 13:28:59 -
@@ -373,6 +373,7 @@ my $PAT_BUGS= _('Report +bugs|Email +b
my $PAT_AUTHOR = _('Written +by');
my $PAT_OPTIONS= _('Options');
my $PAT_EXAMPLES = _('Examples');
+my $PAT_WARNING= _('WARNING');
my $PAT_FREE_SOFTWARE = _('This +is +free +software');
# Start a new paragraph (if required) for these.
@@ -393,6 +394,11 @@ while (length)
$sect = _('EXAMPLES');
next;
}
+elsif (s/^($PAT_WARNING): *\n//o)
+{
+ $sect = _('WARNING');
+ next;
+}
# Copyright section
if (/^Copyright +[(\xa9]/)
@@ -581,8 +587,8 @@ print EOT;
EOT
# Section ordering.
-my @pre = (_('NAME'), _('SYNOPSIS'), _('DESCRIPTION'), _('OPTIONS'),
-_('EXAMPLES'));
+my @pre = (_('NAME'), _('SYNOPSIS'), _('WARNING'), _('DESCRIPTION'),
+ _('OPTIONS'), _('EXAMPLES'));
my @post = (_('AUTHOR'), _('REPORTING BUGS'), _('COPYRIGHT'), _('SEE ALSO'));
my $filter = join '|', @pre, @post;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: md5sum and filenames containing \
[EMAIL PROTECTED] (Bob Proulx) wrote: Olivier Delhomme wrote: Here I have coreutils 5.2.1, debian 3.1 unstable, bash 3.00.16(1) and I can not reproduce your problem. The hash value is correct and without the \ at the beginning. On my Debian system the md5sum utility is not the GNU one but is from a different source and is included in the dpkg package. It is a compatibility issue. As you note it does not behave this way. The GNU md5sum is shipped on Debian as md5sum.textutils. In this particular case bash is not involved. I can reproduce the behavior with the latest GNU md5sum 5.3.1. However I also don't know why it is programed that way. It is obviously intentional. It is to inform `md5sum -c' that the file name is backslash-encoded. This is necessary to make md5sum work with file names containing newlines. For example: # Create a file containing a newline: $ touch 'a b' The `other' md5sum cannot deal with such a name: o $ /usr/bin/md5sum 'a b'|/usr/bin/md5sum -c /usr/bin/md5sum: can't open a /usr/bin/md5sum: no files checked [Exit 3] But the md5sum from coreutils can: $ /usr/bin/md5sum.textutils 'a b'|/usr/bin/md5sum.textutils -c a b: OK ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in uname on Darwin 7.8.0
Geert Jan van Oldenborgh [EMAIL PROTECTED] wrote: a while ago I installed the very useful coreutils on my iMac. However, when I tried to upgrade my free software collection with fink it refused. The reason turned out to be a bew uname from coreutils, which did not recognize the processor: [srikandi] [13:13] /sw% /usr/local/bin/uname --version uname (coreutils) 5.0 That's fixed in a newer version: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd hangs with SIGINT
Bruno Haible [EMAIL PROTECTED] wrote: Guillaume Chazarain wrote: As it prints a message for the first time, it has to initialize gettext, and I'm not sure this qualifies for the do as little as possible in a signal handler rule. I agree. The list of guaranteed async-safe function calls on POSIX systems is listed at http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_03 fprintf() is not part of it. gettext() neither, nor are the calls made by gettext(), namely malloc(), free(), tsearch(), mmap(). So it would seem advisable to pre-fetch the translations before the SIGINT happens. Untested patch is appended. Unfortunately it forces to remove ngettext() calls, which is bad for plural handling. Also you need to check the quote() call whether it avoids calling malloc... Hi Bruno, Thanks for the patch, but that `cure' seems worse than the disease. If there is no better way to solve the problem, then I'd consider leaving the code the way it is. Not only does that change make the code less maintainable in the sense that every message that might be generated by print_stats must be pre-translated, but it also moves the format strings away from the corresponding argument lists; and that makes it so the compiler can no longer verify types and number of format directives vs. arguments. Jim ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd hangs with SIGINT
Guillaume Chazarain [EMAIL PROTECTED] wrote: Jim Meyering wrote: If there is no better way to solve the problem, then I'd consider leaving the code the way it is. Don't forget, there is my workaround, it stills cause gettext() calls in the signal handler, but I cannot make it fail, unlike vanilla. Thanks. I remember :) Your patch is definitely better from the perspective of keeping the code maintainable, but it'd be good to know why it works. Maybe because once initialized, gettext is far less likely to call functions like mmap and malloc? Can you determine whether (with your patch) e.g., malloc is ever being called from the signal handler? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
configure warning about sys/mount.h on FreeBSD 5.4 prerelease
Stephen Mc Gowan [EMAIL PROTECTED] wrote: While make install in /usr/ports/sysutils/coreutils I encountered this error. I'm running FreeBSD 5.4 preRelease configure: WARNING: sys/mount.h: present but cannot be compiled configure: WARNING: sys/mount.h: check for missing prerequisite headers? configure: WARNING: sys/mount.h: see the Autoconf documentation configure: WARNING: sys/mount.h: section Present But Cannot Be Compiled configure: WARNING: sys/mount.h: proceeding with the preprocessor's result configure: WARNING: sys/mount.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to bug-coreutils@gnu.org ## configure: WARNING: ## ## Thanks for the report. Which version of coreutils is that? Can you reproduce that with the latest test release? ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm -r recursion failure
This is probably due to a bug in how readdir works on your system. Currently coreutils has a configure-time run-test that detects whether rm's relatively expensive work-around code is required. But if that test runs only on a file system that does not exhibit the bug, then rm is built without the work-around code. That's probably what happened in your case. The alternative design would be to include in rm.c (remove.c actually) itself code to detect the problem and work around it, even on systems that don't ever exhibit the bug. I was reluctant to impose that cost on every system with only POSIX-compliant readdir implementations. I suggest that you configure/build coreutils in a working directory that is NFS-mounted like the one that exhibited the problem. Then you should end up with a rm binary that works there. FYI, to check for this configure-time test result, look for gl_cv_func_working_readdir in config.h after you've run ./configure. If it is equal to `no', then your resulting `rm' binary will have the required work-around code. If that doesn't help, please let me know, and we'll dig deeper. [EMAIL PROTECTED] (John W. MacDonald) wrote: This report is very similar to earlier ones involving recursion failure using 'rm -r' on directories on nfs mounted volumes. (see http://lists.gnu.org/archive/html/bug-coreutils/2004-03/msg00016.html). In this case: client: RedHat Enterprise WS 3.x, (kernel 2.4.21-15.0.4.ELsmp) server: Apple Xserve OS X server v.10.3.8; filesystems: HFS+ (journaled) [tested ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)
Joey Hess [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.2.1-2
Severity: important
Tags: security
Our coreutils seems to be vulnerable to the problem described in
CAN-2005-1039.
http://www.securityfocus.com/archive/1/395489
A quick strace of mkdir -m 400 foo shows the problem:
mkdir(foo, 0400) = 0
chmod(foo, 0400) = 0
So if this is run in a directory where the attacker has access, such as
a group writable directory (as commonly used for teams in eg, the Debian
project; on alioth, etc), then the attacker can race between the mkdir
and chmod calls, (re)moving the new directory and replacing it with a
symlink to a file or directory owned by the user who ran mkdir. The
chmod will then follow the symlink and act on that directory. And
similar for the other commands.
A fix would be to create the directory/device with the right perms
and not chmod it again afterwards.
Thanks for the report.
FYI, one approach to `fixing' this would cause problems.
For example, the following patch looks like an improvement,
but it would introduce a bug:
Index: mkdir.c
===
RCS file: /fetish/cu/src/mkdir.c,v
retrieving revision 1.91
diff -u -p -r1.91 mkdir.c
--- mkdir.c 21 Sep 2004 22:26:42 - 1.91
+++ mkdir.c 14 Apr 2005 11:43:31 -
@@ -183,6 +183,7 @@ main (int argc, char **argv)
been created. */
if (ok specified_mode dir_created
+ (newmode ~S_IRWXUGO)
chmod (dir, newmode) != 0)
{
error (0, errno, _(cannot set permissions of directory %s),
If the affected directory's parent has a default ACL or has the set group
ID bit set, then the chmod may be required e.g., to reset the inherited
set group ID bit or to adjust any S_IRWXUGO bits that were changed via
the default ACL.
An alternative approach is to lstat the new directory, compare its mode to
the desired mode and then, only if necessary, call chmod. But this still
leaves the race-window open.
The only raceless approach I can see is to lstat the name, open it,
fstat its file descriptor, compare the dev/inode with those from lstat,
check the mode, and if needed, call fchmod. But that too can fail:
if the new directory is not readable by the user who just created it,
then the open will fail. But when setting such restrictive permissions,
resorting to the use of the race-vulnerable lstat+chown isn't a big deal.
But now we're talking about pretty much more code and a little added cost
(always call lstat,open,fstat,and-maybe-fchmod rather than just chmod).
All for a theoretically exploitable race condition.
Is it worth it in this case?
Opinions welcome.
For reference, here's a possible patch, relative to the upstream repository:
(I'm not sure I like the idea of calling chown upon failed open.
Also, I wouldn't really put this code in mkdir.c -- it'd be used
by mknod.c and mkfifo.c, too. )
Index: mkdir.c
===
RCS file: /fetish/cu/src/mkdir.c,v
retrieving revision 1.91
diff -u -p -r1.91 mkdir.c
--- mkdir.c 21 Sep 2004 22:26:42 - 1.91
+++ mkdir.c 14 Apr 2005 14:21:43 -
@@ -1,5 +1,5 @@
/* mkdir -- make directories
- Copyright (C) 90, 1995-2002, 2004 Free Software Foundation, Inc.
+ Copyright (C) 90, 1995-2002, 2004, 2005 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -28,6 +28,7 @@
#include makepath.h
#include modechange.h
#include quote.h
+#include unistd-safer.h
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME mkdir
@@ -78,6 +79,79 @@ Mandatory arguments to long options are
exit (status);
}
+/* Call fchmod(2) on FILE only after ensuring that the file system
+ object to be modified is not a symbolic link.
+ If anything goes wrong,
+ - FILE is a symlink (set errno to EINVAL)
+ - failed system call
+ - FILE changed dev/inode between lstat and open calls (set errno to
EINVAL)
+ skip the fchmod and return -1. Otherwise, return 0.
+ In most cases, there is no possibility for an attacker to replace FILE
+ with say, a symlink, to cause the permissions of some other file to be
+ affected, but if FILE cannot be opened, we go ahead and call chown
+ directly.
+
+ This function is intended to be called on a FILE that has just been
+ created, and that may already have its mode set to MODE. In the
+ relatively unusual case that MODE does not reflect the permissions
+ of FILE, then we set them. */
+
+int
+safe_chmod (char const *file, mode_t mode)
+{
+ struct stat lstat_stats;
+ struct stat fstat_stats;
+ int fd;
+
+ if (lstat (file, lstat_stats) != 0)
+return -1;
+
+ if (S_ISLNK (lstat_stats.st_mode))
+{
+ errno = EINVAL;
+
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)
Paul Eggert [EMAIL PROTECTED] wrote: My kneejerk reaction is that it's not worth making this change. The attack in question will work against almost any program that is operated in an insecure directory, including the chmod program itself. It'd be a real pain to work around this problem in all applications, one at a time, and it's not at all clear to me that it's even doable in general. I suggest simply warning users that if you let bad guys modify your directories, you're asking for trouble. Which is certainly true in any event. That being said, it would be an easy security improvement if mkdir -m would use lchmod rather than chmod, on platforms where lchmod is available. There may be several other programs where this would be advisable as well, and similarly for lchown versus chown. I would be more interested in that approach if I knew that lchmod support were coming to Linux sometime soon. I see that NetBSD, OpenBSD, HPUX (but not Solaris) provide it. This reminds me of Solaris' very nice openat, fdopendir, fstatat functions[1]. They too provide useful functionality that can't be emulated cleanly, yet Linux doesn't provide the necessary syscalls. I suppose a weak replacement function is the `right' way to go -- then, as for openat, redirect complaints to the Linux kernel folks. Jim -- [1] I'm not interested in attribute-related semantics of openat, but rather in the fd-relative-open--related semantics. openat et.al. are very useful in any code that would otherwise have to change to a new directory and then later return to the initial working directory. No code that tries to do that with chdir (or even with open/fchdir) can be truly robust, but it's easy with openat and company. The problem is that sometimes it is impossible to return, even with open/fchdir. With openat, you define away the problem by making it unnecessary to change the current working directory. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: testsuite portability nit
Paul Eggert [EMAIL PROTECTED] wrote: Eric Blake [EMAIL PROTECTED] writes: What was wrong with my proposed patch? I had some qualms with it, because it added coupling between the test cases and the rest of the code, by propagating BUILD_SRC_DIR and EXEEXT from the latter to the former. Coupling like that places extra ... Jim may have other opinions, though. Perhaps he'd prefer the approach of the original patch, in which case we should install that instead. I wouldn't have objected to the original patch, but do see that it would introduce the first use of $EXEEXT in a test script. However, there is precedent for using $BUILD_SRC_DIR. And since there are so few tests for install, I think it's a little friendlier to the other-OS crowd not to skip those tests. Who knows... maybe this test will someday help someone developing on a non-Unix-like system to submit a better patch to install.c. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: renamed fetish to coreutils in a few more places
Paul Eggert [EMAIL PROTECTED] wrote: I installed the following patch to remove fetish to coreutils in a few That was overdue. Long ago, when FIleutils, TExtutils, and SH-utils were merging, I put test tarballs in a directory named fetish/, but people noticed that some corporate content-filters made that directory inaccessible to them. Thanks for doing that. more places. The only nontrivial bit here is removing fetish.sf.net from some URL lists; I assume that's obsolete now? Yes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Build time requirements.
Allen Suski [EMAIL PROTECTED] wrote: I have noticed that source requires the texinfo package (actually makeinfo) in order to successfully compile and install. Identifying this in the build time dependencies may save some others frustration when starting from a fresh HP-UX 11.11 install. Are you using HP's make program? It's had a bug that makes it look like makeinfo is required, when in fact the file mod-times and dependencies indicate that it is *not* required. If you use GNU make, you'll find that makeinfo is not required. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir -p and network drives
By the way, the coreutils anon CVS mirror syncronization appears to be hung again, I've just sync'd things. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Fwd: Strange-Dangerous behaviour in Cygwin]
Eric Blake [EMAIL PROTECTED] wrote: Relevant clips from this cygwin bug report. When tty settings are weird (I'm not sure whether the bug is in cygwin, xterm, or just bad tty settings that could be reproduced elsewhere), backspace only repositions the cursor on screen, so that the actual buffer read by yesno() can contain y\bn instead of n. Is it possible for lib/yesno.c to be a little more paranoid and check that there are not embedded characters normally used in terminal editing that would undo the first character? I don't think changing yesno would be appropriate in this case. What if the string is n\by? What if \b is not the erase character? What if the string is yes and `e' is the `erase' character? Should it handle both DEL and ERASE characters? Should it also handle word-erase and line-erase characters? I know you said `normally used...', so I assume you wanted something simple, befitting yesno's status, but I don't see an appropriate way to solve the problem by changing yesno. Alternative opinions (or patches to yesno.c) welcome. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Buggy mv --interactive --reply=no, hopefully solved here
Vlada Macek [EMAIL PROTECTED] wrote:
I still believe there is a bug in `mv'. Try to run
mv --interactive --reply=no plain1 plain2
and given both plains exist, plain2 gets overwritten. This is not
expected behavior, not just by me (there is a Debian bug filled in).
Command `cp' is not affected.
The problem seems to be fixed by this:
--- coreutils-cvs/src/copy.c2005-04-11 22:06:34.0 +0200
+++ coreutils/src/copy.c2005-05-09 21:43:40.539405480 +0200
Thank you for the report and patch.
I've applied it, adjusted some comments, and added a test case.
The change is committed, but there will be some delay before
it reaches savannah.
2005-05-10 Jim Meyering [EMAIL PROTECTED]
* src/copy.c (abandon_move): Remove erroneous UNWRITABLE check.
This makes `mv -i --reply=no f1 f2' work as expected (in not
performing the move operation). But note that specifying `-i'
after `--reply=no' does *not* work.
Tiny patch from Vlada Macek.
Correct a comment.
* tests/mv/reply-no: New file. Test for the above fix.
* tests/mv/Makefile.am (TESTS): Add reply-no.
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.179
retrieving revision 1.180
diff -u -p -u -r1.179 -r1.180
--- src/copy.c 11 Apr 2005 20:06:34 - 1.179
+++ src/copy.c 10 May 2005 07:35:43 - 1.180
@@ -798,8 +798,8 @@ record_file (Hash_table *ht, char const
/* When effecting a move (e.g., for mv(1)), and given the name DST_PATH
of the destination and a corresponding stat buffer, DST_SB, return
- true if the logical `move' operation should not proceed.
- Return true if it may proceed.
+ true if the logical `move' operation should _not_ proceed.
+ Otherwise, return false.
Depending on options specified in X, this code may issue an
interactive prompt asking whether it's ok to overwrite DST_PATH. */
static bool
@@ -808,8 +808,7 @@ abandon_move (const struct cp_options *x
struct stat const *dst_sb)
{
assert (x-move_mode);
- return ((x-interactive == I_ALWAYS_NO
-UNWRITABLE (dst_path, dst_sb-st_mode))
+ return (x-interactive == I_ALWAYS_NO
|| ((x-interactive == I_ASK_USER
|| (x-interactive == I_UNSPECIFIED
x-stdin_tty
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Make Check on coreutils, darwin failed
Eric Blake [EMAIL PROTECTED] wrote: According to Adam Price on 5/9/2005 11:39 PM: Making check in touch make check-TESTS PASS: relative 0a1 touch: setting times of `/': Permission denied FAIL: not-owner I've noticed that cygwin also tends to fail this test, because the typical cygwin user installed / themselves (as c:\cygwin) and has write access to change /. I don't know if there is a better approach to finding a directory that the user does not have rights to (cygwin will soon have // appear as a directory with read-only properties, so // might work, but doesn't generalize well). Perhaps something like this is needed in tests/touch/not-owner: if test `stat -c %u /` = `id -u` ; then ... Thanks to both of you. I've just added tests to check owner/group and whether / is writable -- using `test' makes it easier :) Index: tests/touch/not-owner === RCS file: /fetish/cu/tests/touch/not-owner,v retrieving revision 1.3 retrieving revision 1.5 diff -u -p -r1.3 -r1.5 --- tests/touch/not-owner 23 Jun 2004 15:07:05 - 1.3 +++ tests/touch/not-owner 10 May 2005 13:30:39 - 1.5 @@ -11,6 +11,17 @@ fi . $srcdir/../lang-default PRIV_CHECK_ARG=require-non-root . $srcdir/../priv-check +test=../../src/test +if $test -w /; then + echo Skipping because you have write access to /. + (exit 77); exit 77 +fi + +if $test -O / || $test -G /; then + echo Skipping because you own /. + (exit 77); exit 77 +fi + pwd=`pwd` t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$ trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 exit $status' 0 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup definition should be changed
Paul Eggert [EMAIL PROTECTED] wrote: Your message about nohup's problems had me nodding in agreement, as similar problems have happened to me. Are there any objections to my installing this patch into GNU coreutils? 2005-05-12 Paul Eggert [EMAIL PROTECTED] * NEWS: nohup now closes stdin if it is a terminal, unless POSIXLY_CORRECT is set. This fixes a glitch noted by Wayne Pollock in https://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-group-lid=8341. * doc/coreutils.texi (nohup invocation): Document this. * src/nohup.c (main): Implement this. Fine by me. Thanks to both of you. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
rm: avoiding a race condition on non-glibc systems
In reviewing parts of remove.c I noted (again) the race condition on
systems with an unlink that may remove directories, so added this comment:
+/* If anyone knows of another system for which unlink can never
+ remove a directory, please report it to [EMAIL PROTECTED]
+ The code below is slightly more efficient if it *knows* that
+ unlink(2) cannot possibly unlink a directory. */
On non-glibc systems that race condition means that there's a window
via which a privileged rm user might be tricked into unlinking a
nonempty directory.
I investigated for Solaris-10 and found that this privilege
can be tested at run-time. Here's a little code to test
whether its PRIV_SYS_LINKDIR is in the effective set:
/* This is Solaris-10-specific -- at least priv.h */
#include priv.h
#include stdlib.h
#include stdbool.h
static bool
can_unlink_directory (void)
{
#ifdef __GLIBC__
return false;
#elif defined PRIV_EFFECTIVE defined PRIV_SYS_LINKDIR
/* Solaris 10 */
priv_set_t *pset = priv_allocset ();
if (getppriv (PRIV_EFFECTIVE, pset) != 0)
return true;
bool can = priv_ismember (pset, PRIV_SYS_LINKDIR);
priv_freeset (pset);
return can;
#else
/* Be pessimistic: assume that unlink can remove a directory. */
return true;
#endif
}
int
main ()
{
exit (can_unlink_directory () ? 0 : 1);
}
That little test program works fine, but I'm not sure I want to
rearrange remove.c enough to add such a run-time test.
At best, the race condition is purely theoretical (barring a manually
suspended `rm -r') and we needn't worry. If anyone can give an idea
of how easy/hard it would be for a non-privileged user to trick a
running rm process into unlinking a directory, I'd appreciate it.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm: avoiding a race condition on non-glibc systems
Paul Eggert [EMAIL PROTECTED] wrote: ... How about this patch? It incorporates the above ideas. 2005-05-13 Paul Eggert [EMAIL PROTECTED] * m4/prereqs.m4 (gl_PREREQ): Require gl_UNLINKDIR. * src/remove.c: Include unlinkdir.h. (UNLINK_CAN_UNLINK_DIRS): Remove. (remove_entry): Use cannot_unlink_dirs () rather than UNLINK_CAN_UNLINK_DIRS. * lib/unlinkdir.c, lib/unlinkdir.h: New files. * m4/unlinkdir.m4: New file. That looks fine, and works fine here. Please commit it. I'll see if I can find someone to test the give-up-privilege code as root on Solaris 10. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm: avoiding a race condition on non-glibc systems
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: That looks fine, and works fine here. Please commit it. OK, done. I also added Cygwin to the list of platforms that can't unlink directories, as Eric Blake suggested. Thanks! I found that it needed a little change: 2005-05-14 Jim Meyering [EMAIL PROTECTED] * unlinkdir.m4: Register unlinkdir.c and unlinkdir.h via AC_LIBSOURCES. Add `AC_LIBOBJ([unlinkdir])'. Index: m4/unlinkdir.m4 === RCS file: /fetish/cu/m4/unlinkdir.m4,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -u -r1.1 -r1.2 --- m4/unlinkdir.m4 14 May 2005 08:01:17 - 1.1 +++ m4/unlinkdir.m4 14 May 2005 10:34:00 - 1.2 @@ -1,4 +1,4 @@ -#serial 1 +#serial 2 # Copyright (C) 2005 Free Software Foundation, Inc. # @@ -13,6 +13,9 @@ AC_DEFUN([gl_UNLINKDIR], AC_REQUIRE([AC_CANONICAL_HOST]) AC_CHECK_HEADERS_ONCE(priv.h unistd.h) + AC_LIBSOURCES([unlinkdir.c, unlinkdir.h]) + AC_LIBOBJ([unlinkdir]) + # The Hurd, the Linux kernel, the FreeBSD kernel version 2.2 and later, # and Cygwin never let anyone (even root) unlink directories. # If anyone knows of another system for which unlink can never ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: command tac ??
Sp4wn Root [EMAIL PROTECTED] wrote: The command tac does not obtain to read memory archives that are located in /proc. Example: #tac /proc/cpuinfo Thank you for the report. That's fixed in the latest test release. ftp://alpha.gnu.org/gnu/coreutils/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug or feature? replace symlink to directory with ln -fs does not work
Peter Kratzer [EMAIL PROTECTED] wrote: I have encountered a problem using the command ln -sf to replace a symlink to a directory by a symlink to a different directory. `ln -nsf' should do what you want. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ./expr 6 + -2 = 8
Dr. David Alan Gilbert [EMAIL PROTECTED] wrote: From the current cvs (as of a few minutes ago) when I do ./expr 6 + -2 I get 8. Every other version of expr I've tried gets 4 which really does seem right. (This is on ubuntu Linux gcc 3.3.5 on x86) Can anyone replicate this? I can :( Thanks for the report. Here's a snap fix. I'll add tests, too. Index: expr.c === RCS file: /fetish/cu/src/expr.c,v retrieving revision 1.102 diff -u -p -r1.102 expr.c --- expr.c 14 May 2005 07:58:37 - 1.102 +++ expr.c 26 May 2005 16:00:27 - @@ -356,7 +356,7 @@ toarith (VALUE *v) while (*++cp); free (v-u.s); - v-u.i = value * sign; + v-u.i = value; v-type = integer; return true; } ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: support for comparison of unlimited-length integers in expr and test
Paul Eggert [EMAIL PROTECTED] wrote: The recent bug-fix to expr got me to thinking: why doesn't expr simply compare integers of unlimited length, the way sort does? That can be done cheaply. test has a similar problem. I installed the following patch to implement this idea. This fixes all the integer-overflow problems I know of with test, but expr still has quite a few problems, e.g., expr 9223372036854775807 + 1 still prints -9223372036854775808. How about if we modify expr to use GMP http://swox.com/gmp/ instead, so that expr doesn't overflow unless it runs out of memory? The disadvantage is a reliance on the GMP library, but the advantage is that expr will just work. We can fall back to the current approach if GMP is not available. Thanks for doing that. Yes, it'd be nice to use GMP when it's available. And not just for expr. Factor would benefit from using it, too. For example, the sample program (factorize.c) in GMP already provides a couple of efficient algorithms. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Port to Solaris 10's rules for whether programs can chown files
Paul Eggert [EMAIL PROTECTED] wrote: ... 2005-05-30 Paul Eggert [EMAIL PROTECTED] Port to Solaris 10's rules for whether programs can chown files. That is indeed an improvement. Thank you! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new coreutil? shuffle - randomize file contents
Frederik Eaton [EMAIL PROTECTED] wrote: So, what is the current state of things? Who is in charge of accepting patches? Are we decided that a 'shuffle' command but no 'sort -R' facility would be best, or that it would be good to have both, or is it still in question whether either would be accepted? I am the official `maintainer', but Paul Eggert has been making most of the changes recently. It looks like there are some desirable features that can be provided only by a shuffle-enabled program that is key-aware. Key specification and the comparison code are already part of sort. Obviously, duplicating all of that in a separate program is not an option. I don't relish the idea of factoring out sort's line- and key-handling code either, but it might be feasible. However, I do like the idea of a new program that simply outputs a random permutation of its input records, and that does it well, and repeatably. The Unix tool philosophy certainly does encourage the `perform one task and do it well' approach. Since doing it well includes handling input larger than available virtual memory, this is not trivial -- and it is well suited to the coreutils, i.e., it's not easily implementable as a script. Initially, I was inclined to say that adding both the new program (no key support) and related functionality to sort was desirable. Thinking of the limits of robustness of such a new program, I realized that if the input is sufficiently large and not seekable (e.g., from a pipe), then the program will have to resort to writing temporary files, much as sort already does. More duplicated effort, determining how much memory to use (like sort's --buffer-size=SIZE option), managing the temporary files, ensuring that they're removed upon interrupt, etc. But maybe not prohibitive. The new program would also have to have an option like sort's -z, --zero-terminated option, and --temporary-directory=DIR, and --output=FILE. In effect, it would need all of sort's options that don't relate to sorting. So implementing a robust shuffle program, even one without key handling capabilities, would require much of the infrastructure already present in sort.c. It sure sounds like shuffle and sort should share a lot of code, one way or another, so why not have them share the line- and key- handling code, too? I won't rule out adding a new program, like shuffle, but I confess I'm less inclined now than when I started typing this message. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested enhancement to du command - show last modified date.
William Brendling [EMAIL PROTECTED] wrote: ... Doesn't the standard ISO-8601 date format accomplish that, too? Quite likely. I will have to find out what the ISO-8601 format is. date already supports it: $ date --iso=s 2005-06-07T08:14:28+0200 ls does, too, via --time-style=STYLE. du's default format needn't include the time zone. It might be nice to have an option that makes it look at atime rather than mtime. Yes, I thought of that, but did not need it myself. Would you suggest a --last-accessed switch as well as --last-modified, or would it be better to have a modifier --use-time=atime|ctime|mtime? Since ls already has related options, it might make sense to do something similar. How about dropping the `use-' part of the option name and making it --time=...? `use time' or `time of last use' is a common description of `atime'. It's good to update the --help output and even better to update the primary documentation in the file doc/coreutils.texi. I have made an addition to the --help output to describe the --last-modified switch, but not the details of the date formats. I have not yet looked at trying to update the other documentation. You don't have to write much. Just say du's date format string is interpreted just like that of the `date' command. Writing ChangeLog entries describing your changes is helpful. OK. It may take me a while to do all this. No problem. Paperwork usually takes at least a couple weeks. Yes, please send me the forms. No promises. Coming right up. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln does not work as documented
Bill, thanks for pointing out the bad example. I've added Bob's examples verbatim. Thanks, Bob. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new coreutil? shuffle - randomize file contents
Frederik Eaton [EMAIL PROTECTED] wrote: Here is a preliminary patch for basic shuffling functionality in 'sort', with same-keys-sort-together behavior. It adds two options: -R to compare based on a hash of key, and --seed to specify salt for the hash. If --seed is not given then the default is to read from /dev/random or /dev/urandom. I still need to add support to configure.ac for some of the random device macros. Thanks. I haven't had time to give it serious consideration yet, but we should get started on the copyright-related paperwork. I'll send you the form separately. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Buffer overflow in cp and mv commands
Gregory Butenko [EMAIL PROTECTED] wrote: I have compiled coreutils with hardened gcc and now the following messages pop up when subtrees copied or moved: mv: stack smashing attack in function copy_internal() or cp: stack smashing attack in function copy_internal() That is a good sign of a buffer overflow bug. Could someone fix that? I run Linux on PPC with 64MB memory and this bug shows up when there is not enough memory, I believe. Thanks for the report. Unfortunately, what you've provided isn't quite enough to say precisely where the bug is -- or indeed, whether there is one. However, here's a guess: If you're really using a system that is so memory-limited, then you may be encountering a stack overflow. alloca is documented to have undefined behavior if allocation causes stack overflow. Consider using more *virtual* memory, so you don't run into this sort or problem. Please be sure to report the version of the coreutils that you're using. If you can get the latest from CVS, that'd be best: http://savannah.gnu.org/cvs/?group=coreutils Otherwise, please use this slightly dated test release: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
minor mkdir bug fixes
There was a long-standing, mostly-theoretical bug in mkdir and mkdir-p.c.
It would cause trouble only when `mkdir -p' changed into some directory
but was unable to change back to an initially unsearchable directory.
In that case, the unfixed code would nonetheless continue processing
subsequent command line arguments. And if one were a relative directory
name, it would try to create it in the wrong place. Before this patch,
mkdir -p /tmp/a/b u would mistakenly create /tmp/a/u under those
circumstances.
As far as I can see, this bug is triggered only when running the command
from a chmod 0'd directory on a Linux system (or any other type of
system where getcwd works even when called from such a directory).
And since the only way to get into such a directory in the first place
is to cd into it before the permissions are restricted and then run e.g.,
`chmod 0 .', this isn't likely to happen to many actual users :)
See the new test script for details.
NEWS:
mkdir -p /tmp/a/b dir no longer attempts to create the `.'-relative
directory, dir (in /tmp/a), when, after creating /tmp/a/b, it is unable
to return to its initial working directory.
ChangeLog
-
2005-06-13 Jim Meyering [EMAIL PROTECTED]
* src/mkdir.c (main): Give a diagnostic for -- and skip -- each
relative directory name after make_dir_parents fails to restore
the working directory. Before, `mkdir -p' could create directories
in the wrong place in unusual circumstances.
* src/install.c (main): Likewise.
(install_file_in_file_parents): Update make_dir_parents caller.
* tests/mkdir/p-3: New test for today's mkdir.c/mkdir-p.c bug fixes.
* tests/mkdir/Makefile.am (TESTS): Add p-3.
lib/ChangeLog
-
2005-06-14 Jim Meyering [EMAIL PROTECTED]
* mkdir-p.c (CLEANUP_CWD): Return *true*, not false when failing
to restore initial working directory.
2005-06-13 Jim Meyering [EMAIL PROTECTED]
* mkdir-p.c (make_dir_parents): New parameter: different_working_dir,
to tell caller if/when we change the working directory and are
unable to return to the initial one.
* mkdir-p.h (make_dir_parents): Update prototype.
2005-06-12 Jim Meyering [EMAIL PROTECTED]
* mkdir-p.c (CLEANUP_CWD): Change one more `return 1' to
`return false'. This fixes a bug introduced on 2004-07-30.
Index: src/mkdir.c
===
RCS file: /fetish/cu/src/mkdir.c,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -p -u -r1.97 -r1.98
--- src/mkdir.c 2 Jun 2005 05:17:24 - 1.97
+++ src/mkdir.c 13 Jun 2005 10:17:36 - 1.98
@@ -87,6 +87,7 @@ main (int argc, char **argv)
const char *verbose_fmt_string = NULL;
int exit_status = EXIT_SUCCESS;
int optc;
+ bool cwd_not_restored;
initialize_main (argc, argv);
program_name = argv[0];
@@ -145,15 +146,29 @@ main (int argc, char **argv)
umask (umask_value);
}
+ /* FIXME: when we assume C99, declare this here. */
+ cwd_not_restored = false;
for (; optind argc; ++optind)
{
bool ok;
+ if (cwd_not_restored IS_RELATIVE_FILE_NAME (argv[optind]))
+ {
+ error (0, 0, _(unable to create relative-named directory, %s,
+ due to prior failure to restore working directory),
+quote (argv[optind]));
+ exit_status = EXIT_FAILURE;
+ continue;
+ }
+
if (create_parents)
{
+ bool different_cwd;
char *dir = argv[optind];
ok = make_dir_parents (dir, newmode, parent_mode,
--1, -1, true, verbose_fmt_string);
+-1, -1, true, verbose_fmt_string,
+different_cwd);
+ cwd_not_restored |= different_cwd;
}
else
{
Index: src/install.c
===
RCS file: /fetish/cu/src/install.c,v
retrieving revision 1.179
retrieving revision 1.180
diff -u -p -u -r1.179 -r1.180
--- src/install.c 2 Jun 2005 05:13:29 - 1.179
+++ src/install.c 13 Jun 2005 10:19:18 - 1.180
@@ -357,11 +357,25 @@ main (int argc, char **argv)
if (dir_arg)
{
int i;
+ bool cwd_not_restored = false;
for (i = 0; i n_files; i++)
{
+ bool different_cwd;
+ if (cwd_not_restored IS_RELATIVE_FILE_NAME (argv[optind]))
+ {
+ error (0, 0,
+_(unable to create relative-named directory, %s,
+ due to prior failure to restore working directory),
+quote (argv[optind]));
+ ok = false;;
+ continue;
+ }
+
ok =
make_dir_parents (file[i], mode, mode, owner_id, group_id, false,
- (x.verbose
Re: minor mkdir bug fixes
Thanks for all of your cleanup work and for catching the true/false bug!
Paul Eggert [EMAIL PROTECTED] wrote:
I found some more glitches in the mkdir code. Occasionally multiple
diagnostics might be generated where one would do. The diagnostics
I spotted another problem.
install -d could still create directories in the wrong place, albeit only
under contrived conditions. That was due to a typo in one of my changes.
I've just fixed that and added to the existing tests/install/basic-1
test script so it would detect the resulting failure.
could report the error number, but didn't. In one unlikely case in
'install', the code would install the file into the wrong place.
If the bug is not too hard to test for, would you please create a
test case for it, so it'll be less likely to be reintroduced later?
These corner case bugs are hard enough to find.
If we don't record/document them via test cases,
we can't even hope to converge on correctness.
Also, there's no need for make_dir_parents to invoke 'stat' each time
through the loop. It can just rely on information gleaned from the
other system calls. In theory even the first stat could go but I'm
not sure that would improve performance on the average, since mkdir
-p /some/existing/file must be a common case.
Finally, there was a new small bug in mkdir-p.c.
Patch and test case below.
2005-06-15 Jim Meyering [EMAIL PROTECTED]
* lib/mkdir-p.c (make_dir_parents): Don't let a failed chdir($PWD)
stop us from restricting permissions of just-created absolute-named
directories.
* tests/mkdir/p-3: Add a test for just-fixed bug in mkdir-p.c.
* src/install.c (main): Fix my typo: s/argv[optind]/file[i]/.
* tests/install/basic-1: Ensure that each `-d'-specified directory
is created. Ensure that rel-named dirs are not created when
chdir($PWD) fails.
Index: lib/mkdir-p.c
===
RCS file: /fetish/cu/lib/mkdir-p.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -u -r1.7 -r1.8
--- lib/mkdir-p.c 14 Jun 2005 23:56:49 - 1.7
+++ lib/mkdir-p.c 15 Jun 2005 08:31:44 - 1.8
@@ -319,7 +319,8 @@ make_dir_parents (char const *arg,
for (; leading_dirs != NULL; leading_dirs = leading_dirs-next)
{
leading_dirs-dirname_end[0] = '\0';
- if (cwd_problem || chmod (full_dir, parent_mode) != 0)
+ if ((cwd_problem *full_dir != '/')
+ || chmod (full_dir, parent_mode) != 0)
{
error (0, (cwd_problem ? 0 : errno),
_(cannot change permissions of %s), quote (full_dir));
Index: tests/mkdir/p-3
===
RCS file: /fetish/cu/tests/mkdir/p-3,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -u -r1.3 -r1.4
--- tests/mkdir/p-3 14 Jun 2005 09:00:00 - 1.3
+++ tests/mkdir/p-3 15 Jun 2005 08:32:11 - 1.4
@@ -18,6 +18,7 @@ mkdir -p $tmp || framework_failure=1
cd $tmp || framework_failure=1
mkdir no-access || framework_failure=1
mkdir no-acce2s || framework_failure=1
+mkdir no-acce3s || framework_failure=1
if test $framework_failure = 1; then
echo $0: failure in testing framework 12
@@ -26,16 +27,25 @@ fi
p=$pwd/$tmp
(cd no-access; chmod 0 . mkdir -p $p/a/b u/v) 2 /dev/null fail=1
+test -d $p/a/b || fail=1
# Same as above, but with a following *absolute* name, it should succeed
-(cd no-acce2s; chmod 0 . mkdir -p $p/a/b $p/z) || fail=1
-
-test -d $p/a/b || fail=1
-b=`ls $p/a|tr -d '\n'`
+(cd no-acce2s; chmod 0 . mkdir -p $p/b/b $p/z) || fail=1
test -d $p/z || fail=1
+b=`ls $p/a|tr -d '\n'`
# With coreutils-5.3.0, this would fail with $b=bu.
test x$b = xb || fail=1
+# Ensure that the re_protect code is run on absolute names, even
+# after failure to return to the initial working directory.
+# This is actually a test of the underlying mkdir-p.c code.
+# The part in question cannot be tested via mkdir(1) because that
+# program cannot create leading directories that lack u=wx permissions,
+# so we have to test with install (aka ginstall in the build directory).
+(cd no-acce3s; chmod 0 . ginstall -m 0 -d $p/c/b $p/y/z) || fail=1
+p=`ls -ld $p/y|sed 's/ .*//'`
+case $p in d-);; *) fail=1;; esac
+
exit $fail
Index: src/install.c
===
RCS file: /fetish/cu/src/install.c,v
retrieving revision 1.184
retrieving revision 1.185
diff -u -p -u -r1.184 -r1.185
--- src/install.c 14 Jun 2005 23:55:24 - 1.184
+++ src/install.c 15 Jun 2005 08:54:21 - 1.185
@@ -360,7 +360,7 @@ main (int argc, char **argv)
int cwd_errno = 0;
for (i = 0; i n_files; i++)
{
- if (cwd_errno != 0 IS_RELATIVE_FILE_NAME (argv[optind]))
+ if (cwd_errno != 0 IS_RELATIVE_FILE_NAME (file[i]))
{
error (0, cwd_errno
Re: digest algorithm performance
[EMAIL PROTECTED] wrote: I haven't looked too deeply into this, so this is just a heads up. Yep. I mentioned that coreutils/TODO wrt md5sum: Look into improving the performance of md5sum. `openssl md5' is consistently about 30% faster than md5sum on an idle AMD 2000-XP system with plenty of RAM and a 261 MB input file. openssl's md5 implementation is in assembly, generated by a perl script. I suspect their sha1 code is similar. I'd welcome patches to improve the performance of either. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Shred documentation
Mark Melahn [EMAIL PROTECTED] wrote: The following patches make the shred man page and doc/coreutils.texi documentation on shred more specific, to reflect the fact that shred should, in fact, work normally in all ext3 journaling modes except data=journal mode. Previous documentation gave the impression that that shred was ineffective on ext3, period. Thank you for those. I've applied them, but had to do it manually, because your mail client split some long lines. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cut(1) feature request
Philip Rowlands [EMAIL PROTECTED] wrote:
I'm missing a feature in cut(1) and wanted to know if i) one can change
the behaviour of the return fields or ii) add an additional parameter
(let's say -F) to GNU cut. The latter option would ensure that things
don't get broken, whereas the first option seems more intuitiv.
The spec mandates that the selected fields be returned in order:
http://www.opengroup.org/onlinepubs/009695399/utilities/cut.html
Note in the rationale section the proposal to add -o as as argument
to indicate that list order should be preserved.
Whether or not GNU cut should use the exact argument -o, I think it
would be a useful feature. I can't speak for the coreutils maintainer,
but patches are usually welcome, especially if supplied with good
documentation and testing.
Many have been tempted to make such an addition.
I've tried to resist it, because this is something
that can already be done easily with other widely available tools.
You can use awk like this:
$ printf 'a b c d e f\n'|awk '{print $2,$1,$5}'
b a e
Or if you want to use e.g., `:' as the input field separator,
$ printf 'a:b:c:d:e:f\n'|awk -F: '{print $2,$1,$5}'
b a e
Then you don't have to worry about using some non-portable
GNU extension to cut in your scripts.
In spite of all of that, the existing behavior (of not honoring
the user-specified field/column-number ordering) is non-intuitive
enough that I'd consider a patch adding an option to make cut
provide the more sensible behavior.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: deref-args test and nfs
Kevin Mudrick [EMAIL PROTECTED] wrote: The make check deref-args test seems to fail on an nfs-mounted directory where attribute-caching is turned on, due to the block size including some extra information besides the file. Using du -bkD slink-to-64k instead, to rely on the file size rather than number of blocks, seems to work fine though. Thanks for the report! I've made this change: 2005-06-21 Jim Meyering [EMAIL PROTECTED] * tests/du/deref-args: Use --apparent-size to avoid the vagaries of counting blocks. Kevin Mudrick reported that this test would fail on an nfs-mounted directory where attribute-caching is turned on. Index: tests/du/deref-args === RCS file: /fetish/cu/tests/du/deref-args,v retrieving revision 1.6 retrieving revision 1.7 diff -u -p -u -r1.6 -r1.7 --- tests/du/deref-args 30 Jun 2004 22:51:11 - 1.6 +++ tests/du/deref-args 21 Jun 2005 08:45:19 - 1.7 @@ -34,10 +34,10 @@ du -D slink | sed 's/^[0-9][0-9]* //' du -D slink/ | sed 's/^[0-9][0-9]* //' out # Ensure that -D makes du dereference even symlinks to non-directories. -# The sed command maps the 68 I get on an ext3 file system to the 64 I expected. -# On tmpfs, I get 64. Similarly, on SELinux-enabled systems, file security -# context labels take up file system space, making du print 72 here. -du -kD slink-to-64k | sed 's/^[67][0-9]/64/' out +# Be sure to use --apparent-size. Otherwise, we'd get varying block counts +# depending on file system type (e.g. 68 on ext3 vs. 64 on tmpfs and 72 +# on SELinux-enabled systems). +du --apparent-size --block-size=1K -D slink-to-64k out cat \EOF exp slink/a slink ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: digest algorithm performance
[EMAIL PROTECTED] wrote: ... OK, I'll have a look. FreeBSD seems to be faster again, (don't compare these results to the previous mail): [I've just noticed you used `sha1' below. Is that a shell alias or function? The program from coreutils is called sha1sum. ] $time sha1 15MBfile 51e673b839d5bee3293fa2f1dd58c69face9770a ... $time openssl sha1 15MBfile 51e673b839d5bee3293fa2f1dd58c69face9770a ... FYI, here are a few more data points: On an AMD-64 system, using a 700MB file on a tmpfs file system (and enough RAM so that no actual disk reads are performed), GNU md5sum is slightly faster than `openssl md5', e.g.: 2.38s user 0.38s system 100% cpu 2.756 total (gnu md5sum) vs. 2.52s user 0.34s system 100% cpu 2.869 total However, `openssl sha1' is about 5% faster than GNU sha1sum: 3.32s user 0.33s system 99% cpu 3.653 total (openssl sha1) 3.45s user 0.39s system 99% cpu 3.843 total (gnu sha1sum) The above are using the debian-sid (amd_64 alioth) binaries from coreutils-5.2.1. When I compile the latest (coreutils-cvs) with gcc-4.0 -O3, I get slightly (2-3%) better sha1sum performance, and a ~7% *decrease* in performance for md5sum. I suspect that with the right compiler options you can do much better. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Does mv Preserve Hard Links?
[EMAIL PROTECTED] wrote: Does `mv (coreutils) 5.2.1' preserve hard links? In particular Yes. If you can make it fail to preserve links, please report it with as much detail as possible. Also, you might want to try the latest test release: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2 or even the latest from cvs: http://savannah.gnu.org/cvs/?group=coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested enhancement to du command - show last modified date.
William Brendling [EMAIL PROTECTED] wrote:
The second iteration of my patch to du to show last modified date follows.
...
Thank you for the patch.
I've applied it, albeit with some difficulty due to changes
in leading white space and split lines caused no doubt by your
mail client.
I've made some minor additional changes:
* src/du.c (show_date): Rename local `time_format' so as not to
shadow the file-scoped global by that name.
(show_date): Add a FIXME comment.
* src/du.c: Include hard-locale.h and strftime.h.
(DUINFO_INI, DUINFO_SET, DUINFO_ADD):
Enclose body in `do {...} while (0)', not just `{...}'.
Adjust uses (add semicolons).
Adjust formatting, indentation.
(usage): Tweak formatting to maintain more or less constant indentation.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: exit status of rm
[EMAIL PROTECTED] (James Youngman) wrote: On Thu, Jun 23, 2005 at 08:45:05PM +, Eric Blake wrote: This puts the invocation of rm without arguments in the implementation's realm, where currently, coreutils is not consistent on what it returns: $ rm rm: missing operand Try `rm --help' for more information. $ echo $? # used improperly 1 $ rm -f $ echo $?# all (zero) calls to unlink succeeded 0 Personally I think this is exactly the right way to do it (both cases). Same here. FYI, Solaris' /bin/rm is similar (though it's 2 and 0). On NetBSD 1.6 /bin/rm exits with status 1 in both cases. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: canon-host.c disagreement (gnulib vs coreutils); zero initializers
Paul Eggert [EMAIL PROTECTED] wrote:
I noticed the following disagreement between gnulib and coreutils:
--- gnulib/lib/canon-host.c 2005-05-13 23:03:57 -0700
+++ cu/lib/canon-host.c 2005-05-14 00:58:06 -0700
...
I assume that this was due to a warning from gcc -W about a missing
initializer. But I prefer the gnulib style: it's easier to read.
Probably.
How about if we just ask people to not use gcc -W?
While we're on the subject, I've noticed that glibc is now using this style:
struct addrinfo hint = { 0, };
The extra comma is an indication to the reader that we know there are
missing zeros, and don't care. This style can be used for any object
in C89, e.g.:
mbstate_t initial_state = { 0, };
That's nice to know. Thanks.
where we don't know whether mbstate_t is a structure, or an integer,
and the code works either way.
So, I propose that we make the following patch to gnulib, and propagate
this to coreutils:
2005-06-23 Paul Eggert [EMAIL PROTECTED]
* canon-host.c (canon-host): Append trailing , to 0 in
initializer of struct addrinfo, as an indication that we don't
care how many members the structure has.
Fine. Thanks.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
