bug#6500: rm 8.1

Brad wrote: > Hi Jim: > > After learning a little more about the debugger I was able to solve > the problem. Good. > It is clear that the option test is not failing. However only one of > three tests are being run because the code is linking to the new > glibc. Therefore the program is calling th

bug#6500: rm 8.1

Hi Jim: After learning a little more about the debugger I was able to solve the problem. It is clear that the option test is not failing. However only one of three tests are being run because the code is linking to the new glibc. Therefore the program is calling the fts_open function defined

bug#6500: rm 8.1

Hi Jim, my copy of fts.i looks the same as yours. Here is the additional gdb output: ### begin gdb ### Starting program: /home/brad/tools/core_debug/src/rm -rf a/b/c/d Breakpoint 1, fts_open (argv=0x7fffed08, options=536, compar=0) at fts.c:92 92 { (gdb) print options & ~0x07ff $1 =

bug#6500: rm 8.1

Brad wrote: ... > (gdb) run -rf a/b/c/d > Starting program: /home/brad/tools/core_debug/src/rm -rf a/b/c/d > > Breakpoint 1, fts_open (argv=0x7fffed08, options=536, compar=0) at > fts.c:92 > 92 { > (gdb) n > 100 if (options & ~FTS_OPTIONMASK) { > (gdb) n > 101

bug#6500: rm 8.1

Thanks Jim! I knew you would know what to do. Please tell me what this all means. Here is the output you need: GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free

bug#6500: rm 8.1

Brad wrote: > Thanks for your help Jim. I tried to debug the program by running > gdb. I'm not sure if the backtrace has the information you need. ... > Please let me know if you have any > suggestions to get more information. Thanks for the details. Here's how to get more: First, recompile at le

bug#6500: rm 8.1

Thanks for your help Jim. I tried to debug the program by running gdb. I'm not sure if the backtrace has the information you need. GNU gdb (GDB) 7.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free soft

bug#6500: rm 8.1

Brad wrote: > Hi Jim: Hi Brad, I've Cc'd the bug-reporting address. It's better to report problems to that address than to my personal one. > Are you sure this is fixed? How could I be sure it is fixed, considering that this is the first I've heard of this failure? > I get these errors: > rm:

Re: rm 8.1

Jim Meyering wrote: > Ladislav Hagara wrote: >> the behaviour of rm from last stable coreutils 8.1 is quite different >> from previous 7.6 one. > >> Is this a bug or a new feature of rm 8.1? > > Thank you very much for the report! > That is most definitely

Re: rm 8.1

Jim Meyering wrote: > Ladislav Hagara wrote: >> the behaviour of rm from last stable coreutils 8.1 is quite different >> from previous 7.6 one. > >> Is this a bug or a new feature of rm 8.1? > > Thank you very much for the report! > That is most definitely

Re: rm 8.1

Ladislav Hagara wrote: > the behaviour of rm from last stable coreutils 8.1 is quite different > from previous 7.6 one. > Is this a bug or a new feature of rm 8.1? Thank you very much for the report! That is most definitely a bug. The fix has two parts: in gnulib: The

Re: rm 8.1

Eric Blake writes: > It depends on how worried you are about the likelihood of distros > distributing unpatched coreutils 8.0 and 8.1 builds, and how worried you > are about encountering it in the wild. In general, passing an empty file > name to rm is never going to succeed, so there's already

Re: rm 8.1

b "" c; ls > rm: invalid argument: `' > a b c > Is this a bug or a new feature of rm 8.1? Thanks for the report. This is indeed a regression and a violation of POSIX, and was probably caused by our move from a hand-rolled recursion over to using an enhanced fts interface (he

rm 8.1

valid argument" and DOESN'T remove files: # rm --version | head -n 1 rm (GNU coreutils) 8.1 # touch a b c; rm a b "" c; ls rm: invalid argument: `' a b c # This problem arises when variable isn't defined, for example rm "$FILE". Is this a bug or a new f