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