Re: ls: write error: Broken pipe

2007-11-02 Thread Jim Meyering
Dan Nicolaescu [EMAIL PROTECTED] wrote:
 Jim Meyering [EMAIL PROTECTED] writes:

Dan Nicolaescu [EMAIL PROTECTED] wrote:
 I have been using this alias: lt = 'ls -lt | head'
...
 ls: write error: Broken pipe

 Is there any reason for this error to be printed?
   
Hi Dan,
   
You should see it only if you have changed the default signal
handling to ignore SIGPIPE, and then only some of the time.
When it's possible to see it, kernel buffering and the size of your
environment also determine how much can be written before the
signal is sent.

 Hmm, that probably explains the behavior I am seeing: in the beginning
 no error, but after executing a few commands (i.e. the history size
 grows)

 This is with tcsh, and AFAIK tcsh does not have a way to tell it

I'm sure you've already heard it, but I have to say it:
You shouldn't use csh-based shells.
If you ask anyone or google, you'll find many good reasons.
Lack of a decent signal-handling mechanism is one of them.

 whether to catch SIGPIPE or not. Maybe something has changed in tcsh
 to make it catch SIGPIPE...

How do you start tcsh?
If you start from another shell that *does* ignore SIGPIPE,
that would explain it.

FWIW, I've just tested with tcsh-6.14.00 on debian unstable and
tcsh-6.15-1.fc8 on fedora rawhide, and neither does what yours does
when run interactively:

$ tcsh
tcsh$ seq 9|head -1
1
tcsh$

But when run via -c, tcsh's exit code indicates the SIGPIPE:
(it's my prompt-handling code that displays the [Exit 141 (PIPE)])

$ tcsh -c 'seq 9|head -1'
1
[Exit 141 (PIPE)]

If you ever get in the mood to switch, consider zsh.


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


Re: ls: write error: Broken pipe

2007-11-02 Thread Dan Nicolaescu
Jim Meyering [EMAIL PROTECTED] writes:

   Dan Nicolaescu [EMAIL PROTECTED] wrote:
I have been using this alias: lt = 'ls -lt | head'
   ...
ls: write error: Broken pipe
   
Is there any reason for this error to be printed?
   
   Hi Dan,
   
   You should see it only if you have changed the default signal
   handling to ignore SIGPIPE, and then only some of the time.
   When it's possible to see it, kernel buffering and the size of your
   environment also determine how much can be written before the
   signal is sent.

Hmm, that probably explains the behavior I am seeing: in the beginning
no error, but after executing a few commands (i.e. the history size
grows) 

This is with tcsh, and AFAIK tcsh does not have a way to tell it
whether to catch SIGPIPE or not. Maybe something has changed in tcsh
to make it catch SIGPIPE...

   This topic was beaten to death as a side effect of my patch to
   make git detect a bunch of previously-ignored write errors:
   
 http://thread.gmane.org/gmane.comp.version-control.git/48469/focus=48617
   
   If you're bored, read on in that thread... it gets even more animated.

Sorry, I don't know about this... (and I don't have time to read a
very long thread).


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


Re: Tiny magic file entry

2007-11-02 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to [EMAIL PROTECTED] on 11/2/2007 2:43 AM:
 60  string  SONGSoundFX Module sound file

Thanks for the report; however, coreutils does not maintain the file magic
database.

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

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

iD8DBQFHKxUF84KuGfSFAYARAiIsAKCR6/SLaM05Iw5qRjfCV3VlOVyrIwCeJV+W
jJ6bBliZPR3AGyBdaug3thc=
=L2H5
-END PGP SIGNATURE-


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


Re: ls: write error: Broken pipe

2007-11-02 Thread Dan Nicolaescu
Jim Meyering [EMAIL PROTECTED] writes:

   Dan Nicolaescu [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
   
   Dan Nicolaescu [EMAIL PROTECTED] wrote:
I have been using this alias: lt = 'ls -lt | head'
   ...
ls: write error: Broken pipe
   
Is there any reason for this error to be printed?
  
   Hi Dan,
  
   You should see it only if you have changed the default signal
   handling to ignore SIGPIPE, and then only some of the time.
   When it's possible to see it, kernel buffering and the size of your
   environment also determine how much can be written before the
   signal is sent.
   
Hmm, that probably explains the behavior I am seeing: in the beginning
no error, but after executing a few commands (i.e. the history size
grows)
   
This is with tcsh, and AFAIK tcsh does not have a way to tell it
   
   I'm sure you've already heard it, but I have to say it:
   You shouldn't use csh-based shells.
   If you ask anyone or google, you'll find many good reasons.

This is probably not the right place to talk about this, but since you
started...
bash didn't have decent programmable completion until 3.0 (maybe
3.1?). It still does not have dabbrev-expand, which for someone used
to emacs is irreplaceable. (Yes, I did submit a patch, it will be
available in the next version of bash). There's a few other missing
things: the prompt ellipsis, run-fg-editor, 

zsh is a non-starter, it is not available on many systems that I have
to use.

I am pretty happy with tcsh, the only problem is that some systems
don't install it by default anymore.

   Lack of a decent signal-handling mechanism is one of them.

This has never been a problem for my use.

whether to catch SIGPIPE or not. Maybe something has changed in tcsh
to make it catch SIGPIPE...
   
   How do you start tcsh?

It's the login shell. I used it in xterm, not sure how xterm starts
it.


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


Re: ls: write error: Broken pipe

2007-11-02 Thread Jim Meyering
Micah Cowan [EMAIL PROTECTED] wrote:
 Jim Meyering wrote:
 I'm sure you've already heard it, but I have to say it:
 You shouldn't use csh-based shells.
 If you ask anyone or google, you'll find many good reasons.
 Lack of a decent signal-handling mechanism is one of them.

 Usually when I hear this, it's in reference to shell scripting, and not
 interactive shell use. The famous Csh Considered Harmful article, for
 instance, is explicitly in the context of shell scripts, and not
 interactive use.

Well, some people are known to program on the command line, and when
I do that, I want to have an adequate language at my fingertips.
Similarly, we all do some amount of programming in our shell-startup
scripts, and should be able to expect them to work well, too.

I too started off thinking tcsh was great, but switched to bash about
the time CCH was written, and later to zsh.  I haven't looked back.


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


Re: new snapshot

2007-11-02 Thread Pádraig Brady
Andreas Schwab wrote:
 Where do you think it is buggy?  This is the classical effect of double
 rounding, and the printf formatting is doing exactly the right thing.

Yes you are right.
I misread my own test (again).

sigh,
Pádraig.



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


Re: new snapshot

2007-11-02 Thread Andreas Schwab
Pádraig Brady [EMAIL PROTECTED] writes:

 Jim Meyering wrote:
 
 Here are the ChangeLog entries since the 354-68c33a snapshot:
 -
 
 2007-11-01  Jim Meyering  [EMAIL PROTECTED]
 
  Adjust a seq subtest not to depend on the vagaries of floating point.
  * tests/misc/seq (float-3): Use 10.94 as the endpoint, not 10.95,
  since 10.95 was precisely in the middle of the interval, and with
  a %.1f format could map to either 10.9 or 11.0.
  Reported by Mike Frysinger

 I agree with the work around, but that's one buggy
 printf rounding implementation if you ask me.

Where do you think it is buggy?  This is the classical effect of double
rounding, and the printf formatting is doing exactly the right thing.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


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


Re: new snapshot

2007-11-02 Thread Jim Meyering
Pádraig Brady [EMAIL PROTECTED] wrote:
 Jim Meyering wrote:
...
 2007-11-01  Jim Meyering  [EMAIL PROTECTED]

  Adjust a seq subtest not to depend on the vagaries of floating point.
  * tests/misc/seq (float-3): Use 10.94 as the endpoint, not 10.95,
  since 10.95 was precisely in the middle of the interval, and with
  a %.1f format could map to either 10.9 or 11.0.
  Reported by Mike Frysinger

 I agree with the work around, but that's one buggy
 printf rounding implementation if you ask me.
 Where was this?

Hi Pádraig,

I think Mike's was on some ppc-based system, but I think
the cause was a buggy test, not a buggy printf function.
Did you see Andreas' messages in this thread?

  http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/11713


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


Re: new snapshot

2007-11-02 Thread Pádraig Brady
Jim Meyering wrote:
 
 Here are the ChangeLog entries since the 354-68c33a snapshot:
 -
 
 2007-11-01  Jim Meyering  [EMAIL PROTECTED]
 
   Adjust a seq subtest not to depend on the vagaries of floating point.
   * tests/misc/seq (float-3): Use 10.94 as the endpoint, not 10.95,
   since 10.95 was precisely in the middle of the interval, and with
   a %.1f format could map to either 10.9 or 11.0.
   Reported by Mike Frysinger

I agree with the work around, but that's one buggy
printf rounding implementation if you ask me.
Where was this?


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


Re: ls: write error: Broken pipe

2007-11-02 Thread Micah Cowan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jim Meyering wrote:
 I'm sure you've already heard it, but I have to say it:
 You shouldn't use csh-based shells.
 If you ask anyone or google, you'll find many good reasons.
 Lack of a decent signal-handling mechanism is one of them.

Jim,

Usually when I hear this, it's in reference to shell scripting, and not
interactive shell use. The famous Csh Considered Harmful article, for
instance, is explicitly in the context of shell scripts, and not
interactive use.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHK1zn7M8hyUobTrERCCx/AJ98q07a26xwTkSMcQZ5nLNGatkAbACeIkb9
AemM4lGRrbHpr/RVehQFRao=
=ghCS
-END PGP SIGNATURE-


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


Re: Tiny magic file entry

2007-11-02 Thread Christos Zoulas
On Nov 2,  9:12am, [EMAIL PROTECTED] (Eric Blake) wrote:
-- Subject: Re: Tiny magic file entry

| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
| 
| According to Leslie P. Polzer on 11/2/2007 8:30 AM:
|  -BEGIN PGP SIGNED MESSAGE-
|  Hash: SHA1
| 
|  According to [EMAIL PROTECTED] on 11/2/2007 2:43 AM:
|  60  string  SONGSoundFX Module sound file
|  Thanks for the report; however, coreutils does not maintain the file magic
|  database.
|  
|  Who does?
| 
| I didn't know, since 'file --help' doesn't list a bug reporting address,
| at least, as of version file-4.21.  So I guess I'm reporting that
| oversight as a second bug in file(1).

BTW, the contact information is in the man page.

| Fortunately, the Free Software Directory had some contact info:
| http://directory.fsf.org/project/file/
| 
| - --
| Don't work too hard, make some time for fun as well!
| 

Got it, thanks!

christos


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


Tiny magic file entry

2007-11-02 Thread leslie . polzer
60  string  SONGSoundFX Module sound file


pgp04QixkBwm2.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: ls: write error: Broken pipe

2007-11-02 Thread Jim Meyering
Dan Nicolaescu [EMAIL PROTECTED] wrote:
 This is probably not the right place to talk about this, but since you
 started...

:-)

 bash didn't have decent programmable completion until 3.0 (maybe

That was one of the reasons I switched to zsh.

 3.1?). It still does not have dabbrev-expand, which for someone used
 to emacs is irreplaceable. (Yes, I did submit a patch, it will be
 available in the next version of bash). There's a few other missing
 things: the prompt ellipsis, run-fg-editor,

I don't know what those are, sorry.

 zsh is a non-starter, it is not available on many systems that I have
 to use.

If it wasn't around, and couldn't be installed, I've
always just built a private version and made whatever
shell happened to be the default exec it.

 I am pretty happy with tcsh, the only problem is that some systems
 don't install it by default anymore.

Lack of a decent signal-handling mechanism is one of them.

 This has never been a problem for my use.

Before now, of course :-)

 whether to catch SIGPIPE or not. Maybe something has changed in tcsh
 to make it catch SIGPIPE...
   
How do you start tcsh?

 It's the login shell. I used it in xterm, not sure how xterm starts
 it.

Look at pstree output to see which program starts your xterm,
then see if that parent or some ancestor script uses trap.
Just searching for grep -w trap ~/.?? might give you something
interesting.

Either your version of tcsh is somehow different from mine,
or some parent process is catching SIGPIPE.


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


Re: Tiny magic file entry

2007-11-02 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Leslie P. Polzer on 11/2/2007 8:30 AM:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 According to [EMAIL PROTECTED] on 11/2/2007 2:43 AM:
 60  string  SONGSoundFX Module sound file
 Thanks for the report; however, coreutils does not maintain the file magic
 database.
 
 Who does?

I didn't know, since 'file --help' doesn't list a bug reporting address,
at least, as of version file-4.21.  So I guess I'm reporting that
oversight as a second bug in file(1).

Fortunately, the Free Software Directory had some contact info:
http://directory.fsf.org/project/file/

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

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

iD8DBQFHKz5A84KuGfSFAYARAsDbAKC8s+VGk4IQ7zcSPDppttu4WNgsxQCgmU4s
UrOL99JXqf0NUVnUyq/6DHU=
=ghFe
-END PGP SIGNATURE-


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


bug report, sort command

2007-11-02 Thread Peter Alefounder
I have recently installed Debian 4.0r1 with sort version 5.97.

The sort command ignores the characters #  % = _ and, for all I know,
other characters as well. Looks like it is acting as if I had used
the -d option, which I had not.

I set LC_ALL=C as suggested in the man page. The sort command
under my previous system, SuSE 9.1, worked as I would expect.

Regards,
Peter Alefounder.



  ___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 


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


Re: bug report, sort command

2007-11-02 Thread Bob Proulx
Peter Alefounder wrote:
 The sort command ignores the characters #  % = _ and, for all I know,
 other characters as well. Looks like it is acting as if I had used
 the -d option, which I had not.

That does sound like it matches a common pattern.  Please see this FAQ
entry for more information.

  http://www.gnu.org/software/coreutils/faq/coreutils-faq.html

 I set LC_ALL=C as suggested in the man page. The sort command
 under my previous system, SuSE 9.1, worked as I would expect.

Did setting LC_ALL=C resolve the problem?  Or did it not?

Bob


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


Re: bug report, sort command

2007-11-02 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Proulx on 11/2/2007 2:59 PM:
 I set LC_ALL=C as suggested in the man page. The sort command
 under my previous system, SuSE 9.1, worked as I would expect.
 
 Did setting LC_ALL=C resolve the problem?  Or did it not?

And did you make sure that the setting was actually exported to the
environment?  Which shell are you using?  Posting an actual transcript of
what you typed might be helpful.

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

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

iD8DBQFHK5GE84KuGfSFAYARAjBXAKCi6UZy9mRDq0B9F81NflNLtRZc7wCffbY3
97yoXT3kQ5xBPfFvSdEKCFw=
=eyAh
-END PGP SIGNATURE-


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