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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9483 in the body.
You can then email your comments to 9483 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Anand Anand <anand.sinha85 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: issue with coreutils-6.9
Date: Mon, 12 Sep 2011 18:44:38 +0530

[Message part 1 (text/plain, inline)]

I need some help on coreutils-6.9 ??

I was running a testsuite on coreutils-6.9 wherein I have issues with yesno
API in the library.EVen if the stdin input is y in case of rm tests the
processed output is always taken as "n" and thus all the tests fail which
are interactive in nature.

Thanks and Regards,
Anand

[Message part 2 (text/html, inline)]

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

From: Bob Proulx <bob <at> proulx.com>
To: Anand Anand <anand.sinha85 <at> gmail.com>
Cc: 9483 <at> debbugs.gnu.org
Subject: Re: bug#9483: issue with coreutils-6.9
Date: Mon, 12 Sep 2011 17:33:26 -0600

tag 9483 + moreinfo
thanks

Anand Anand wrote:
> I was running a testsuite on coreutils-6.9 wherein I have issues with yesno
> API in the library.EVen if the stdin input is y in case of rm tests the
> processed output is always taken as "n" and thus all the tests fail which
> are interactive in nature.

Thank you for helping with GNU Coreutils.  However version 6.9 was
released 2007-03-22 over four years ago.  The current version of
coreutils is 8.13.  Since 6.9 there have been a lot of changes and
improvements.  Looking at the version control there are 2747 separate
changes committed between version 6.9 and the current version 8.13.
It is possible and dare I say likely that your the problem you are
reporting has already been fixed in the intervening years.

Could you try building the current version 8.13 and seeing if your
problem still exists?  Here is the latest release announcement with
information about obtaining the latest version.  Either way please
reply to this bug ticket so that we can track the progress.

  https://lists.gnu.org/archive/html/coreutils/2011-09/msg00130.html

Thanks!
Bob

Message #13 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: Tue, 13 Sep 2011 15:31:19 +0530

[Message part 1 (text/plain, inline)]

Hello Bob,

Thanks for the prompt reply.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.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

As for that matter any response value always came with 0 as return value
from rpmatch function.

I have to use "ENABLE_NLS" in this case.Let em know in case of any more
inputs required

Thanks and Regards,
Anand

On Tue, Sep 13, 2011 at 5:03 AM, Bob Proulx <bob <at> proulx.com> wrote:

> tag 9483 + moreinfo
> thanks
>
> Anand Anand wrote:
> > I was running a testsuite on coreutils-6.9 wherein I have issues with
> yesno
> > API in the library.EVen if the stdin input is y in case of rm tests the
> > processed output is always taken as "n" and thus all the tests fail which
> > are interactive in nature.
>
> Thank you for helping with GNU Coreutils.  However version 6.9 was
> released 2007-03-22 over four years ago.  The current version of
> coreutils is 8.13.  Since 6.9 there have been a lot of changes and
> improvements.  Looking at the version control there are 2747 separate
> changes committed between version 6.9 and the current version 8.13.
> It is possible and dare I say likely that your the problem you are
> reporting has already been fixed in the intervening years.
>
> Could you try building the current version 8.13 and seeing if your
> problem still exists?  Here is the latest release announcement with
> information about obtaining the latest version.  Either way please
> reply to this bug ticket so that we can track the progress.
>
>  https://lists.gnu.org/archive/html/coreutils/2011-09/msg00130.html
>
> Thanks!
> Bob
>

[Message part 2 (text/html, inline)]

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

From: Jim Meyering <jim <at> meyering.net>
To: Anand Anand <anand.sinha85 <at> gmail.com>
Cc: 9483-done <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#9483: issue with coreutils-6.9
Date: Tue, 13 Sep 2011 12:10:34 +0200

tags 9483 + notabug
thanks

Anand Anand wrote:
> Hello Bob,
>
> Thanks for the prompt reply.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.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
>
> As for that matter any response value always came with 0 as return value
> from rpmatch function.
>
> I have to use "ENABLE_NLS" in this case.Let em know in case of any more
> inputs required
>
> Thanks and Regards,
> Anand

You're welcome to continue discussing this here, but since this is
not a bug in any recent version, I'm marking the issue as closed.

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

From: Bob Proulx <bob <at> proulx.com>
To: Anand Anand <anand.sinha85 <at> gmail.com>
Cc: 9483 <at> debbugs.gnu.org
Subject: Re: bug#9483: issue with coreutils-6.9
Date: Tue, 13 Sep 2011 11:09:05 -0600

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 #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)]

Message #27 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: Thu, 15 Sep 2011 17:14:56 +0530

[Message part 1 (text/plain, inline)]

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 <anand.sinha85 <at> gmail.com>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 <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)]

Previous Next

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