Re: UNIX comm command does not work with underscore _
That looks like a locale issue. Try setting LC_ALL=C in the environment. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
infloop in `make check' on FreeBSD 5.0: due to /bin/sh?
FYI: I've just added this warning to coreutils' README file: *** FreeBSD 5.0 `make test' infinite loop with /bin/sh --- When building and running `make test' on a FreeBSD 5.0 system, expect the tests/install/trap test to get stuck in an infinite loop. That appears to be due to a bug in /bin/sh. When you change the first line of the tests/install/trap script to be e.g., #!/usr/local/bin/bash, the test completes normally. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Eric Blake [EMAIL PROTECTED] wrote: According to Dr. David Alan Gilbert on 9/26/2005 11:17 AM: $ mkdir a b $ ln -s $PWD/a sym $ mv sym/ b mv: cannot move `sym/' to `b/sym': Not a directory Nod. Perhaps the warning needs a warning that it can't be relied on? No, POSIX requires rename(sym/, name) to move the directory, not the symlink, so the warning is accurate and should apply to all systems, whether or not their rename is conformant. You may also want to check what `type mv` prints, in case you have an alias in place that strips trailing slashes. As you can imagine, I find the POSIX-required behavior to be senseless. The above behavior of non-POSIX rename, seen on Linux-2.6.x, is fine. Now that Linux/glibc provides a sane rename function, I'm tempted to make mv work in the above manner on all systems rather than allowing the crazy move-pointed-to-directory behavior on systems with a technically-conforming rename. The wrapper will incur the expense of a syscall or two on losing systems when the first argument ends with `/'. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: infloop in `make check' on FreeBSD 5.0: due to /bin/sh?
Jim Meyering [EMAIL PROTECTED] writes: FYI: I've just added this warning to coreutils' README file: *** FreeBSD 5.0 `make test' infinite loop with /bin/sh --- When building and running `make test' on a FreeBSD 5.0 system, expect the tests/install/trap test to get stuck in an infinite loop. That appears to be due to a bug in /bin/sh. I didn't see the original bug report, but if that /bin/sh bug is what I think it might be, the following patch would work around the problem. Can this be tried out on FreeBSD 5.0? 2005-09-28 Paul Eggert [EMAIL PROTECTED] * tests/install/trap: Work around a bug in FreeBSD 5.0. --- trap.~1.3.~ 2005-04-20 17:30:35.0 -0700 +++ trap2005-09-28 10:32:31.0 -0700 @@ -23,10 +23,13 @@ fi fail=0 -# ash doesn't support trap '' CHLD; it knows only signal numbers. -sig=`$pwd/../../src/kill -l CHLD 2/dev/null` trap '' $sig +# Use a subshell and an exec to work around a bug in FreeBSD 5.0 /bin/sh. +( + # ash doesn't support trap '' CHLD; it knows only signal numbers. + sig=`$pwd/../../src/kill -l CHLD 2/dev/null` trap '' $sig -# Before 2004-04-21, install would infloop, in the `while (wait...' loop: -ginstall -s $pwd/../../src/ginstall$EXEEXT . + # Before 2004-04-21, install would infloop, in the `while (wait...' loop: + exec ginstall -s $pwd/../../src/ginstall$EXEEXT . +) (exit $fail); exit $fail ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: infloop in `make check' on FreeBSD 5.0: due to /bin/sh?
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: FYI: I've just added this warning to coreutils' README file: *** FreeBSD 5.0 `make test' infinite loop with /bin/sh --- When building and running `make test' on a FreeBSD 5.0 system, expect the tests/install/trap test to get stuck in an infinite loop. That appears to be due to a bug in /bin/sh. I didn't see the original bug report, but if that /bin/sh bug is what Nelson Beebe reported it privately. I think it might be, the following patch would work around the problem. Can this be tried out on FreeBSD 5.0? That works, so I've applied it and reverted the README change. Thanks. 2005-09-28 Paul Eggert [EMAIL PROTECTED] * tests/install/trap: Work around a bug in FreeBSD 5.0. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Jim Meyering [EMAIL PROTECTED] writes: As you can imagine, I find the POSIX-required behavior to be senseless. Two things. First, I recall that you preferred the non-POSIX behavior because of file name completion issues. But because we agitated about this a while ago, Bash now does a better job with file name completion. For example, given this: mkdir dir ln -s dir symlink If I type mv sym[TAB], where [TAB] stands for a tab character, the screen then looks like this: mv symlink If I type another [TAB] it then looks like this: mv symlink/ so I'm given a signal from Bash that I have a symlink to a directory, and that it matters whether there's a trailing slash. In the old days this didn't happen, the intermediate step was missing, and so there was more of an argument that mv symlink/ target should ignore the slash. Nowadays, though, isn't that argument weaker? Second, I just read the POSIX spec and it seems to be a bit buggy http://www.opengroup.org/onlinepubs/009695399/functions/rename.html. The rationale says Renaming dot or dot-dot is prohibited but I can't see anything to that effect in the text itself. Furthermore, POSIX says that a pathname like abc/ must be resolved as if it were abc/. (see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11) so arguably rename(abc/, def) must be handled like rename(abc/., def) and if renaming dot or dot-dot is prohibited (which I think it must be, even if it's omitted inadvertently from the standard) then this must fail. There's a similar issue with rmdir symlink/. It's not clear that rmdir (symlink/) should succeed, because pathname resolution indicates that it should be treated like rmdir (symlink/.) and this clearly must fail. Clearly it's a messy area. My kneejerk reaction is that I might prefer it if mv symlink/ foo and rmdir symlink/ always failed, if only because in a confusing situation like this it's often better to use the Hippocratic rule: first, do no harm. It would be easy to implement that rule: it wouldn't require any system calls at all, since we could simply reject all file names with trailing slashes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
[cc-ing bash-completion maintainer] First, I recall that you preferred the non-POSIX behavior because of file name completion issues. But because we agitated about this a while ago, Bash now does a better job with file name completion. For example, given this: mkdir dir ln -s dir symlink If I type mv sym[TAB], where [TAB] stands for a tab character, the screen then looks like this: mv symlink If I type another [TAB] it then looks like this: mv symlink/ This assumes, of course, that you don't have 'set mark-symlinked-directories on' in your ~/.inputrc, at which point a single [TAB] completes the trailing slash. On the other hand, with the bash-completion package, it might make sense for programmable completion for mv, cp, and rm to omit the trailing slash in spite of the mark-symlinked-directories setting. The only argument against this is that there is no way to know whether the user really meant to move (or copy or delete) the symlink to a directory, vs. a file located in the directory, until they move on to the next word or hit Enter. This was the entire reason that mark-symlinked-directories exists in readline, and --strip-trailing-slashes exists as an option to mv and cp. On a related note, why don't rm and rmdir have a --strip-trailing-slashes option? so I'm given a signal from Bash that I have a symlink to a directory, and that it matters whether there's a trailing slash. Second, I just read the POSIX spec and it seems to be a bit buggy http://www.opengroup.org/onlinepubs/009695399/functions/rename.html. The rationale says Renaming dot or dot-dot is prohibited but I can't see anything to that effect in the text itself. Agreed - we should bring this up with the austin group. Something along the lines of this statement from rmdir(): If the path argument refers to a path whose final component is either dot or dot-dot, rmdir() shall fail. ... [EINVAL] The path argument contains a last component that is dot. Furthermore, POSIX says that a pathname like abc/ must be resolved as if it were abc/. (see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_1 1) so arguably rename(abc/, def) must be handled like rename(abc/., def) and if renaming dot or dot-dot is prohibited (which I think it must be, even if it's omitted inadvertently from the standard) then this must fail. I agree with your logic here on rename(2) needing to fail on a trailing slash if it is also supposed to fail on a trailing dot. But that doesn't necessarily mean that mv(1) need to fail on a trailing slash or dot. There's a similar issue with rmdir symlink/. It's not clear that rmdir (symlink/) should succeed, because pathname resolution indicates that it should be treated like rmdir (symlink/.) and this clearly must fail. Oops - cygwin has a bug in this regards: $ mkdir dir $ rmdir dir/. $ echo $? 0 $ ls dir ls: dir: No such file or directory Is it worth patching coreutils rm and rmdir to work around buggy systems that don't follow this POSIX restriction on rmdir()? (Meanwhile, I will try to get cygwin fixed.) Should we update the coreutils testsuite? My kneejerk reaction is that I might prefer it if mv symlink/ foo and rmdir symlink/ always failed, if only because in a confusing situation like this it's often better to use the Hippocratic rule: first, do no harm. It would be easy to implement that rule: it wouldn't require any system calls at all, since we could simply reject all file names with trailing slashes. You could probably convince me that your proposed approach of always rejecting an operation with a trailing slash is valid, as long as the error message gives a hint to the user on how to do what they wanted, and as long as --strip-trailing-slashes still worked. On the other hand, since 'mv symlink/ foo' invokes underspecified behavior in rename(2), maybe we can get away with deciding that mv(1) always behaves as --strip-trailing-slashes - is there anything in POSIX that would prohibit us from always stripping the trailing slash and acting on the symlink without an explicit option requesting that behavior? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: As you can imagine, I find the POSIX-required behavior to be senseless. Two things. First, I recall that you preferred the non-POSIX behavior because of file name completion issues. But because we agitated about this a That was indeed a motivator, since it made the commands with ambiguous syntax more likely. while ago, Bash now does a better job with file name completion. For example, given this: ... and so there was more of an argument that mv symlink/ target should ignore the slash. Nowadays, though, isn't that argument weaker? Even if bash fixes things to make this less likely, there's still plenty of room for user error and confusion, especially since less-seasoned users still use shells that cannot -- or are not configured to -- clean up the syntax of their commands. Personally, this hasn't affected me for some time (since I switched to zsh). zsh can be configured so that it completes the trailing slash in I type mv symliTAB zsh does this: mv symlink/ But the moment I type the space after the zsh-added `/', zsh removes that slash. If I type the slash, zsh leaves it. That said, I looked in some old command history logs and see hundreds of commands I typed (back before using zsh) including trailing slashes like this: mv dir/ new-name I know lots of people who would be very annoyed if they had to change habits or even just add an option via an alias to avoid failure in cases like those. Second, I just read the POSIX spec and it seems to be a bit buggy http://www.opengroup.org/onlinepubs/009695399/functions/rename.html. The rationale says Renaming dot or dot-dot is prohibited but I can't see anything to that effect in the text itself. Furthermore, POSIX says that a pathname like abc/ must be resolved as if it were abc/. (see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11) so arguably rename(abc/, def) must be handled like rename(abc/., def) and if renaming dot or dot-dot is prohibited (which I think it must be, even if it's omitted inadvertently from the standard) then this must fail. There's a similar issue with rmdir symlink/. It's not clear that rmdir (symlink/) should succeed, because pathname resolution indicates that it should be treated like rmdir (symlink/.) and this clearly must fail. Clearly it's a messy area. My kneejerk reaction is that I might prefer it if mv symlink/ foo and rmdir symlink/ always failed, if only because in a confusing situation like this it's often better to use the Hippocratic rule: first, do no harm. It would be easy to implement that rule: it wouldn't require any system calls at all, since we could simply reject all file names with trailing slashes. IMHO, such a move [making mv fail for any source argument specified with a trailing slash] would `do harm' :-) albeit to people's sensibilities when GNU mv starts griping, not to their files. I think the wrapper-induced overhead of an extra lstat imposed on losing systems, but only for operands with a trailing slash, is bearable. This is one of those `would be nice' things. But I'm not in any big hurry, since Linux 2.6.x does it right. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
[EMAIL PROTECTED] (Eric Blake) writes: Why don't rm and rmdir have a --strip-trailing-slashes option? I'd guess because that option is an ugly hack and we'd rather that the problem went away we should bring this up with the austin group. Perhaps, but let's figure out what we want first. I agree with your logic here on rename(2) needing to fail on a trailing slash if it is also supposed to fail on a trailing dot. But that doesn't necessarily mean that mv(1) need to fail on a trailing slash or dot. But POSIX says mv a/ b does the equivalent of rename(a/, b). So if you agree with the logic, then mv a/ b must fail. Oops - cygwin has a bug in this regards: $ mkdir dir $ rmdir dir/. $ echo $? 0 $ ls dir ls: dir: No such file or directory Is it worth patching coreutils rm and rmdir to work around buggy systems that don't follow this POSIX restriction on rmdir()? Naah, let's just get cygwin fixed. On the other hand, since 'mv symlink/ foo' invokes underspecified behavior in rename(2), maybe we can get away with deciding that mv(1) always behaves as --strip-trailing-slashes POSIX may be underspecified, but it's not _that_ underspecified. :-) I think one could argue that mv symlink/ foo should rename the target of the symlink (which is what Solaris does), or that it should fail (which is what I'd mildly prefer); but I don't see a way to read POSIX to say that it allows mv to ignore the slash. Note that, by this argument, mv dir/ foo should fail even if dir/ is an ordinary directory and is not a symlink. So it'd be kind of a big change. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
[EMAIL PROTECTED] (Eric Blake) wrote: As you can imagine, I find the POSIX-required behavior to be senseless. The above behavior of non-POSIX rename, seen on Linux-2.6.x, is fine. Now that Linux/glibc provides a sane rename function, I'm tempted to make mv work in the above manner on all systems rather than allowing the crazy move-pointed-to-directory behavior on systems with a technically-conforming rename. The wrapper will incur the expense of a syscall or two on losing systems when the first argument ends with `/'. If you do that, you need to make sure POSIXLY_CORRECT still gets the POSIX behavior of move-pointed-to-directory. But Not if I deem that behavior senseless :-) Can you imagine any real user (non-standards-weenie) *wanting* or even expecting that behavior? The few people I've shown that example to in person have always looked a little slack-jawed and expressed dismay that such silly behavior is mandated. wasn't this the reason that --strip-trailing-slashes was created as an option? That way, a user can do alias mv='mv --strip-trailing-slashes' and get the sane behavior of always moving the symlink, not the pointed-to-directory, regardless of whether rename() is conformant or not, and regardless of whether their shell's tab-completion puts slashes on symlinks-to-directories. Right. But as long as Linux's rename had the unwanted behavior, I was unwilling to impose the overhead of a wrapper. Now that constraint is removed. Meanwhile, since you think that the POSIX definition of rename() is insane, try filing an aardvark to allow an implementation-defined choice between moving the symlink/moving the directory, rather than the current mandated semantics of moving the directory. That way, Linux 2.6.x would still be able to comply to POSIX with what you term to be saner semantics (personally, I like the POSIX-mandated semantics, as it provides a consistent way to choose between operating on the symlink vs. operating on what it points to by the presence of the trailing slash, and it is not just rename() that is affected by POSIX semantics). Or you could file an aardvark on mv(1) to allow an implementation to always strip trailing slashes before calling rename(). I don't want to give myself that kind of work right now. Besides, I don't lose sleep if a GNU tool or two deviate from POSIX on corner cases like this. One way or another, we'll all converge, eventually. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Re2: coreutils v5.2.1 - stat.c
ThMO [EMAIL PROTECTED] writes: · even though the C compiler might be able to deal with 64-bit integer values, this must *not* be the case with the C pre-processor: #define ULLONG_MAX 18446744073709551615ULL the C compiler (gcc v2.7.2.1) *is* able to deal with that value, but the cpp can't Ouch. Thanks for reporting the problem; this is due, I think, to a change installed in January. Can you please try the following private snapshot instead? http://www.cs.ucla.edu/~eggert/coreutils-5.3.1-20050928-eggert.tar.gz It has the following patch installed (which I also installed into CVS coreutils): 2005-09-28 Paul Eggert [EMAIL PROTECTED] * m4/ullong_max.m4 (gl_ULLONG_MAX): Simplify so that it merely defines ULONG_MAX_LT_ULLONG_MAX. Thomas M.Ott reports that ULLONG_MAX doesn't work with 2.7.2.1. * src/system.h (LONGEST_MODIFIER): Use ULONG_MAX_LT_ULLONG_MAX instead of ULLONG_MAX, as the latter doesn't work with GCC 2.7.2.1. Index: m4/ullong_max.m4 === RCS file: /fetish/cu/m4/ullong_max.m4,v retrieving revision 1.2 diff -p -u -r1.2 ullong_max.m4 --- m4/ullong_max.m422 Jan 2005 06:25:53 - 1.2 +++ m4/ullong_max.m428 Sep 2005 22:04:09 - @@ -11,36 +11,17 @@ AC_DEFUN([gl_ULLONG_MAX], [ dnl Avoid _AC_COMPUTE_INT-related macros, as they may not work with dnl types wider than long int, due to problems with expr. - AC_CACHE_CHECK([for ULLONG_MAX], gl_cv_ullong_max, -[gl_cv_ullong_max=no - AC_EGREP_CPP([ULLONG_MAX is defined], - [ - #include limits.h - #ifdef ULLONG_MAX -ULLONG_MAX is defined - #endif - ], - [gl_cv_ullong_max=yes]) - case $gl_cv_ullong_max in - no) - for gl_expr in \ -18446744073709551615ULL \ -4722366482869645213695ULL \ -340282366920938463463374607431768211455ULL - do -AC_TRY_COMPILE([], - [char test[$gl_expr == (unsigned long long int) -1 ? 1 : -1]; - static unsigned long long int i = $gl_expr; - return i test;], - [gl_cv_ullong_max=$gl_expr]) - test $gl_cv_ullong_max != no break - done - esac]) - case $gl_cv_ullong_max in - yes | no) ;; - *) -AC_DEFINE_UNQUOTED([ULLONG_MAX], [$gl_cv_ullong_max], - [Define as the maximum value of the type 'unsigned long long int', - if the system doesn't define it, and if the system has that type.]);; - esac + AC_CACHE_CHECK([whether ULONG_MAX ULLONG_MAX], +[gl_cv_ulong_max_lt_ullong_max], +[AC_COMPILE_IFELSE( + [AC_LANG_BOOL_COMPILE_TRY( +[AC_INCLUDES_DEFAULT], +[[(unsigned long int) -1 (unsigned long long int) -1]])], + [gl_cv_ulong_max_lt_ullong_max=yes], + [gl_cv_ulong_max_lt_ullong_max=no])]) + if test $gl_cv_ulong_max_lt_ullong_max = yes; then +AC_DEFINE([ULONG_MAX_LT_ULLONG_MAX], 1, + [Define if ULONG_MAX ULLONG_MAX, even if your compiler does not + support ULLONG_MAX.]) + fi ]) Index: src/system.h === RCS file: /fetish/cu/src/system.h,v retrieving revision 1.136 diff -p -u -r1.136 system.h --- src/system.h23 Sep 2005 20:35:41 - 1.136 +++ src/system.h28 Sep 2005 22:04:09 - @@ -316,7 +316,7 @@ initialize_exit_failure (int status) # include stdint.h #endif -#if ULONG_MAX ULLONG_MAX +#if ULONG_MAX_LT_ULLONG_MAX # define LONGEST_MODIFIER ll #else # define LONGEST_MODIFIER l ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
Yes, cygwin (but again, that goes back to the rmdir(2) bug
in cygwin that I have just reported to the cygwin maintainers):
$ mkdir a
$ ln -s a b
$ rmdir b/
$ ls -F a b
ls: a: No such file or directory
b@
Whereas on sane systems (for example, Solaris 8):
$ mkdir a
$ ln -s a b
$ rmdir b/
rmdir: directory b/: Path component not a directory
$ rmdir b/.
rmdir: directory b/.: Can't remove current directory or ..
By Paul's argument, both uses should have failed with
EINVAL, since POSIX requires resolving symlink/ as
symlink/., and requires rmdir(symlink/. to fail with
EINVAL. Solaris 8 returned ENOTDIR in the first case, so
it appears they stripped the trailing slash (and their error
message leaves something to be desired in accuracy in
the second case). But at least it reliably failed instead
of removing a. I don't have access to other systems to
see what other behaviors might exist.
Is it worth patching coreutils rm and rmdir to work around buggy
systems that don't follow this POSIX restriction on rmdir()? (Meanwhile,
I will try to get cygwin fixed.) Should we update the coreutils testsuite?
It depends a whole lot on how invasive or complicated the patch is.
Ideally, it wouldn't change anything in src/*.c at all.
If cygwin doesn't get patched, it sounds like a gnulib module
to replace rmdir() is all that would be needed. Something like
this untested snippet (it would need to be cleaned up for
corner cases like , /, ., but you get the picture):
int
rpl_rmdir(const char* name)
{
int len = strlen (name);
if (name[len - 1] == '/'
|| (name[len - 1] == '.'
(name[len - 2] == '/'
|| (name[len - 2] == '.' name[len - 3] == '/'
{
errno = EINVAL;
return -1;
}
return rmdir (name);
}
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Re2: coreutils v5.2.1 - stat.c
ThMO [EMAIL PROTECTED] writes: · lib/getdate.y: I'm using bison v1.28 - and for me it's unacceptable, that this grammar can't be processed corrrectly with this older version, You shouldn't need to process it at all, since getdate.c is present in the source distribution. Perhaps the time stamps on your files were corrupted? it should also be processed by stock berkeley yacc But that wouldn't support reentrant parsers. getdate needs to be reentrant, for other projects. It should not be a problem anyway; you shouldn't need to run either Bison or Yacc. BTW, is anyone able to guarantee me, that bison v2.0 has not even one problem with processing older (and oldest - I'm using software packages dated in the early 80's) grammar files? Someone could guarantee you that, yes, if you paid them enough. :-) But the FSF isn't rich and can't afford to give out guarantees like that. bison --version clearly says There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. · src/su.c: This one tends to be so distribution-dependent that we're thinking of dropping 'su' from coreutils. · --disable-nls: IMHO there is no need, if I decide to configure *wihtout* NLS support, which I usually do, to setup a specific locale, --disable-nls affects only diagnostics and the like: it does not disable all usages of locales. For example, LC_CTYPE still affects whether something is considered to be a letter. the man-page should *always* reflect the various options, for which a command was configured for The dd man page has changed in the latest CVS version; perhaps the point is moot now. To be honest I didn't fully follow your comments. info coreutils dd works on my host and that is what the man page suggests. · factor: it's increddible - your factor command is *not* able to factorize negative values Patches would we welcome here. only this command knowns nothing about the --help switch Fixed in 5.3.0. · NEWS: why is the above bug, which I reported, *not* listed within the NEWS file, clearly stated as a fixed bug? NEWS reports only important user-visible fixes. I don't know which bug you meant by the above bug. If we forgot to put a bugfix in NEWS and it's important please tell it what it was. · fprintf, printf, fputs, fputc, putc, putchar: I may be wrong, but I seem to remember me, that some time ago the GNU conding style said something about *not* using each and every output function... I don't recall that as being a rule. Certainly these functions are all used in a lot of GNU code. · configure run: this 1.7 MB fat configure file is checking for a M$windog system? We'd like to make it smaller and faster, yes. Contributions toward that end would be welcome. They should go to autoconf-patches@gnu.org, since it's an Autoconf problem not a coreutils problem. · performance of the dd command: the execution speed of dd sucks heavily, Can you give a specific example of the problem? A shell transcript would help. Thanks again for your comments. (Though we don't really need to know about your sex life) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Jim Meyering [EMAIL PROTECTED] writes: Do you know of a system where `rmdir symlink/' removes only the referent of the symlink? Lots of systems do that, I expect. Solaris 10 does, for example. This is either with Solaris rmdir or coreutils 5.3.0 rmdir. I wouldn't be surprised if core commands other than mv and rmdir are affected by this issue as well. rm and ln come to mind, though I haven't tested them. Here's a transcript on Solaris 10 (sparc) with coreutils 5.3.0: 1018-otter $ ls -l total 2 drwxrwxr-x 2 eggert faculty 512 2005-09-28 15:18 dir lrwxrwxrwx 1 eggert faculty 3 2005-09-28 15:18 symlink - dir 1019-otter $ rmdir symlink/ 1020-otter $ ls -l total 1 lrwxrwxrwx 1 eggert faculty 3 2005-09-28 15:18 symlink - dir ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Jim Meyering [EMAIL PROTECTED] writes: I think the wrapper-induced overhead of an extra lstat imposed on losing systems, but only for operands with a trailing slash, is bearable. This is one of those `would be nice' things. But I'm not in any big hurry, since Linux 2.6.x does it right. Yes, I wouldn't be in any hurry either. Come to think of it, how about if we just stick to the current approach, and let 'mv' use the system rename() function and do whatever rename() does? Advantages of the current approach: * Easier to implement and maintain. * Solaris folks used to Solaris mv's behavior won't be surprised by GNU mv. * GNU mv conforms to POSIX, on POSIX-conforming hosts. (On non-POSIX hosts all bets are off anyway. :-) Disadvantages: * GNU mv behaves differently on different hosts. Similarly for rmdir and rmdir(), etc. I suppose either way, the eocumentation needs to explain the issue better. (Arrgh.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
FYI: upcoming test release to be called coreutils-5.90
The upcoming test release will be called coreutils-5.90. There have been so many changes since 5.3.0, that calling it 5.3.1 didn't seem right. Besides, having a 3-component version number isn't very useful now. 2005-09-28 Jim Meyering [EMAIL PROTECTED] * configure.ac: Use 5.90-cvs as the version string, not 5.3.1-cvs. * NEWS: Adjust accordingly. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
By a strict reading of
http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html,
'rm -R symlink/' should empty the referrant, then fail!
step 0: the command line does not end in .
step 1: symlink/ exists
step 2: 'symlink/' is of type directory ('symlink', on the other hand,
is of type symlink); this is the recursion, ending with the
referrant being emptied, and symlink and symlink/ still existing
step 3: 'symlink/' is a directory
step 4: call rmdir(symlink/), which should fail with EINVAL
But no implementation of rm(1) that I am aware of does this;
they all unlink symlink and call it quits, leaving the referrant
(and its contents) alone. We really do need to clean this up
with the austin group; surely they intended to document
historical behavior.
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Re2: coreutils v5.2.1 - stat.c
Paul Eggert wrote: ThMO [EMAIL PROTECTED] writes: · NEWS: why is the above bug, which I reported, *not* listed within the NEWS file, clearly stated as a fixed bug? NEWS reports only important user-visible fixes. I don't know which bug you meant by the above bug. If we forgot to put a bugfix in NEWS and it's important please tell it what it was. I could not find a NEWS entry on this item either. This is a significant enough item that I think it should have one. After I responded to Tom and the list I posted this note as a followup to the bug-coreutils list only. It seemed germane only to the coreutils developers on the list and so that is where I directed it. http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00178.html Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
