On Mon, Feb 28, 2005 at 10:06:23AM +0000, [EMAIL PROTECTED] wrote: > Felipe Kellermann wrote: > >On Sat, 26 Feb 2005 5:39am +0100, Alfred M. Szmidt wrote: > > > > > >> > Did I mention ls should have a --no-total option > >> > to remove those annoying > >> > total 1120 > >> > without needing to pipe to a filter. > >> > >> Another possibility would be to output the `total' to stderr. > >> > >>The horror, why do people come up with these silly ideas? `total > >>NNNNN' is not a error message, and doesn't belong on stderr. > > > > > >I've seen other programs printing only informative messages to stderr. > >And doing a find + fgrep I can even see coreutils programs doing so. > > bash is the one that annoys me most. > It puts errors AND THE PROMPT to stderr. > I's a very minimal patch to change this > (allowing one to automatically colour all errors > from bash and child programs red for e.g.), > but it was rejected with no reason :-(
The POSIX specification requires that the prompt be issued to stderr:- 1468 PS1 Each time an interactive shell is ready to read a command, the value of this 1469 variable shall be subjected to parameter expansion and written to standard 1470 error. The default value shall be "$ ". For users who have specific additional 1471 implementation-defined privileges, the default may be another, 1472 implementation-defined value. The shell shall replace each instance of the 1473 character '!' in PS1 with the history file number of the next command to be 1474 typed. Escaping the '!' with another '!' (that is, "!!") shall place the literal 1475 character '!' in the prompt. This volume of IEEE Std 1003.1-2001 specifies 1476 the effects of the variable only for systems supporting the User Portability 1477 Utilities option. I'm guessing that that is why your patch was rejected. Regards, James. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
