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@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
>