GNU bug report logs - #9483
issue with coreutils-6.9

Previous Next

Package: coreutils;

Reported by: Anand Anand <anand.sinha85 <at> gmail.com>

Date: Mon, 12 Sep 2011 16:10:02 UTC

Severity: normal

Tags: moreinfo

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


Message #24 received at 9483 <at> debbugs.gnu.org (full text, mbox):

From: Anand Anand <anand.sinha85 <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 9483 <at> debbugs.gnu.org
Subject: Re: bug#9483: issue with coreutils-6.9
Date: Wed, 14 Sep 2011 00:31:37 +0530
[Message part 1 (text/plain, inline)]
Hey Bob,

Thanks for the update....Yeah I understand about it..I have already started
diggin deep into the code.(good that there is a fix somewhere).

As for your question ..yes this command "rm -ir z" is being run as part of a
testscript .The testscript is rm3 and it can be found in coreutils/tests/rm
folder.

Just giving a brief snippet here

cat <<EOF > in
y
y
y
y
y
y
y
y
y
EOF

# Both of these should fail.
rm -ir z < in > out 2>&1 || fail=1

....Now I started checking the rm code in rm.c and there i could find that
the userinput was processed as false here instead of true...

Digging into code i could see that the ultimate culprit was rpmatch API call
in yesno.c

if (response_len <= 0)
    yes = false;
  else
    {
      response[response_len - 1] = '\0';
      yes = (0 < rpmatch (response));
    }

I tried printing the value of response here and it always came out as "y"
still variable "yes" would always come out as false instead of true.I
removed the "ENABLE_NLS" check her and used the code originally meant for
"disable_NLS" then everything worked fine but that was not the solution to
the problem..

I also have a mightbe very starnge doubt which might be due to something i
overlooked..I tried putting in logs in rpmatch but it didnt print anything.I
also tried redirecting logs to stderr still there wud be no
printouts.Ultimately I also tried creating a file in the entrance of the
file but still nothing would work..It seems rpmatch is being called form
yesno.c but the function never gets invoked.Is that possible ?

Lastly i might be wrong in any of my protocols of communication.So please
forgive me..I will improve as I am new to opensource way of life :)

Thanks and Regards,
Anand
On Tue, Sep 13, 2011 at 10:39 PM, Bob Proulx <bob <at> proulx.com> wrote:

> Anand,
>
> Anand Anand wrote:
> > Due to certain constraints I am to fix this bug within this version
> > itself.  I know thats kind of lame but thats the way its reqd to be.
>
> If you are needing to fix this in such an old version then you will
> probably need to be the one to do most of the debugging work.  This
> problem only affects you and no one else.  But that is the good thing
> about free software.  You have all of the source code available to you
> and so you are empowered and enabled to do what you need to do.  Life
> is good! :-)
>
> > I can give you more inputs on the bug right now.  While running rm
> > tests as part of testsuites we have tgo run the command "rm -ir z"
> > wherein user input is expected.The userinput irrespective of what is
> > fed is always taken negative and always returned as
> > "user_permission_denied".I triede putting in more logs and I could
> > see in the function "yesno" in file yesno.c even though response
> > pointed to "y" the rpmatch function was exiting with 0 return value
>
> You did not supply very much information.  Why do you need to run the
> "rm -ir z" command?  If you want to remove the directory then you
> should run the rm -rf command.
>
> Or is this in a coreutils test file?  You did not say.  If so then
> what test file?  If so then what was the output of the test file?  You
> did not say.
>
> "Permission denied" is a completely different problem from 'rm -i' not
> taking 'y' or 'n'.  It is unrelated.  Do not confuse the two problems.
>
> Perhaps you have created a directory hierarchy with directories that
> are not writable.  If so then this is not a bug in rm.  If so then you
> will first need to make the directories writable.
>
> Command to make all directories below the '.' directory writable by
> the user owning the directory.  This might be useful to you.
>
>  find . -type d -exec chmod u+rwx {} +
>
> Bob
>
[Message part 2 (text/html, inline)]

This bug report was last modified 13 years and 250 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.