Re: coreutils 5.97: Adjust mkdir message (File exists)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jari Aalto wrote: Thanks, but File exists is just the English version of the strerror(EEXIST) string from the C library. Target exists would be more generic if message is based on the EEXIST error code. Considering that, as Jim points out just below, directories and symlinks are also files, how would target be any better? File is quite generic enough, without being as vague in meaning as target is (and I thought you were arguing for more specificity?) (Jim:) For one thing, in discussing file system objects, file is often used to refer to a generic object, be it symlink, block device, regular file, directory, etc. ... I'm inclined to say no, but there is precedent for examining the file type. The prompt you see when using rm's -i tells you about the type of the file it might remove. Sure; but then, it's asking whether you want to destroy something; the more information about what you're potentially obliterating, the better. In this case, mkdir's telling you it can't create a directory because something else is already there. Does it really matter what specific thing is there? Perhaps it's a directory, perhaps it's a file; it doesn't really matter, because regardless of what it is, you're not going to clobber it with a directory. Perhaps, in addition to performing an lstat(), mkdir should go ahead and ls -lR it (if it's a directory), or page it for you (if it's a text file), so you can make the most-informed decision as to whether to remove it and try again. :) At any rate, I suspect the realm into which this suggestion falls was probably clarified, once it was accompanied with the suggestion that mkdir generate a logfile. Given that there's no historical precedent for it, the message is accurate as it stands, and no one has established what benefit a change could provide, it seems to me that the burden of proof is a long way from being met. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhIbd7M8hyUobTrERAqMFAJ0ds6kGhU8anYer1nEZPtQIjZHn0ACeLcSn EKM4zbKQecQmvjLrCxvXf7Y= =fK8D -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 5.97: Adjust mkdir message (File exists)
Jari Aalto [EMAIL PROTECTED] wrote: ... Should mkdir have to perform an additional lstat so that it can include the type of the preexisting file system object when the mkdir functions fails with EEXIST? I'd welcome this. When error condition occures, it's a perfect place to provide more information. The information is not necessarily displayed to user, but stored to a log file, so when person looks at the logs later, he can get detailled view of the problem. ... Adding post-failure code to perform file system operations in order to give better diagnostics is not something to do lightly. I've done it for a few cases in coreutils, but only to avoid particularly misleading diagnostics. Sorry. It's not justified in this case. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Fix preserve_mode when destination directory partially exists
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: 2008-01-07 Jan Blunck [EMAIL PROTECTED] cp --parents: don't use uninitialized memory when restoring permissions In reviewing that patch I noticed that the bug of using uninitialized memory still remains in some (unlikely) cases. If 'stat (src, new-st)' fails, the resulting uninitialized new-st buffer still remains in the list of directories whose modes need fixing later. As far as I can tell the bug is triggered only in a race condition, where a directory is moved as we are trying to copy it, so it's hard to come up with a test case for it. However, here's a patch. 2008-01-08 Paul Eggert [EMAIL PROTECTED] Fix a minor race condition when using cp -p --parents. * src/cp.c (make_dir_parents_private): If stat fails on the parent directory, do not add it to the list of directories whose modes might need fixing later. Also, do not bother invoking 'stat' unless the stat results might be needed later. Good catch. I've applied and pushed that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: strange 'sort' behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please keep replies on the list, so that others may chime in or learn from the discussion. According to Eric Stockman on 1/9/2008 4:37 AM: | dear Eric , | Thanks a lot for the quick reply . | I added an export LC_ALL=POSIX in my .bash_aliases file and now | sort works as expected. | I still don't understand why . I'm using the English version of Ubuntu | see the next extracts from 'env' | --- | PWD=/home/eric | LANG=en_US.UTF-8 That's exactly why. As the FAQ explained, different locales have different collation (sorting) rules. It is the LC_COLLATE env-var (which defaults to LANG, but is overridden by LC_ALL) that controls this particular aspect of sort's behavior. And the en_US.UTF-8 collation rules prefers a dictionary sort (where certain punctuation characters compare equal) over the byte-wise value sort (which is what you get with the C locale; note that I generally use the identical LC_ALL=C as it is less typing than LC_ALL=POSIX). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhNCa84KuGfSFAYARAlaVAKDM/49q1F7Sj1EcpngTqv/1mXfkkACcC72Q jHFcFYbvlwT202DghFjbSK4= =HWxq -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ready for a final coreutils-6.9.9x test release
I'm ready to release coreutils-6.9.92, which should be the final test release before a stable coreutils-6.10. If you know of problems that you think should be addressed before then, please speak up now. I expect to release coreutils-6.9.92 in a day or two. In the mean time, here's the latest snapshot: http://meyering.net/cu/coreutils-ss.tar.gz8.8 MB http://meyering.net/cu/coreutils-ss.tar.lzma 3.6 MB http://meyering.net/cu/coreutils-ss.tar.gz.sig http://meyering.net/cu/coreutils-ss.tar.lzma.sig aka http://meyering.net/cu/coreutils-6.9.91.24-424fe.tar.gz http://meyering.net/cu/coreutils-6.9.91.24-424fe.tar.lzma http://meyering.net/cu/coreutils-6.9.91.24-424fe.tar.gz.sig http://meyering.net/cu/coreutils-6.9.91.24-424fe.tar.lzma.sig ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
