bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9483: issue with coreutils-6.9


From: Anand Anand
Subject: bug#9483: issue with coreutils-6.9
Date: Thu, 15 Sep 2011 17:14:56 +0530

Hello All,

Need some help.WHenever I amke changes in rpmatch.c the changes are not
reflecting int the execution.I think I have not understood how rpmatch
compilation works.Can anyone please help me with some pointers as to how to
make changes reflect ?

Thanks and Regards,
Anand

On Wed, Sep 14, 2011 at 12:31 AM, Anand Anand <address@hidden>wrote:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]