Re: should GNU install call matchpathcon by default?

2008-05-21 Thread Ondrej Vasik
Jim Meyering  meyering.net> writes:
> In the multi-file case, the pre-patch performance penalty for enabling
> the ifdef'd-out code would range from probably-immeasurable (for just
> 2 or 3 files) to infinite, with enough files to make install exhaust
> virtual memory.

Actually even for 2-3 files (copied to /usr/temp dir) it was measurable. 
On my machine the performance impact is following:
Setdefaultcontext code if0'd:  0.0148 s.
Current patch(matchpathcon_init_prefix just once): 0.0666 s.
Old setdefaultcontext code:0.1702 s.

For 100 files(copied to /usr/temp) it took 4.0342 s. - that's about 35,5 times
more than with current patch from Jim and 128 times more than with if0'd
setdefaultcontext code. And of course for more files it goes to infinity.

Problem is that disabled code is causing bugzilla tickets like
https://bugzilla.redhat.com/show_bug.cgi?id=319231 , so maybe the best solution
to reduce performance impact would be to patch automake to install multiple
files in one directory at once or something like that - to reduce performance
impact of the ifdefed code on installation of big portions of files.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: bug report : about rm command

2008-05-21 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[re-adding the list]

According to [EMAIL PROTECTED] on 5/20/2008 10:18 PM:
| U:\>rm --version
| rm (coreutils) 5.2.1

Thanks.  This version is several years old, and typically means you
downloaded rm as part of a poorly-maintained port.  I would suggest that
if you want to use GNU tools on Windows, that you use a different port;
I'm particularly fond of cygwin (see cygwin.com).

| I have resove my question by copy command instead of rm command.
| If not exist z:\_%1.dll copy z:\%1 z:\_%1.dll
| Instead of :
| If exist z:\%1.dll rm z:\%1.dll z:\_%1.dll

copy is a windows cmd builtin, which is why it has no problem
understanding the \ syntax.  It may also be that you merely wanted to use
rm -f instead of plain rm, to ignore warnings about attempts to delete
files that are not present.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg0DoEACgkQ84KuGfSFAYB2JACfepBATORgbyExIJOkhr3EXY86
CG4An2Ec9ovG9KOQLNAlOL7fVhSYHJcS
=xfc0
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: bug report : about rm command

2008-05-21 Thread Etienne Buira
On Wed, May 21, 2008 at 11:14:55AM +0800, [EMAIL PROTECTED] wrote:
> Thanks for you rapid response.
> 
> My rm command use background:
> I use it in a cpy.bat file , which is invoked by VC++ 6.0 post build 
> command.(per build , dll and pde file will be copy to a special directory, 
> but the original file should be backup for possible restore reason)
> 
> ENV : XP sp2 professional . window english version.
> 
> Z: is a network driver , I have full access privilege.
> The cpy.bat script content::
> if exist z:\%1.dll rm z:\%1.dll z:\_%1.dll
> copy /y %1.dll z:\
> copy /y %1.pdb z:\
> copy /y %1.sbr z:\
> 
> 
> the line "if exist z:\%1.dll rm z:\%1.dll z:\_%1.dll " always fails, even I 
> test it in CMD method. Example : 
> Start -> run -> cmd
> D:
> rm c:\aa.dll c:\_aa.dll

Why not being consistant and use the DOSish "del" command instead?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: bug report : about rm command

2008-05-21 Thread Etienne Buira
On Wed, May 21, 2008 at 11:14:55AM +0800, [EMAIL PROTECTED] wrote:
> Thanks for you rapid response.
> 
> My rm command use background:
> I use it in a cpy.bat file , which is invoked by VC++ 6.0 post build 
> command.(per build , dll and pde file will be copy to a special directory, 
> but the original file should be backup for possible restore reason)
> 
> ENV : XP sp2 professional . window english version.
> 
> Z: is a network driver , I have full access privilege.
> The cpy.bat script content::
> if exist z:\%1.dll rm z:\%1.dll z:\_%1.dll
> copy /y %1.dll z:\
> copy /y %1.pdb z:\
> copy /y %1.sbr z:\
> 
> 
> the line "if exist z:\%1.dll rm z:\%1.dll z:\_%1.dll " always fails, even I 
> test it in CMD method. Example : 
> Start -> run -> cmd
> D:
> rm c:\aa.dll c:\_aa.dll

Why not being consistant and use the DOSish "del" command instead?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Is this bug in who?

2008-05-21 Thread Subash Patel
$   who am i?
spsaspts/5May 21 07:52 (10.0.71.131)
$   who am i
spsaspts/5May 21 07:52 (10.0.71.131)
$   who you are
spsaspts/5May 21 07:52 (10.0.71.131)
$   who who who
spsaspts/5May 21 07:52 (10.0.71.131)
$   who who
$   who who who
spsaspts/5May 21 07:52 (10.0.71.131)
$   who abcd abcd
spsaspts/5May 21 07:52 (10.0.71.131)
$   uname -a
Linux sasken01 2.6.19-rc3-1-486 #1 Mon Oct 30 13:49:42 UTC 2006 i686
GNU/Linux

 

I thought this should be a minor bug, although not critical.

 

Subash

SASKEN BUSINESS DISCLAIMER
-
This message may contain confidential, proprietary or legally privileged 
information. In 
case you are not the original intended Recipient of the message, you must not, 
directly or 
indirectly, use, Disclose, distribute, print, or copy any part of this message 
and you are 
requested to delete it and inform the sender. Any views expressed in this 
message are 
those of the individual sender unless otherwise stated. Nothing contained in 
this message 
shall be construed as an offer or acceptance of any offer by Sasken 
Communication 
Technologies Limited ("Sasken") unless sent with that express intent and with 
due 
authority of Sasken. Sasken has taken enough precautions to prevent the spread 
of 
viruses. However the company accepts no liability for any damage caused by any 
virus 
transmitted by this email
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Is this bug in who?

2008-05-21 Thread James Youngman
I assume you are surprised by the result for "who abcd abcd", but I
think that just means you didn't read the documentation yet. If
you are trying to report a bug could you explain what you think is
wrong?

James.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Is this bug in who?

2008-05-21 Thread Eric Blake

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Subash Patel on 5/21/2008 5:51 AM:
| $   who abcd abcd
| spsaspts/5May 21 07:52 (10.0.71.131)
|
| I thought this should be a minor bug, although not critical.

And what exactly did you expect?  I saw nothing in your trace that looked
suspicious - you have to tell us where the behavior didn't match your
expectations, before we can tell you if it is a bug or just a
misunderstanding on your part.

| This message may contain confidential, proprietary

Please ensure that future mails on this subject omit this trailer; perhaps
by opening up a free web-based email rather than going through your
employer's mail.  It is an unenforceable disclaimer by virtue of the fact
that you posted to a publicly archived mailing list; however, some people
refuse, on principle, to answer such mail.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg0F/cACgkQ84KuGfSFAYBbfwCfXZ14o5l0MhZ9Vk5SUpV/XC3U
/YUAniJJdT/7ESYzrTMhGjaytMBI1RZJ
=llkc
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


RE: Is this bug in who?

2008-05-21 Thread Subash Patel
James,
I appreciate your prompt reply. I am
pasting the cut section from "info coreutils who"
-
If given two non-option arguments, `who' prints only the entry for
the user running it (determined from its standard input), preceded by
the hostname.  Traditionally, the two arguments given are `am i', as in
`who am i'.
-
Although I have been using this command for a long time,
I never gave a thought to try something like today, which happened by a
typo. As per this document, "am I" is considered as arguments (most
common one). So isnt it required to validate them? "Who abcd abcd" has
no meaning when the purpose was "who am I", and both throw same output.

Thanks,
Subash


Please reply me if you have anything to id cc'ed.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Youngman
Sent: Wednesday, May 21, 2008 6:09 PM
To: Subash Patel
Cc: bug-coreutils@gnu.org
Subject: Re: Is this bug in who?

I assume you are surprised by the result for "who abcd abcd", but I
think that just means you didn't read the documentation yet. If
you are trying to report a bug could you explain what you think is
wrong?

James.
SASKEN BUSINESS DISCLAIMER
-
This message may contain confidential, proprietary or legally privileged 
information. In 
case you are not the original intended Recipient of the message, you must not, 
directly or 
indirectly, use, Disclose, distribute, print, or copy any part of this message 
and you are 
requested to delete it and inform the sender. Any views expressed in this 
message are 
those of the individual sender unless otherwise stated. Nothing contained in 
this message 
shall be construed as an offer or acceptance of any offer by Sasken 
Communication 
Technologies Limited ("Sasken") unless sent with that express intent and with 
due 
authority of Sasken. Sasken has taken enough precautions to prevent the spread 
of 
viruses. However the company accepts no liability for any damage caused by any 
virus 
transmitted by this email



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Is this bug in who?

2008-05-21 Thread Eric Blake

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Subash Patel on 5/21/2008 6:51 AM:
|   Although I have been using this command for a long time,
| I never gave a thought to try something like today, which happened by a
| typo. As per this document, "am I" is considered as arguments (most
| common one). So isnt it required to validate them?

who is working exactly as documented.  There is nothing _to_ validate -
the documentation states that who changes its behavior merely because of
the _presence_ of two arguments, without regards to the contents of those
arguments.

| "Who abcd abcd" has
| no meaning when the purpose was "who am I", and both throw same output.

As designed.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg0HA0ACgkQ84KuGfSFAYCP1gCgr5uNI+MWkg+UEJTfZC7OauvD
/aoAoJUODPmZO38R6q5CrGBhoeAPlKdQ
=5T68
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


RE: Is this bug in who?

2008-05-21 Thread Subash Patel
Eric,
Thanks for that reply. I have cc'ed your
group and expect you got my reply to James. The same reply holds good
here as well.

Thanks,
Subash 

-Original Message-
From: Eric Blake [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 6:09 PM
To: Subash Patel
Cc: bug-coreutils@gnu.org
Subject: Re: Is this bug in who?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Subash Patel on 5/21/2008 5:51 AM:
| $   who abcd abcd
| spsaspts/5May 21 07:52 (10.0.71.131)
|
| I thought this should be a minor bug, although not critical.

And what exactly did you expect?  I saw nothing in your trace that
looked suspicious - you have to tell us where the behavior didn't match
your expectations, before we can tell you if it is a bug or just a
misunderstanding on your part.

| This message may contain confidential, proprietary

Please ensure that future mails on this subject omit this trailer;
perhaps by opening up a free web-based email rather than going through
your employer's mail.  It is an unenforceable disclaimer by virtue of
the fact that you posted to a publicly archived mailing list; however,
some people refuse, on principle, to answer such mail.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg0F/cACgkQ84KuGfSFAYBbfwCfXZ14o5l0MhZ9Vk5SUpV/XC3U
/YUAniJJdT/7ESYzrTMhGjaytMBI1RZJ
=llkc
-END PGP SIGNATURE-
SASKEN BUSINESS DISCLAIMER
-
This message may contain confidential, proprietary or legally privileged 
information. In 
case you are not the original intended Recipient of the message, you must not, 
directly or 
indirectly, use, Disclose, distribute, print, or copy any part of this message 
and you are 
requested to delete it and inform the sender. Any views expressed in this 
message are 
those of the individual sender unless otherwise stated. Nothing contained in 
this message 
shall be construed as an offer or acceptance of any offer by Sasken 
Communication 
Technologies Limited ("Sasken") unless sent with that express intent and with 
due 
authority of Sasken. Sasken has taken enough precautions to prevent the spread 
of 
viruses. However the company accepts no liability for any damage caused by any 
virus 
transmitted by this email



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: should GNU install call matchpathcon by default?

2008-05-21 Thread Jim Meyering
Ondrej Vasik <[EMAIL PROTECTED]> wrote:
> Jim Meyering  meyering.net> writes:
>> In the multi-file case, the pre-patch performance penalty for enabling
>> the ifdef'd-out code would range from probably-immeasurable (for just
>> 2 or 3 files) to infinite, with enough files to make install exhaust
>> virtual memory.
>
> Actually even for 2-3 files (copied to /usr/temp dir) it was measurable.
> On my machine the performance impact is following:
> Setdefaultcontext code if0'd:  0.0148 s.
> Current patch(matchpathcon_init_prefix just once): 0.0666 s.
> Old setdefaultcontext code:0.1702 s.
>
> For 100 files(copied to /usr/temp) it took 4.0342 s. - that's about 35,5 times
> more than with current patch from Jim and 128 times more than with if0'd
> setdefaultcontext code. And of course for more files it goes to infinity.
>
> Problem is that disabled code is causing bugzilla tickets like
> https://bugzilla.redhat.com/show_bug.cgi?id=319231 , so maybe the best 
> solution

Perhaps you mean some other BZ?  That one doesn't involve performance.
To enable the code in question, just define this symbol for install.c:
ENABLE_WHEN_MATCHPATHCON_IS_MORE_EFFICIENT

> to reduce performance impact would be to patch automake to install multiple
> files in one directory at once or something like that - to reduce performance
> impact of the ifdefed code on installation of big portions of files.

That will help, and part of it is already done in upstream automake:

2008-03-08  Ralf Wildenhues  <[EMAIL PROTECTED]>

Use `install' with multiple files at once for some primaries.
With nobase targets, at most 50 files are installed at once,
to avoid quadratic string concatenation and line length limits.
This isn't yet done with base targets.  One hope is that there,
the typical file name length is lower.  If this turns out to be
a problem, it should be revisited.

but that doesn't yet help when installing e.g., coreutils' 100 programs,
since the existing code still loops, installing each individually.
In a way, it has to, because with --program-transform-name, it may
have to rename each one.

However, automake *can* (and probably will, now that I've proposed it)
special-case the very common situation in which there is no
--program-transform-name and $(EXEEXT) is empty.  Maybe someone
will propose a patch to do that.  A 30x performance improvement is
worth a small compromise for the common case.

However, the underlying problem still needs to be dealt with:
the outrageous expense of the matchpathcon function.
Is anyone planning to address that?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: should GNU install call matchpathcon by default?

2008-05-21 Thread Stephen Smalley

On Wed, 2008-05-21 at 16:26 +0200, Jim Meyering wrote:
> Ondrej Vasik <[EMAIL PROTECTED]> wrote:
> > Jim Meyering  meyering.net> writes:
> >> In the multi-file case, the pre-patch performance penalty for enabling
> >> the ifdef'd-out code would range from probably-immeasurable (for just
> >> 2 or 3 files) to infinite, with enough files to make install exhaust
> >> virtual memory.
> >
> > Actually even for 2-3 files (copied to /usr/temp dir) it was measurable.
> > On my machine the performance impact is following:
> > Setdefaultcontext code if0'd:  0.0148 s.
> > Current patch(matchpathcon_init_prefix just once): 0.0666 s.
> > Old setdefaultcontext code:0.1702 s.
> >
> > For 100 files(copied to /usr/temp) it took 4.0342 s. - that's about 35,5 
> > times
> > more than with current patch from Jim and 128 times more than with if0'd
> > setdefaultcontext code. And of course for more files it goes to infinity.
> >
> > Problem is that disabled code is causing bugzilla tickets like
> > https://bugzilla.redhat.com/show_bug.cgi?id=319231 , so maybe the best 
> > solution
> 
> Perhaps you mean some other BZ?  That one doesn't involve performance.
> To enable the code in question, just define this symbol for install.c:
> ENABLE_WHEN_MATCHPATHCON_IS_MORE_EFFICIENT
> 
> > to reduce performance impact would be to patch automake to install multiple
> > files in one directory at once or something like that - to reduce 
> > performance
> > impact of the ifdefed code on installation of big portions of files.
> 
> That will help, and part of it is already done in upstream automake:
> 
> 2008-03-08  Ralf Wildenhues  <[EMAIL PROTECTED]>
> 
> Use `install' with multiple files at once for some primaries.
> With nobase targets, at most 50 files are installed at once,
> to avoid quadratic string concatenation and line length limits.
> This isn't yet done with base targets.  One hope is that there,
> the typical file name length is lower.  If this turns out to be
> a problem, it should be revisited.
> 
> but that doesn't yet help when installing e.g., coreutils' 100 programs,
> since the existing code still loops, installing each individually.
> In a way, it has to, because with --program-transform-name, it may
> have to rename each one.
> 
> However, automake *can* (and probably will, now that I've proposed it)
> special-case the very common situation in which there is no
> --program-transform-name and $(EXEEXT) is empty.  Maybe someone
> will propose a patch to do that.  A 30x performance improvement is
> worth a small compromise for the common case.
> 
> However, the underlying problem still needs to be dealt with:
> the outrageous expense of the matchpathcon function.
> Is anyone planning to address that?

There have been a number of small optimizations made over time, and we
keep looking for other ways to improve the situation. There is also an
experimental implementation in progress to replace the current use of
pathname regexes with a simpler glob syntax (FCglob) that should help if
it succeeds.

-- 
Stephen Smalley
National Security Agency



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Is this bug in who?

2008-05-21 Thread James Youngman
On Wed, May 21, 2008 at 1:51 PM, Subash Patel <[EMAIL PROTECTED]> wrote:
> James,
>I appreciate your prompt reply. I am
> pasting the cut section from "info coreutils who"
> -
> If given two non-option arguments, `who' prints only the entry for
> the user running it (determined from its standard input), preceded by
> the hostname.  Traditionally, the two arguments given are `am i', as in
> `who am i'.
> -
>Although I have been using this command for a long time,
> I never gave a thought to try something like today, which happened by a
> typo. As per this document, "am I" is considered as arguments (most
> common one). So isnt it required to validate them? "Who abcd abcd" has
> no meaning when the purpose was "who am I", and both throw same output.

In terms of the specification at
http://www.opengroup.org/onlinepubs/009695399/utilities/who.html,
we're required to support "am I" and "am i".   We're doing that.   But
there is no standard interpretation of any other non-option arguments.

Hence the current behaviour is allowable, but if I understand you
correctly you're just pointing out that it is surprising.I guess
it is, really.   I'm not really sure though on what grounds we should
restrict the allowed arguments, or how we should explain the new
restrictions to the user.

James.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


I think sort has a bug

2008-05-21 Thread Dai, Manhong
Hi,


I think I found a bug of sort. the command is 

echo -e "a0 1\na 1\na1 1" | sort


The result is
a0 1
a 1
a1 1


Is this wrong?


Best,
Manhong Dai
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: I think sort has a bug

2008-05-21 Thread Bob Proulx
Dai, Manhong wrote:
>   I think I found a bug of sort. the command is 
> 
> echo -e "a0 1\na 1\na1 1" | sort
> a0 1
> a 1
> a1 1
> 
>   Is this wrong?

The result is dependent upon your configured locale.  The above is
correct in a locale that ignores punctuation such as en_US.  Please
see this reference for more information.

  
http://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils