[bug] coreutils 5.2.1 - incorrect behaviour for mv --reply=no
When using the option --reply=no for mv, it still overwrites the file when it is not supposed to. Here is a quick demo: [EMAIL PROTECTED] ~]# mkdir mvtest [EMAIL PROTECTED] ~]# cd mvtest/ [EMAIL PROTECTED] mvtest]# mkdir moveto [EMAIL PROTECTED] mvtest]# echo test file.ext [EMAIL PROTECTED] mvtest]# touch moveto/file.ext [EMAIL PROTECTED] mvtest]# ls file.ext moveto [EMAIL PROTECTED] mvtest]# mv --reply=no -v file.ext moveto/ `file.ext' - `moveto/file.ext' [EMAIL PROTECTED] mvtest]# ls moveto [EMAIL PROTECTED] mvtest]# This is wrong as the destination file should not be overwritten when using --reply=no Oher relevant information: [EMAIL PROTECTED] ~]# mv --version mv (coreutils) 5.2.1 Written by Mike Parker, David MacKenzie, and Jim Meyering. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] ~]# rpm --query coreutils coreutils-5.2.1-31.7 [EMAIL PROTECTED] ~]# rpm --query glibc glibc-2.3.4-2.39 [EMAIL PROTECTED] ~]# uname -a Linux wilber.pointclark.net 2.6.18-8.1.14.3.cccustom #1 PREEMPT Sun Nov 4 22:53:10 EST 2007 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] ~]# ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[coreutils-6.9] ls bug: ls failing to sort alphabetically with and without options
My distro is ClarkConnect Community Edition release 4.0 (kernel 2.6.9-42.cc). I noticed that ls was failing to sort alphabetically so I grabbed the latest version of coretuils and compiled it: ]# wget http://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.gz ]# tar xvfz coreutils-6.9.tar.gz ]# cd coreutils-6.9 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[coreutils-6.9] ls and sort bug: ls and sort fails to sort alphabetically with and without options
My distro is ClarkConnect Community Edition release 4.0 (kernel 2.6.9-42.cc). I noticed that ls was failing to sort alphabetically so I grabbed the latest version of coreutils and compiled it to test it, which failed as well: ~]# wget http://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.gz ~]# tar xvfz coreutils-6.9.tar.gz ~]# cd coreutils-6.9 coreutils-6.9]# ./configure coreutils-6.9]# make coreutils-6.9]# ldd src/ls librt.so.1 = /lib/tls/librt.so.1 (0x00111000) libc.so.6 = /lib/tls/libc.so.6 (0x00428000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x00bda000) /lib/ld-linux.so.2 (0x00bf2000) coreutils-6.9]# src/ls -1 /var/arpwatch/ arp2ethers arp.dat arp-eth1.dat arpfetch arp-wlan0.dat d.awk duplicates.awk e.awk ethercodes.dat euppertolower.awk massagevendor massagevendor-old missingcodes.txt p.awk The same order in the output is produced by -alh(I'd imagine other options as well) as well as no options. -r produces the same order except reversed. The unsorted section is the arp* block: arp2ethers arp.dat arp-eth1.dat arpfetch arp-wlan0.dat Next I tried to pipe that through sort to see if it would come out sorted: coreutils-6.9]# src/ls -1 /var/arpwatch/ | grep arp | src/sort arp2ethers arp.dat arp-eth1.dat arpfetch arp-wlan0.dat I also tried passing various values to sort like -dfgin(not at the same time) and this had no effect on the sort order, each option looked like the output above. I would have expected the output to look like this: arp-eth1.dat arp-wlan0.dat arp.dat arp2ethers arpfetch or something similar, not the output I am currently getting. Hooroo, Wilber ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[coreutils-6.9] multiple utilities not handling escape char(\) properly when used with -, instead interpreting as option(could be a bash bug?)
ClarkConnect Community Edition release 4.0 (kernel 2.6.9-42.cc) I compiled the latest coreutils from source. Then I ran these series of commands: coreutils-6.9]# mkdir testdir coreutils-6.9]# cd testdir/ testdir]# ../src/touch +foo0 testdir]# ../src/touch \+foo1 testdir]# ../src/touch -bar0 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ That error is correct as the - char is used for options. testdir]# ../src/touch \-bar1 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ This is wrong, this should work!! testdir]# ../src/touch \\-bar2 ^^ Trying a double backslash to see what happens testdir]# ls +foo0 +foo1 \-bar2 ^^ It is what is expected. testdir]# ../src/touch '-bar3' ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ Trying single quotes testdir]# ../src/touch -bar4 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ Trying double quotes testdir]# ../src/mv +foo0 -bar5 ../src/mv: invalid option -- e Try `../src/mv --help' for more information. ^^ That error is correct as the - char is used for options. testdir]# ../src/mv +foo0 \-bar6 ../src/mv: invalid option -- e Try `../src/mv --help' for more information. ^^ This is wrong, this should work!! testdir]# ../src/touch ./-bar7 testdir]# ../src/touch ./\-bar8 testdir]# ls +foo0 +foo1 \-bar2 -bar7 -bar8 testdir]# As you can see from the above commands, \-barX is being interpreted as an option to touch/mv/etc instead of being part of the filename. Hooroo, Wilber ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
