Re: ar(1) issue building coreutils on 64-bit AIX
Daniel Richard G. [EMAIL PROTECTED] wrote: I am building coreutils-6.9 on a 64-bit AIX 5.3 system. The system ar(1) command, in its default behavior, only accepts 32-bit objects. In order to accept 64-bit objects, a switch has to be given. So in my standard build environment, I set AR_FLAGS=-X64 cru This takes care of the bulk of Libtool-based packages out there. However, in building coreutils, I encountered this: coreutils doesn't use libtool, but it does use automake. And automake uses the ARFLAGS spelling. ... I noticed that lib/Makefile uses ARFLAGS instead of AR_FLAGS. I set this in the environment, reconfigured, and built again. Same error. Edited the variable manually in the makefile. The build succeeds. I think that the variable in question should be picked up from the environment, for cases like this one (editing makefiles is cumbersome, especially in a semi-automated build system as I have here). I would also suggest renaming it to AR_FLAGS, for consistency with Libtool convention. No need to edit Makefiles. Just invoke make with your ARFLAGS setting on the command line: make ARFLAGS=-X64 cru ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in od with -j option?
Paul GHALEB [EMAIL PROTECTED] wrote:
IOW, when one tries to skip exactly the size of the file, od acts as
if it ignored the -j size option.
I looked at the source code and found that the problem is most likely
in src/od.c:skip() at line 1043:
if ((uintmax_t) file_stats.st_size = n_skip)
which should be:
if ((uintmax_t) file_stats.st_size n_skip)
Thank you for the report and patch.
That bug was present even on the trunk.
I've just applied your patch, adjusted the comment,
added tests and NEWS, and pushed the result:
http://git.sv.gnu.org/gitweb/?p=coreutils.git
diff --git a/ChangeLog b/ChangeLog
index 1cd7390..df1718e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2007-08-14 Jim Meyering [EMAIL PROTECTED]
+
+ od: fix a bug that arises when skipping exact length of file
+ * NEWS: Document the bug fix.
+ * src/od.c (skip): Call fseek even when n_skip is exactly the
+ same as the length of the current file. Otherwise, the next
+ iteration would use unadjusted input stream pointer, thus ignoring
+ the desired skip. Report and patch by Paul GHALEB.
+
2007-08-10 Paul Eggert [EMAIL PROTECTED]
Accommodate more xstrtol changes.
diff --git a/NEWS b/NEWS
index 83d06b7..13d3402 100644
--- a/NEWS
+++ b/NEWS
@@ -98,6 +98,11 @@ GNU coreutils NEWS-*-
outline -*-
ln=target attribute) would mistakenly output the string target
before the name of each symlink. [introduced in coreutils-6.0]
+ od -j L FILE had a bug: when the number of bytes to skip, L, is exactly
+ the same as the length of FILE, od would skip *no* bytes. When the number
+ of bytes to skip is exactly the sum of the lengths of the first N files,
+ od would skip only the first N-1 files. [introduced in textutils-2.0.9]
+
seq no longer mishandles obvious cases like seq 0 0.01 0.03,
so workarounds like seq 0 0.01 0.031 are no longer needed.
diff --git a/THANKS b/THANKS
index ae5269f..cdddec4 100644
--- a/THANKS
+++ b/THANKS
@@ -397,6 +397,7 @@ Oskar Liljeblad [EMAIL PROTECTED]
Pádraig Brady [EMAIL PROTECTED]
Patrick Mauritz [EMAIL PROTECTED]
Paul Eggert [EMAIL PROTECTED]
+Paul Ghaleb [EMAIL PROTECTED]
Paul Jarc [EMAIL PROTECTED]
Paul Nevai [EMAIL PROTECTED]
Paul Sauer [EMAIL PROTECTED]
diff --git a/src/od.c b/src/od.c
index 1e77f92..0abce59 100644
--- a/src/od.c
+++ b/src/od.c
@@ -1034,13 +1034,12 @@ skip (uintmax_t n_skip)
{
/* The st_size field is valid only for regular files
(and for symbolic links, which cannot occur here).
-If the number of bytes left to skip is at least
-as large as the size of the current file, we can
-decrement n_skip and go on to the next file. */
-
+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)
{
- if ((uintmax_t) file_stats.st_size = n_skip)
+ if ((uintmax_t) file_stats.st_size n_skip)
n_skip -= file_stats.st_size;
else
{
--
1.5.3.rc4.67.gf9286
From 459afe0f9859fdf0e9c1a3505425c8bd345b72e3 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Tue, 14 Aug 2007 10:17:52 +0200
Subject: [PATCH] Add tests for the just-fixed od -j N FILE bug.
* tests/misc/od: New file, test for the above.
* tests/misc/Makefile.am (TESTS): Add od.
Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
ChangeLog |3 ++
tests/misc/Makefile.am |1 +
tests/misc/od | 74
3 files changed, 78 insertions(+), 0 deletions(-)
create mode 100755 tests/misc/od
diff --git a/ChangeLog b/ChangeLog
index df1718e..aa81a6c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -7,6 +7,9 @@
iteration would use unadjusted input stream pointer, thus ignoring
the desired skip. Report and patch by Paul GHALEB.
+ * tests/misc/od: New file, test for the above.
+ * tests/misc/Makefile.am (TESTS): Add od.
+
2007-08-10 Paul Eggert [EMAIL PROTECTED]
Accommodate more xstrtol changes.
diff --git a/tests/misc/Makefile.am b/tests/misc/Makefile.am
index 8cf03f2..7206b39 100644
--- a/tests/misc/Makefile.am
+++ b/tests/misc/Makefile.am
@@ -42,6 +42,7 @@ TESTS_ENVIRONMENT = \
# will execute the test script rather than the standard utility.
TESTS = \
+ od \
xstrtol \
arch \
pr \
diff --git a/tests/misc/od b/tests/misc/od
new file mode 100755
index 000..1cbbcdb
--- /dev/null
+++ b/tests/misc/od
@@ -0,0 +1,74 @@
+#!/bin/sh
+# -*- perl -*-
+# Exercise od
+
+#
Segmentation fault copying a file
Hello, I get a segmentation fault when I try to copy a file in particular: $ cp a b Fallo de segmentación Note: Fallo de segmentación means segmentation fault. $ ls -l -rwx-- 1 eneko eneko 16875520 2007-08-14 12:55 b -rwx-- 1 eneko eneko 102049992 2006-05-05 11:23 a These messages appear in /var/log/messages: Aug 14 12:55:35 eneko kernel: [101755.918638] 1BUG: unable to handle kernel paging request at virtual address 0001 Aug 14 12:55:35 eneko kernel: [101801.885715] c0157076 Aug 14 12:55:35 eneko kernel: [101801.885724] Modules linked in: radeon drm binfmt_misc rfcomm l2cap vmnet(P) vmmon(P) ppdev cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_stats freq_table sony_acpi tc1100_wmi pcc_acpi dev_acpi video ac sbs i2c_ec button asus_acpi backlight container dock battery af_packet nls_iso8859_1 nls_cp437 vfat fat sbp2 parport_pc lp parport fuse snd_via82xx_modem snd_seq_dummy snd_seq_oss snd_seq_midi hci_usb snd_emu10k1_synth snd_emux_synth ipv6 bluetooth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_via82xx snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_ac97_codec ac97_bus nfs lockd sunrpc serio_raw pcspkr snd_util_mem snd_pcm snd_mpu401_uart psmouse snd_seq snd_timer snd_hwdep snd_rawmidi snd_seq_device i2c_viapro k8temp snd snd_page_alloc soundcore i2c_core emu10k1_gp amd64_agp agpgart sk98lin shpchp pci_hotplug gameport tsdev evdev ext3 jbd mbcache ide_cd cdrom ide_disk ata_generic generic floppy ehci_hcd uhci_hcd usbcore via82cxxx sata_via Aug 14 12:55:35 eneko kernel: libata scsi_mod ohci1394 ieee1394 skge thermal processor fan fbcon tileblit font bitblit softcursor vesafb capability commoncap $ uname -a Linux eneko 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux $ cp --version cp (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. Este programa es software libre Puede ser redistribuido bajo los términos de la Licencia Pública General de GNU http://www.gnu.org/licenses/gpl.html. No se proporciona NINGUNA GARANTÍA, hasta al grado permitido por la ley. Escrito por Torbjorn Granlund, David MacKenzie, y Jim Meyering. I am using Kubuntu Feisty 7.04. Do you need more info? Perhaps a kernel bug? Thank you very much and nice job!! Eneko ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Segmentation fault copying a file
Eneko Nieto [EMAIL PROTECTED] wrote: I get a segmentation fault when I try to copy a file in particular: $ cp a b Fallo de segmentación Note: Fallo de segmentación means segmentation fault. $ ls -l -rwx-- 1 eneko eneko 16875520 2007-08-14 12:55 b -rwx-- 1 eneko eneko 102049992 2006-05-05 11:23 a These messages appear in /var/log/messages: Aug 14 12:55:35 eneko kernel: [101755.918638] 1BUG: unable to handle kernel paging request at virtual address 0001 Aug 14 12:55:35 eneko kernel: [101801.885715] c0157076 Aug 14 12:55:35 eneko kernel: [101801.885724] Modules linked in:... $ uname -a Linux eneko 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux $ cp --version cp (GNU coreutils) 5.97 ... I am using Kubuntu Feisty 7.04. Do you need more info? Perhaps a kernel bug? Thanks for the report. Like you, I suspect a kernel problem, but you can narrow it down by providing more info: - Tell us your file system type: df -T . - See if your file a is sparse: Run both of these: du --apparent a du a - Rerun your command under strace: strace -o log cp a b then, look at (and send here) the file log. It tells a lot about the syscalls cp uses. - maybe useful: try to provoke the failure using a smaller file. If you can, how small can you go? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Segmentation fault copying a file
[cc'ing the list, so others know, too] Eneko Nieto [EMAIL PROTECTED] wrote: On Tuesday 14 August 2007 14:32:29 you wrote: ... Oops, the system blocked and after rebooting it I can't reproduce the error, sorry :( Anyway, take the info: $ df -T . S.ficherosTipo Bloques de 1K UsadoDispon Uso% Montado en /dev/hdb2 ext317860612 10687712 6265632 64% /home $ du --apparent a 99659 a $ du a 99764 a Thank you!! Eneko Ok. We'll write if off to a corrupted kernel. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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. - Why shouldn't coreutils accept native win32 ports? GNU make does. I think native win32 support should be an objective of the project; if not, the situation I described before won't be solved: win32 users will have endless choices of non-standard, not-entirely-working ports. --Aviad -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 05:05 To: Aviad Lahav Cc: bug-coreutils@gnu.org Subject: Re: coreutils rm - win32 native port -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Aviad Lahav on 8/13/2007 7:29 AM: I needed to use rm.exe on my project but found no decent pre-built binaries: - Cygwin binary was bad for me because the dependency on the DLL and the mess it does with paths The cygwin community is aware of this - it is the price they are willing to pay for the most complete POSIX emulation among the various Windows ports. - GnuWin32 had some bugs with \ GnuWin32 has earned somewhat of a reputation on this list of being woefully out of date. - UnxUtils had problems with read-only files (rm -f doesn't work) I'm not that familiar with UnxUtils. Have you tried mingw? It is probably the best-maintained port that does not also require a separate dll. So I built my own version of rm, modified coreutils 6.9; tried to minimize changes; remove.c was almost completely re-written using the native WIN32 API. It now compiles with MSVC 2005 and works well. Sorry, but this list probably will not accept patches to convert to the Windows API. The gnulib list might take patches for ports of common POSIX functions, when a more efficient implementation that uses Windows API under the hood is provided, and where the patch is easy enough to maintain. But it is much easier to write portable code that uses a portable, publicly maintained API (anyone can join the Austin Group and contribute to POSIX free of charge, whereas the Windows API is proprietary and not portable). This is not meant to discourage you from submitting your patches to UnxUtils or GnuWin32, but I can also guarantee that your patches won't be accepted into the cygwin port of coreutils. Bottom line: I'd like this to be committed to main CVS - how and who? Does this need code review? This is the right list for posting proposed patches; and even if we have reasons for not incorporating them, someone else can read the archives and use the patch if they like it. The other thing you have to have to get non-trivial patches incorporated upstream is copyright disclaimer to the FSF. - -- 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 iD8DBQFGwQ3A84KuGfSFAYARAsgTAJ94Pf6z6MbJB/FrovhgGBTVB6hQ9ACeK6nP Fa8zLBmAeIV4LBZD+Yi9Hmk= =bmuV -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #20784] mv should be able to change filename case on case-insensitive file systems
URL: http://savannah.gnu.org/bugs/?20784 Summary: mv should be able to change filename case on case-insensitive file systems Project: GNU Core Utilities Submitted by: None Submitted on: Tuesday 08/14/2007 at 16:29 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: On Cygwin using non-managed mounts (and presumably other operating systems when using a case-insensitive file system), it's not possible to use Coreutils mv to change the case of a filename; mv reports that they are the same file. The underlying Cygwin rename() function does support this functionality. Also see the thread on the Cygwin mailing list starting at http://cygwin.com/ml/cygwin/2007-08/msg00335.html. Example: $ touch foo $ mv foo Foo mv: `foo' and `Foo' are the same file $ mv --version mv (GNU coreutils) 6.9 Copyright (C) 2007 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License http://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law. Written by Mike Parker, David MacKenzie, and Jim Meyering. $ uname -a CYGWIN_NT-5.1 jonathan-lmi 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin $ perl -e 'rename foo, Foo or die($!)' $ ls [Ff]oo Foo ___ Reply to this item at: http://savannah.gnu.org/bugs/?20784 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug #20784] mv should be able to change filename case on case-insensitive file systems
anonymous scripsit: On Cygwin using non-managed mounts (and presumably other operating systems when using a case-insensitive file system), it's not possible to use Coreutils mv to change the case of a filename; mv reports that they are the same file. This is a nasty bug, and definitely should be fixed. Note that it has to do with the behavior of the file system, not the OS as such, and any file system might be mounted in any OS these days. (The workaround is mv Foo gibblebobble; mv gibblebobble foo.) -- I am expressing my opinion. When myJohn Cowan honorable and gallant friend is called, [EMAIL PROTECTED] he will express his opinion. This is http://www.ccil.org/~cowan the process which we call Debate. --Winston Churchill ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv: cannot move `dir' to a subdirectory of itself, `../dir'
mv seems to think that ../dir is a subdirectory of dir, not realising that .. has a special meaning. Here's a shell transcript that produces the incorrect error message in coreutils 5.97-5.2ubuntu3 (ubuntu 7.04): $ cd $ mkdir test $ cd test $ mkdir ../dir $ mkdir dir $ touch ../dir/x dir/y $ ls -al ../dir dir dir: total 20 drwxr-xr-x 2 chris chris 4096 2007-08-14 18:37 . drwxr-xr-x 3 chris chris 4096 2007-08-14 18:36 .. -rw-r--r-- 1 chris chris0 2007-08-14 18:37 y ../dir: total 28 drwxr-xr-x 2 chris chris 4096 2007-08-14 18:37 . drwx-- 104 chris chris 12288 2007-08-14 18:36 .. -rw-r--r-- 1 chris chris 0 2007-08-14 18:37 x $ mv dir .. mv: cannot move `dir' to a subdirectory of itself, `../dir' $ rm ../dir/x $ ls -al ../dir dir dir: total 20 drwxr-xr-x 2 chris chris 4096 2007-08-14 18:37 . drwxr-xr-x 3 chris chris 4096 2007-08-14 18:36 .. -rw-r--r-- 1 chris chris0 2007-08-14 18:37 y ../dir: total 24 drwxr-xr-x 2 chris chris 4096 2007-08-14 18:38 . drwx-- 104 chris chris 12288 2007-08-14 18:36 .. $ mv dir .. $ ls -al ../dir dir ls: dir: No such file or directory ../dir: total 28 drwxr-xr-x 2 chris chris 4096 2007-08-14 18:37 . drwx-- 104 chris chris 12288 2007-08-14 18:36 .. -rw-r--r-- 1 chris chris 0 2007-08-14 18:37 y $ Perhaps it's correct behaviour not to allow me to move ./dir into the parent directory when the parent directory contains a non-empty directory with the same name, but the error message that is shown is misleading - ../dir isn't a subdirectory of ./dir ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
basename whitespace bug
Hi when executed with file name containing spaces, basename returns only first part of file name (until space). Rihards ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv can't change filename case on case-insensitive file systems
(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.) On Cygwin using non-managed mounts (and presumably other operating systems when using a case-insensitive file system), it's not possible to use Coreutils mv to change the case of a filename; mv reports that they are the same file. The underlying Cygwin rename() function does support this functionality. Also see the thread on the Cygwin mailing list starting at http://cygwin.com/ml/cygwin/2007-08/msg00335.html. Example: $ touch foo $ mv foo Foo mv: `foo' and `Foo' are the same file $ mv --version mv (GNU coreutils) 6.9 Copyright (C) 2007 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License http://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law. Written by Mike Parker, David MacKenzie, and Jim Meyering. $ uname -a CYGWIN_NT-5.1 jonathan-lmi 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin $ perl -e 'rename foo, Foo or die($!)' $ ls [Ff]oo Foo -- Jonathan Lennox [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in od with -j option?
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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: basename whitespace bug
On Tue, 14 Aug 2007, Rihards Kazainis wrote: when executed with file name containing spaces, basename returns only first part of file name (until space). I can't reproduce this: $ basename --version basename (GNU coreutils) 5.93 $ basename '/tmp/filename with spaces' filename with spaces Could you give an example transcript of the problem you're seeing. It's possible there's a misunderstanding about how the shell passes arguments to basename; be sure to quote the filename properly. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: basename whitespace bug
when executed with file name containing spaces, basename returns only first part of file name (until space). Try quoting the string. [EMAIL PROTECTED]:~$ basename /home/ams/frob ni.cate frob ni.cate Space is treated as a seperator of arguments on GNU and Unixoid systems. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: cannot move `dir' to a subdirectory of itself, `../dir'
Chris Moore [EMAIL PROTECTED] writes: $ mv dir .. mv: cannot move `dir' to a subdirectory of itself, `../dir' With coreutils 6.9 you'll get Directory not empty. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
printf --help
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: Right now, there's nothing explicitly saying that --help and --version are the options. I admit it's unlikely to be a point of confusion (especially for anyone who can figure out how to invoke coreutils printf in the first place :), but is there any harm in saying it explicitly? Thanks for coreutils :). karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: cannot move `dir' to a subdirectory of itself, `../dir'
Andreas Schwab wrote: Chris Moore [EMAIL PROTECTED] writes: $ mv dir .. mv: cannot move `dir' to a subdirectory of itself, `../dir' With coreutils 6.9 you'll get Directory not empty. That also seems incorrect. Shouldn't the error be A file ( directory ) with that name already exists? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: cannot move `dir' to a subdirectory of itself, `../dir'
Phillip Susi [EMAIL PROTECTED] writes: Andreas Schwab wrote: Chris Moore [EMAIL PROTECTED] writes: $ mv dir .. mv: cannot move `dir' to a subdirectory of itself, `../dir' With coreutils 6.9 you'll get Directory not empty. That also seems incorrect. Shouldn't the error be A file ( directory ) with that name already exists? No. If the directory was empty it would just be overwritten, so the non-emptyness is the key for the error (and it's directly the error the kernel returns). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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#Compatibility http://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration GNU make does. Only because someone volunteers to maintain it. 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. 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). -- Eric Blake ___ 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
(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. On Cygwin using non-managed mounts (and presumably other operating systems when using a case-insensitive file system), it's not possible to use Coreutils mv to change the case of a filename; mv reports that they are the same file. The underlying Cygwin rename() function does support this functionality. Although it is an unstandardized behavior. Consider - should rename(Foo, foo) be a no-op when stat(Foo) and stat(foo) resolve to the same file? Reading just the POSIX rename(2) requirements seems to say yes (it requires rename to be a no-op when both names resolve to the same inode, ie. no case change allowed); but reading the stat(2) requirements says it is undefined, since a case-insensitive filesystem violates POSIX in the first place. 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? Also, what about FAT filesystem access under Linux? I'd like to know whether platforms agree on semantics, before deciding whether a patch is even possible. One of the more interesting manifestations of the problems with case-insensitive systems was this example culled from the mentioned thread on cygwin: $ mkdir foo $ mv -T foo Foo Rather than being a no-op (because it is two spellings of the same file) or changing the case (as was argued above might be reasonable behavior for case-insensitive systems), it triggers the coreutils shortcut that since foo and Foo give the same stat results, they must be hard-linked, so it attempts unlink(foo), which is invalid on a directory. Another example: $ touch foo $ ln foo fool $ mv foo Foo $ echo ?oo* fool Oops - because foo has a link count 1, and because stat returned the same results, unlink(foo) was called, getting rid of foo in all forms rather than just renaming foo. Yes, the data is preserved in fool, but it seems odd to have all references to foo disappear merely because of the hard link. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils rm - win32 native port
Eric Blake wrote: Aviad Lahav wrote: - 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#Compatibility http://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration The GNU project exists to create a completely free operating system. There are many non-free operating systems. Most are quite incompatible with standard free systems. It just does not make sense to put a lot of effort supporting the closed source proprietary systems when the goal is to create a completely free system. This has even been written down as a rule for GNU maintainers. Here is what the GNU standards say on this topic: http://www.gnu.org/prep/standards/html_node/System-Portability.html#System-Portability The primary purpose of GNU software is to run on top of the GNU kernel, compiled with the GNU C compiler, on various types of cpu. So the kinds of portability that are absolutely necessary are quite limited. But it is important to support Linux-based GNU systems, since they are the form of GNU that is popular. ... As for systems that are not like Unix, such as MSDOS, Windows, VMS, MVS, and older Macintosh systems, supporting them is often a lot of work. When that is the case, it is better to spend your time adding features that will be useful on GNU and GNU/Linux, rather than on supporting other incompatible systems. I think native win32 support should be an objective of the project; The scary part that I heard in the original message was: remove.c was almost completely re-written using the native WIN32 API. It now compiles with MSVC 2005 and works well. That almost certainly sounds bad for the code for use on GNU and Unix-like systems. Don't you agree? Since the primary purpose of GNU software is to run on the GNU operating system this is taking the code in the wrong direction. It does not improve the maintainability and (by the probable use of #ifdefs) would decrease it. The amount and how much is all part of the judgement call as to whether it is acceptable or not to put in and support or not. Small amounts of diversion are often acceptable but huge differences would tend to be too much difference. When I hear almost completely re-written using the native WIN32 API that sounds like too much difference and sounds detrimental to use of the code on GNU systems. If that is not correct then please follow up with additional information. if not, the situation I described before won't be solved: win32 users will have endless choices of non-standard, not-entirely-working ports. Please put yourself in our position. How should an advocate of free software developing projects for the GNU operating system be expected to respond to a request to tie software to a non-free, non-standard, system when doing so is disadvantageous to the native free GNU system? This definitely puts us in an uncomfortable situation. We would like to please everybody but obviously that is not possible. In the end we just have to say we are very sorry but priority must be given to the native goals of the project. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
