coreutils-6.9 problem with --preserve-timestamps
I just found an issue where coreutils-6.9 does not seem to work right with the --preserve=timestamps switch when copying to an nfs filesytem when the pwd is the same directory. I had a copy of the coreutils-5.0 available and it worked fine. cd /some/nfs/mounted/directory ll file -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 13:51 file GNU/Linux RH4, coreutil-6.9, coreutils-5.0 /bin/cp --preserve=timestamps file /tmp/file_1 /tools/wdtgnu/coreutils-6.9/bin/cp --preserve=timestamps file /tmp/file_2 /tools/wdtgnu/coreutils-5.0/bin/cp --preserve=timestamps file /tmp/file_3 /bin/cp --preserve=timestamps file ./file_1 /tools/wdtgnu/coreutils-6.9/bin/cp --preserve=timestamps file ./file_2 /tools/wdtgnu/coreutils-5.0/bin/cp --preserve=timestamps file ./file_3 ls -al /tmp/file_1 /tmp/file_2 /tmp/file_3 ./file_1 ./file_2 ./file_3 -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 13:51 ./file_1 -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 14:14 ./file_2BAD -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 13:51 ./file_3 -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 13:51 /tmp/file_1 -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 13:51 /tmp/file_2 -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 13:51 /tmp/file_3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Broken link
http://www.gnu.org/software/coreutils/ says: Coreutils can be found on ... one of our FTP mirrors http://www.gnu.org/prep/ftp . But the link to the mirrors is broken. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Command touch and irregular file names
Hi, How to let command touch to work with irregular file names? In my script I have touch -r $file1 $file2 the file1/2 can be anything file, ../path/file, /root/file, etc. The problem is when file1/2 are irregular file names. E.g., -test.file1/2. I.e., anyway to make the following touch command works? $ touch -r -test.file1 -test.file2 touch: invalid date format `est.file2' FYI, I tried this but didn't work: $ touch -r -- -test.file1 -test.file2 touch: invalid date format `est.file1' I think if the touch command uses the standard gnu getopt lib, then the above code should work, shouldn't it? Thanks tong ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Command touch and irregular file names
- Tong - wrote: In my script I have touch -r $file1 $file2 the file1/2 can be anything file, ../path/file, /root/file, etc. The problem is when file1/2 are irregular file names. E.g., -test.file1/2. I.e., anyway to make the following touch command works? $ touch -r -test.file1 -test.file2 touch: invalid date format `est.file2' You can do: $ touch -r ./-test.file1 -- -test.file2 If you want to automate this from the script I suppose you could try something like: touch -r $(readlink -f -- $file1) -- $file2 That is, express file1 with a full pathname, and -- should work for $file2 since it is a non-option argument. I think if the touch command uses the standard gnu getopt lib, then the above code should work, shouldn't it? I don't think it should. It would require much more context for a generic options parser to speculatively treat certain groupings of options as filenames, test for existance of those files, and change behavior dynamically. That kind of thing would be rife with corner cases, unexpected outcomes (e.g. -file names a filename that's not supposed to exist), maintenance nightmares, etc. Brian ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: printf --help
[EMAIL PROTECTED] (Karl Berry) wrote: The --help message for printf (coreutils 6.9) starts with this: Usage: /usr/local/gnu/bin/printf FORMAT [ARGUMENT]... or: /usr/local/gnu/bin/printf OPTION Print ARGUMENT(s) according to FORMAT. --help display this help and exit --version output version information and exit I'd like to suggest a tiny change, something like: Print ARGUMENT(s) according to FORMAT, or execute according to OPTION: Thanks. I've done that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.9 problem with --preserve-timestamps
Warren L Dodge wrote: I just found an issue where coreutils-6.9 does not seem to work right with the --preserve=timestamps switch when copying to an nfs filesytem when the pwd is the same directory. Thanks for the report. Could you run your test case again under 'strace' and report the result for the failing case? /tools/wdtgnu/coreutils-6.9/bin/cp --preserve=timestamps file /tmp/file_2 -rw-rw-r-- 1 warrend fusion2 6402 Aug 14 14:14 ./file_2BAD Try this: strace -e trace=file -o /tmp/cp.strace.out /tools/wdtgnu/coreutils-6.9/bin/cp --preserve=timestamps file /tmp/file_2 That should report useful information to understand what it is doing under the hood. Please send the resulting information back to the mailing list. Thanks Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Broken link
Shugart, Ashley J ERD-GSL-MS wrote: http://www.gnu.org/software/coreutils/ says: Coreutils can be found on ... one of our FTP mirrors http://www.gnu.org/prep/ftp . But the link to the mirrors is broken. Thank you for reporting that problem. The location of the mirrors page seems to have moved since that link was placed there. I have corrected it to the new location. It should correct now. Thanks again for the report. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Obsolete fileutils, shellutils, textutils web pages updated
Just an fyi... I have updated the web pages for the obsolete fileutils, shellutils, textutils to remove obsolete information leaving only the redirect to the new coreutils and also updated them to the new gnu.org html page templates. As Paul said when he updated the main coreutils page a while back, It does look fancier now. :-) Although the css diversions are not designed for short pages like those and so there are some display artifacts in my browser. I think for the obsolete pages this is not worth deviating from the site standard css to avoid those though. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in od with -j option?
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: + If the number of bytes left to skip is larger than + the size of the current file, we can decrement + n_skip and go on to the next file. */ if (S_ISREG (file_stats.st_mode) 0 = file_stats.st_size) An idle thought. Given the problems we've had elsewhere with /proc files that claim to be regular files of size zero, perhaps the above line should be changed to the following? if (S_ISREG (file_stats.st_mode) 0 file_stats.st_size) More generally, the idea is that if a file claims to be a regular file of size zero, then GNU utilities should not attempt to do optimizations based on the assumption that the file is empty, but should go ahead and try to actually read the file. It's kind of a pain to treat size-zero files specially, but there it is. Good catch. Yes, it is good to work around kernel lies, at least when it's recent Linux :-) I'll check that in this evening, along with a test. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: coreutils rm - win32 native port
First Bob, then Eric :) http://www.gnu.org/prep/standards/html_node/System-Portability.html#System-P ortability This policy explains why not initiate non-gnu-os porting (for which I have a good answer: I need it) - but not why to *reject* them. remove.c was almost completely re-written using the native WIN32 API. It now compiles with MSVC 2005 and works well. The reality is quite the opposite of what you've said: have you looked in remove.c ? It's full of sun's proprietary functions: openat() and similar; emulating them is a terrible performance hit (200+% more system calls is my estimation) and a headache. Had it been written with only opendir() and unlink(), it wouldn't have had to be re-written. Another thing is the code complexity in remove.c - I didn't quite understand why is it so big and complicated; but this is probably just me.. I really could have re-written it using opendir() and unlink() - but win32 was my main concern here. ( Here, opendir() and unlink() would serve a nice example of a near-portable API: it provides access to the underlying implementation using a DIR* opaque structure; yet it uses proprietary dirent for file information. ) -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 06:51 To: Aviad Lahav Cc: bug-coreutils@gnu.org Subject: RE: coreutils rm - win32 native port - I tried Mingw's MSYS now; it suffers from the problems similar to cygwin's: needs to be installed and needs a DLL. MSYS is a collection of mingw apps along with a shell; it encompasses several features including file name munging, above what a simple mingw application normally does. Using mingw does not require using MSYS. But complaints about MSYS or mingw are better directed at their mailing list, rather than here. - Why shouldn't coreutils accept native win32 ports? Because the GNU Coding Standards do not require bending backwards to support proprietary systems. It is counterproductive to our philosophy to add #ifdefs all over the portable code just for one non-free platform that does not believe in following standards. http://www.gnu.org/prep/standards/html_node/Compatibility.html#Compatib ility http://www.gnu.org/prep/maintain/maintain.html#Ethical-and- Philosophical-Consideration GNU make does. Only because someone volunteers to maintain it. So, if I volunteer to maintain win32 support, would coreutils accept the changes? I think native win32 support should be an objective of the project; And you are entitled to that opinion. However, Jim, as the primary maintainer, is of the contrary opinion that upstream coreutils is easier to maintain if it sticks to non-proprietary, portable APIs, and I agree with him. First, I tend to agree with GNU's approach here. Second, I think there's a confusion here: Posix/unix-like API is indeed non-proprietary, but it's *not portable* by no means; a portable API means it abstracts away any underlying OS objects using undefined structs and opaque void* types. for instance (a) it assumes a user/group identifier is always a uid_t/gid_t (integral type), (b) no support for arbitrary-file-system per-file information, such as hidden/system attribute on win32 or file version on VMS, hence there's no way of copying it from file to file (cp -p is hurt here). (c) It assumes the underlying FS has inodes; I guess cp's hardlink detection breaks when a linux machine mounts an NTFS. (d) as a design principle, it not only lacks extensibility mechanism, it explicitly precludes them. This is more of an anti-portability approach. I think a truly portable (and therefore extensible) OS API is a real need of the GNU community. A well-designed API could make lives much easier for everybody - users and maintainers. if not, the situation I described before won't be solved: win32 users will have endless choices of non-standard, not-entirely-working ports. That all depends on your definition of non-working. In my opinion, the cygwin port of coreutils works just fine (but I am a bit biased, as I maintain the cygwin port). I don't think you're the responsible for cygwin's non-working stuff. Such problems are inherent to cygwin as it supplies a posix API - which is not portable, as I said above. Cp -p could never preserve hidden file attributes using a posix emulation layer - to mention one burning example. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: coreutils rm - win32 native port
The reality is quite the opposite of what you've said: have you looked in remove.c ? It's full of sun's proprietary functions: openat() and similar; Those aren't Sun proprietary. They are being added by the next revision of POSIX, and have already been adopted by Linux. Cygwin is not far from adopting them as well. And for platforms that lack them, gnulib provides a good emulation. Furthermore, the use of openat() closes common security holes. In other words, Jim and Paul moved to the openat approach BECAUSE it is being standardized, in a freely accessible (non-proprietary) standards process. emulating them is a terrible performance hit (200+% more system calls is my estimation) and a headache. Had it been written with only opendir() and unlink(), it wouldn't have had to be re-written. And it previously was written in only opendir() and unlink(), and had bugs. We did the rewrite because it fixes data races and security holes. [One more note - on this list, we prefer comments in context, rather than top-posting] -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: coreutils rm - win32 native port
I'm sorry but this is getting much too religious debate, and I don't really have the time to spend on it. If you want the updates, I'll post them (along with additional changes to support mv cp). If not, it's a pity - I think you're turning against your users. -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 17:46 To: Aviad Lahav Cc: bug-coreutils@gnu.org Subject: RE: coreutils rm - win32 native port Only because someone volunteers to maintain it. So, if I volunteer to maintain win32 support, would coreutils accept the changes? If your changes are not deemed too invasive (you haven't even posted them yet), and if you have copyright assignment, then perhaps Jim will be willing to let you maintain such patches. But why not maintain them for a windows-specific port, rather than forcing those patches upstream on all platforms? First, I tend to agree with GNU's approach here. Second, I think there's a confusion here: Posix/unix-like API is indeed non-proprietary, but it's *not portable* by no means; a portable API means it abstracts away any underlying OS objects using undefined structs and opaque void* types. No, a portable API means that it compiles on multiple platforms (namely, all platforms which implement POSIX or a reasonable subset thereof). It has nothing to do with how much or little it abstracts away OS details. for instance (a) it assumes a user/group identifier is always a uid_t/gid_t (integral type), (b) no support for arbitrary-file-system per-file information, such as hidden/system attribute on win32 or file version on VMS, hence there's no way of copying it from file to file (cp -p is hurt here). In a portable world, you are correct - file attributes not specified by POSIX are inherently non-portable, so they cannot reasonably be expected to be managed by a portable application. Making cp -p preserve non-portable attributes is the wrong approach, instead, you should use an OS-specific application that is aware of the OS's non-portable extensions if you want those extensions preserved across copies. (c) It assumes the underlying FS has inodes; I guess cp's hardlink detection breaks when a linux machine mounts an NTFS. NTFS supports hardlinks and inodes just fine. Rather than guessing, why not test your claim. And if it really is broken on Linux accessing NTFS, then the bug is not in coreutils, but in the Linux NTFS file system layer. I think a truly portable (and therefore extensible) OS API is a real need of the GNU community. A well-designed API could make lives much easier for everybody - users and maintainers. You are more than welcome to join the Austin group and make your proposals for new portable APIs; but good luck getting it approved without any prior implementations to back it up. And don't go expecting us to rewrite code with years of history just to use your new APIs, if you can't prove that your approach is more sound than years of industry experience. I don't think you're the responsible for cygwin's non-working stuff. Such problems are inherent to cygwin as it supplies a posix API - which is not portable, as I said above. Cp -p could never preserve hidden file attributes using a posix emulation layer - to mention one burning example. And that's why I claim that cygwin is not broken - since hidden file attributes are outside the realm of POSIX and portability, I have no desire for cygwin's cp -p to try and preserve it. Rather, since it is an OS-specific attribute, I use OS-specific tools when I want the non-POSIX hidden attributes preserved across copies. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ar(1) issue building coreutils on 64-bit AIX
On Tue, 2007 Aug 14 08:47:07 +0200, Jim Meyering wrote: AR_FLAGS=-X64 cru coreutils doesn't use libtool, but it does use automake. And automake uses the ARFLAGS spelling. I lament the inconsistency, but that's a fair point. No need to edit Makefiles. Just invoke make with your ARFLAGS setting on the command line: make ARFLAGS=-X64 cru That's a bit more convenient, but my point was that the configure script should pick up that variable from the environment, as it does for CFLAGS, CPPFLAGS, LDFLAGS et al. (Libtool's autoconf bits already do this for AR_FLAGS.) --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = [EMAIL PROTECTED]## don't smell bad---(/o|o\) / EMAIL2 = [EMAIL PROTECTED] ## it's the people who(^), WWW= http://www.**.org/ ## annoy them that do!/ \ -- (** = site not yet online) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Could we have a flag to tell us which directories were actually removed?
I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. -- http://rrt.sc3d.org/ | violence, n. bravery for cowards ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
'futimens' name conflict with glibc-2.6.1 header file sys/stat.h
Hi internal 'futimens' name has conflict with glibc-2.6.1 header file sys/stat.h a patch would be wonderful Regards ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: coreutils rm - win32 native port
On Wed, 15 Aug 2007, Aviad Lahav wrote: I'm sorry but this is getting much too religious debate, Maintaining multi-platform utilities on which users of many of those platforms depend minute-by-minute is a tricky enterprise. I don't see any religious debate here, only a platform-specific versus a more general viewpoint. If you want the updates, I'll post them (along with additional changes to support mv cp). As Eric explains (and as for all GNU software), you'd need to assign copyright in them to the FSF. If not, it's a pity - I think you're turning against your users. Like yours, the GNU coreutils maintainers' time is limited. It's unrealistic to expect them simply to accept patches; apart from the legal aspect of copyright assignment, there is the maintenance burden. You've offered to take that on, which is great, but it's hardly surprising if the maintainers don't immediately believe that's going to work out. These things have to be taken a step at a time! It's great that you've offered to write and maintain a win32 port; it is perhaps possible, though, that you haven't appreciated how much work that is, and in particular that it's not simply a question of writing code. If you can commit to the required work, then do be patient and persevere, and you may be able to make a contribution that will benefit many GNU users on Windows. -- http://rrt.sc3d.org/ lawyer, n. one paid to make the inexcusable incomprehensible ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
DWIM feature request for cp
Hello, I want to ask the developers what do they think about implementing a way to do cp -r .* target (copy files and directories starting with dot) without copying the parent directory .. (I think that's what the user usually intends to do) Thank you all and keep the good work, Roberto -- Roberto Rodríguez http://www.robertorodriguez.com.ar ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: DWIM feature request for cp
Hello, I want to ask the developers what do they think about implementing a way to do cp -r .* target (copy files and directories starting with dot) without copying the parent directory .. (I think that's what the user usually intends to do) Won't work, globs is expanded by the shell not by cp. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Command touch and irregular file names
On Tue, 14 Aug 2007, - Tong - wrote: How to let command touch to work with irregular file names? FYI, I tried this but didn't work: $ touch -r -- -test.file1 -test.file2 touch: invalid date format `est.file1' That's nearly right; put the -- immediately following the last option, e.g. $ touch -r '-test.file1' -- '-test.file2' Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'futimens' name conflict with glibc-2.6.1 header file sys/stat.h
سید حسن فیروزآبادی wrote: internal 'futimens' name has conflict with glibc-2.6.1 header file sys/stat.h a patch would be wonderful Can you post the error message that you are seeing back to the mailing list? That would help us know what is happening. Thanks Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas [EMAIL PROTECTED] wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. Why add a new option? While adding a new rmdir option may look simple, there are larger implications that make it so you'd have to provide significant justification. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: DWIM feature request for cp
Roberto Rodríguez wrote:
Hello, I want to ask the developers what do they think about implementing a
way to do cp -r .* target (copy files and directories starting with dot)
without copying the parent directory .. (I think that's what the user
usually intends to do)
The first thing to think about is that the command line shell is where
the expansion is taking place. The 'cp' command does not see the *
and does not know that you have used a wildcard. You can verify what
the cp command is seeing by using the echo command.
echo cp -r .* target
The cp command is seeing the literal names that are being given to
it. Therefore it seems inconsistent to me to give it a name and then
add an option to tell it to ignore a name. Better simply not to give
the name to it in the first place.
If you are using GNU bash then it is pretty easy to avoid .. if you
want.
echo cp -r .!(.|) target/
That will expand to be every dot name except the . and .. name. The
command won't have those handed to it as an argument and won't have to
avoid them.
It is of course possible to do more fancy stuff too but personally I
would probably copy the directory from the directory above in that
case because then things get simple.
Also, if I want to do some complicated picking of filenames then I
would use 'find' for this.
find . -name 'foo*' -exec cp --target-directory=target {} +
find . -type d -exec cp --target-directory=target {} +
find . -type f -exec cp --target-directory=target {} +
The find command is very powerful and can select almost any
interesting combination of files.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. How about this? $ mkdir -p 1/2/3 11 $ rmdir -v 1 rmdir: removing directory, 1 rmdir: 1: Directory not empty $ echo $? 1 And this does not seem like the type of thing that needs to be optimized for keyboard use but sounds more like something in a script. In which case a little more verbose is okay. That leads me to this: for dir in *; do rmdir $dir echo removed: $dir # or whatever you want to do here done Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: DWIM feature request for cp
Alfred M. Szmidt scripsit: Hello, I want to ask the developers what do they think about implementing a way to do cp -r .* target (copy files and directories starting with dot) without copying the parent directory .. (I think that's what the user usually intends to do) Won't work, globs is expanded by the shell not by cp. Not so fast. It would be perfectly possible to have a switch --ignore-dots that made cp ignore all arguments whose basenames were . or ... I'm not sure if this is a Good Thing overall (you can achieve the same results with careful use of find and grep), but it should at least be thought about. -- John Cowan [EMAIL PROTECTED] http://www.ccil.org/~cowan Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive outside of the box thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: DWIM feature request for cp
2007/8/15, Bob Proulx [EMAIL PROTECTED]: If you are using GNU bash then it is pretty easy to avoid .. if you want. echo cp -r .!(.|) target/ OK, thank you all for your explanations. I wasn't aware of the expansion in shell. I'll read more about that in the Bash manpage. -- Roberto Rodríguez http://www.robertorodriguez.com.ar ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
On Wednesday, August 15 2007, Eric Blake wrote to Jonathan Lennox, bug-coreutils@gnu.org saying: (I reported this issue on the bug tracker on Savannah, but it looks like sending bug reports to this mailing list is preferred, so I'm repeating it here.) The bug-tracker forwards all edits to this list, so you just repeated yourself. Yes, I saw that on the web archive shortly after I sent the second message. Sorry about that. Mac HFS is the other biggest case-preserving case-insensitive system out there; can anyone comment on whether rename(2) is a no-op or changes case when given two case-wise distinct spellings of the same file? On Darwin, rename(2) does indeed change case given two spellings of the same file: $ uname -a Darwin woody.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386 $ touch foo $ echo *oo foo $ perl -e 'rename foo, Foo or die ($!)' $ echo *oo Foo Darwin's mv(1) code also has special-case code added to handle case-renaming a directory, to force mv foo Foo in that case to be the equivalent of coreutils mv's mv -T foo Foo. The code (BSD licensed) is at http://www.opensource.apple.com/darwinsource/10.4.9.x86/file_cmds-116.10/mv/mv.c; you might need to register for an Apple ID. -- Jonathan Lennox lennox at cs dot columbia dot edu ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
On Wed, 15 Aug 2007, Bob Proulx wrote: Reuben Thomas wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. How about this? $ mkdir -p 1/2/3 11 $ rmdir -v 1 rmdir: removing directory, 1 rmdir: 1: Directory not empty $ echo $? 1 And this does not seem like the type of thing that needs to be optimized for keyboard use but sounds more like something in a script. In which case a little more verbose is okay. That leads me to this: for dir in *; do rmdir $dir echo removed: $dir # or whatever you want to do here done I wanted this for keyboard use, for multiple directories: rmdir [--magic-flag] * in fact. Maybe it's just not common enough a case? -- http://rrt.sc3d.org/ | maximiste, n. pessimiste (Roux) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
On Wed, 15 Aug 2007, Jim Meyering wrote: Reuben Thomas [EMAIL PROTECTED] wrote: I just had a situation where this would have been useful. I tried -v --ignore-fail-on-non-empty, but of course it told me about every directory it processed, which is fine, but not what I wanted. Why add a new option? In this case, I don't see a good way of getting the same information. The best way I could come up with that was short enough for command-line use was use find to find directories with only 2 symlinks to them, but of course that only works on some filing systems. While adding a new rmdir option may look simple, there are larger implications that make it so you'd have to provide significant justification. What are they in this case? Seems to me that it's just printing a diagnostic on an already-existing code path (the one where the directory is unlinked), and hence has no major code burden. Of course there's the usual overhead of documentation c... -- http://rrt.sc3d.org/ | perfect, a. unsatirizable ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
FAT is always upper case and the driver forces it to lower case. VFAT ignores attempts to change case with rename(), in conformity to Posix. You missed my earlier remark - since POSIX requires case sensitivity, a case-insensitive file system is not specified by POSIX, therefore, a platform may do whatever it likes with rename(2), including change the case (rather than be a no-op). There _is_ no conformity issue, once you use rename(2) on a non-conformant file system; rather, it is just a consistency issue. My question, then, is whether it is likely that Linux will be changed to take this attitude. And now that we have proven that current Linux behaves differently than current cygwin, which behavior should mv(1) promote? I would argue that being able to change case is more useful, particularly based on the volume of complaints of people on case-insenstive systems who don't like the current solution of using an intermediate name. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Could we have a flag to tell us which directories were actually removed?
Reuben Thomas wrote:
I wanted this for keyboard use, for multiple directories:
rmdir [--magic-flag] *
Let me keep working the problem... How about this?
perl -le 'for my $i (@ARGV) { print $i if rmdir($i); };' *
That would be quite easy to turn into a script to reuse more often
such as on the command line.
#!/bin/sh
exec perl -le 'for my $i (@ARGV) { print $i if rmdir($i); };' $@
in fact. Maybe it's just not common enough a case?
It does seem pretty unusual to me to want to do something like that
and I have not wanted to do it before. In fact thinking about it a
little bit more and this seems to be actively bad to me. I think the
reverse information is really what I would want to see.
I am pretty pedantic about checking for errors. The reason I don't
like the above is that I can't tell the difference between a failure
to remove the directory and a failure to remove the directory. I mean
sure it is possible to print out which directories were removed and
that is fine for the directories that were actually removed. But what
if there is a problem? Already there is an expectation that some
directories won't get removed because of the error that they are not
empty. But what about other errors such as permissions and read-only
filesystems and I/O errors and other things? They are errors that I
would want to know about. I think it is better to perform actions
purposefully and to verify that the action did succeed.
But for some keyboard activities I am okay with being lazy. I have
often simply done 'rmdir *' and then looked to see what resulted. I
know that only empty directories will get removed and it will spew
errors for the others and I ignore that. But since I will look
immediately at the result and deal with the new state that seems
okay. If a directory that I think should have been removed was not I
can simply inspect it and 'rm -rf' it if needed.
So for me I would almost always want the reverse of this information.
I almost never want to know the names of the directories that I
removed. I would almost always want to know the names of the
directories that did *not* get removed. I assume that I am not alone
in this since this is also the behavior we currently have from the
commands for all of these years. The reverse information just does
not feel right to me.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'futimens' name conflict with glibc-2.6.1 header file sys/stat.h
On Wednesday 15 August 2007, Bob Proulx wrote: internal 'futimens' name has conflict with glibc-2.6.1 header file sys/stat.h a patch would be wonderful Can you post the error message that you are seeing back to the mailing list? That would help us know what is happening. this has been fixed in latest coreutils/gnulib cvs/git/whatever it's a gnulib problem ... the futimens() prototype changed during standardization which means the one in gnulib didnt match the one in glibc-2.6+ -mike signature.asc Description: This is a digitally signed message part. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
