Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
...
I have installed Fedora 8 on another 32bit x86 system, and the problem
appears there too.
(I moved /etc/csh* out of the way, used a freshly created account that
uses /bin/tcsh. I also deleted all the ~/.* files)
I straced the mingetty process corresponding to VT 1, and logged on
there.
The only mention of SIGPIPE is this:
4549 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
...
Maybe it is done in some library? Here's the part of the strace log that
includes the SIGPIPE handling
I've tracked it down.
mingetty exec's /bin/login, which calls pam stuff, which in turn uses
libdbus. And that is the culprit:
./dbus/dbus-sysdeps-unix.c-_dbus_disable_sigpipe (void)
./dbus/dbus-sysdeps-unix.c-{
./dbus/dbus-sysdeps-unix.c: signal (SIGPIPE, SIG_IGN);
./dbus/dbus-sysdeps-unix.c-}
That function is called by default.
The change that introduced this behavior dates back to 2003:
http://www.redhat.com/archives/message-bus-list/2003-February/msg1.html
Perhaps dbus-the-daemon needs this behavior, but the library code must not
ignore SIGPIPE. Since it's a library, it shouldn't modify process state
at all, but if portability dictates that it ignore SIGPIPE temporarily,
it should be careful to restore the preceding handler asap. The dbus
library can avoid the problem altogether when a system supports sendto's
new POSIX-specified MSG_NOSIGNAL flag (just test #ifdef MSG_NOSIGNAL):
MSG_NOSIGNAL
Requests not to send SIGPIPE on errors on stream oriented
sockets when the other end breaks the connection. The
EPIPE error is still returned.
I'm filing a bug report to the dbus folks.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote:
...
I have installed Fedora 8 on another 32bit x86 system, and the problem
appears there too.
(I moved /etc/csh* out of the way, used a freshly created account that
uses /bin/tcsh. I also deleted all the ~/.* files)
I straced the mingetty process corresponding to VT 1, and logged on
there.
The only mention of SIGPIPE is this:
4549 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
4549 is the mingetty process.
That may be the root of your problem.
Some process is ignoring SIGPIPE.
Odd.. I don't see any trace of SIGPIPE in the mingetty sources.
I looked at the sources for rawhide's mingetty-1.07-6.
Are you sure 4549 is the PID of a process running mingetty?
What version of mingetty are you using?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
...
I have installed Fedora 8 on another 32bit x86 system, and the problem
appears there too.
(I moved /etc/csh* out of the way, used a freshly created account that
uses /bin/tcsh. I also deleted all the ~/.* files)
I straced the mingetty process corresponding to VT 1, and logged on
there.
The only mention of SIGPIPE is this:
4549 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
4549 is the mingetty process.
That may be the root of your problem.
Some process is ignoring SIGPIPE.
Odd.. I don't see any trace of SIGPIPE in the mingetty sources.
Maybe it is done in some library? Here's the part of the strace log that
includes the SIGPIPE handling
4549 access(/var/run/console/dann, F_OK) = 0
4549 fstat64(3, {st_mode=S_IFREG|0600, st_size=1, ...}) = 0
4549 read(3, 1, 1) = 1
4549 _llseek(3, 0, [0], SEEK_SET) = 0
4549 write(3, 2, 1) = 1
4549 close(3) = 0
4549 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
4549 gettid() = 4549
4549 open(/proc/self/task/4549/attr/current, O_RDONLY|O_LARGEFILE) = 3
4549 read(3, kernel\0, 4095) = 7
4549 close(3) = 0
4549 open(/etc/passwd, O_RDONLY|0x8 /* O_??? */) = 3
4549 fstat64(3, {st_mode=S_IFREG|0644, st_size=1729, ...}) = 0
4549 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7f24
000
4549 read(3, root:x:0:0:root:/root:/bin/bash\n..., 4096) = 1729
4549 close(3) = 0
4549 munmap(0xb7f24000, 4096) = 0
4549 socket(PF_FILE, SOCK_STREAM, 0) = 3
4549 connect(3, {sa_family=AF_FILE, path=/var/run/dbus/system_bus_socket},
33) = 0
4549 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
4549 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4549 fcntl64(3, F_GETFD) = 0
4549 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
4549 getuid32()= 0
4549 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
4549 poll([{fd=3, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
4549 write(3, \0, 1) = 1
4549 write(3, AUTH EXTERNAL 30\r\n, 18) = 18
4549 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, -1) = 1
I looked at the sources for rawhide's mingetty-1.07-6.
Are you sure 4549 is the PID of a process running mingetty?
Yep, I have the command in history:
strace -f -o out.strace -p 4549
and I started stracing from mingetty.
What version of mingetty are you using?
mingetty-1.07-6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
...
I created a new account with /bin/tcsh as a shell, deleted all the
dot
files in that new account, logged in on a linux console and run the
perl command above. It prints IGNORE.
tcsh is: tcsh-6.14-15
perl is: perl-5.8.8-23.fc7
Finally! So that version of tcsh may be at fault.
I built tcsh-6.15 using the F8 rpm, and the problem still occurs with
that one.
When you tested this, did you try from an account that uses tcsh as
the shell? Because if I start tcsh from bash things work...
Yes. I changed my shell to /bin/tcsh and logged in again.
Have you tried on other systems?
I have installed Fedora 8 on another 32bit x86 system, and the problem
appears there too.
(I moved /etc/csh* out of the way, used a freshly created account that
uses /bin/tcsh. I also deleted all the ~/.* files)
I straced the mingetty process corresponding to VT 1, and logged on
there.
The only mention of SIGPIPE is this:
4549 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
4549 is the mingetty process.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: ... I created a new account with /bin/tcsh as a shell, deleted all the dot files in that new account, logged in on a linux console and run the perl command above. It prints IGNORE. tcsh is: tcsh-6.14-15 perl is: perl-5.8.8-23.fc7 Finally! So that version of tcsh may be at fault. I built tcsh-6.15 using the F8 rpm, and the problem still occurs with that one. When you tested this, did you try from an account that uses tcsh as the shell? Because if I start tcsh from bash things work... Yes. I changed my shell to /bin/tcsh and logged in again. Have you tried on other systems? I did. I only have access to one F7 system, and that is the one where I observed the problems. I tried on FC5, no problem there with either the original tcsh, with the version from F7 recompiled on FC5... Did you already look at /etc/csh.*? Move them aside and try again, just in case. Tried it, no difference. I'm running out of ideas, but you might want to use oprofile to trace everything from login to your first prompt. Do it twice. First with /bin/bash as your shell, then with /bin/tcsh. Then compare. Let's see if I have time to do this before the machine gets upgraded to F8... So I have an older version of tcsh than you do. I looked at the src.rpm for my version of tcsh and it has a patch that tinkers with signal handling (not with SIGPIPE, but still...). I'll try to install your version of tcsh tonight, and maybe build my version without any patches. If you could reproduce the problem by starting tcsh manually, I'd suggest debugging (or just using strace) tcsh to see where it's misbehaving. What should I look for? In source, look for calls to signal, sigaction, sigprocmask. On recent Linux, they show up in strace output as calls to rt_sigaction and rt_sigprocmask. strace did not show anything about SIGPIPE. I wouldn't expect it to, since you can't reproduce the problem by starting tcsh manually. If I start tcsh from a tcsh login shell I can reproduce the problem... Thanks! --dan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Bob Proulx) writes: Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. The output is write error: Broken pipe. Then that is a pretty strong indication that your session is trapping SIGPIPE. You will have to debug that to root cause. Something, somewhere in the start path for you is trapping that and it will cause endless problems until it is found and fixed. Advice on finding that would be welcome. As I suggested earlier, you need to find the shell code (probably bourne shell code) that your window manager is running before it exec's xterm. You'll probably find a trap stmt there. If I execute the same thing in a Linux console it never stops. Do you mean that on the console that you do not get that error and everything seems to be working properly? That is what we would expect and should be the normal behavior in your other terminals too, but apparently is not. Please ignore my statement above, I made a typo on the command line. I run a few more experiments with the bash command above: - when run from an xterm it fails with the broken pipe error - when run from in an xterm like this: bash tcsh bash -c '(while echo foo; do :; done); echo status=$? 2' | head it prints 141. - when run from the Linux console it fails with the broken pipe error. In that case the pstree chain is like this: init - login - tcsh That's the way it should be. So your login shell is clean, but window-manager-spawned tools get the bad environment. You haven't said what window manager you're using, but each one usually comes with plenty of start-up scripts (usually under /etc). Search those for the trap. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Bob Proulx) writes: Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. - when run from the Linux console it fails with the broken pipe error. In that case the pstree chain is like this: init - login - tcsh That's the way it should be. So your login shell is clean, Are you sure? It seems to me that the right way is to not fail with the broken pipe error, but to print 141. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Bob Proulx) writes: Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. - when run from the Linux console it fails with the broken pipe error. In that case the pstree chain is like this: init - login - tcsh That's the way it should be. So your login shell is clean, Are you sure? It seems to me that the right way is to not fail with the broken pipe error, but to print 141. Oh. You're right. I misread. What version of bash are you using? Did you compile it yourself? There was a related bug in bash back in 2004, so be sure you're using something recent. Have you tried changing your login shell to bash? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Bob Proulx) writes: Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. - when run from the Linux console it fails with the broken pipe error. In that case the pstree chain is like this: init - login - tcsh That's the way it should be. So your login shell is clean, Are you sure? It seems to me that the right way is to not fail with the broken pipe error, but to print 141. Oh. You're right. I misread. What version of bash are you using? bash-3.2-9.fc7 Did you compile it yourself? No. There was a related bug in bash back in 2004, so be sure you're using something recent. Have you tried changing your login shell to bash? Yeah, changing the login shell to bash works. But so does running bash from tcsh and running tcsh from that bash. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote: ... Have you tried changing your login shell to bash? Yeah, changing the login shell to bash works. But so does running bash from tcsh and running tcsh from that bash. I've tried setting my shell to tcsh (tcsh-6.15-1.fc8) but still can't get it to fail the way it does for you. Have you tried moving aside all of your ~/.??* files? Maybe one of those is causing the trouble. If you can reproduce it with an empty home directory, at least we'll know it something specific to tcsh itself and/or start-up files it reads from somewhere other than your home dir. Are you beginning to see why some people prefer not to use tcsh? :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] wrote:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
...
Have you tried changing your login shell to bash?
Yeah, changing the login shell to bash works.
But so does running bash from tcsh and running tcsh from that bash.
I've tried setting my shell to tcsh (tcsh-6.15-1.fc8)
but still can't get it to fail the way it does for you.
Have you tried moving aside all of your ~/.??* files?
Maybe one of those is causing the trouble.
If you can reproduce it with an empty home directory,
at least we'll know it something specific to tcsh itself and/or
start-up files it reads from somewhere other than your home dir.
Are you beginning to see why some people prefer not to use tcsh? :-)
Here's a more direct way to test tcsh's sighandler. Run this:
perl -le 'print $SIG{PIPE}'
When I start tcsh from an environment where SIGPIPE is ignored,
(which is where you see the troubling behavior) it prints IGNORE:
bash$ (trap '' PIPE; tcsh)
tcsh$ seq 90|head -1
1
seq: write error: Broken pipe
tcsh$ perl -le 'print $SIG{PIPE}'
IGNORE
With zsh-4.3.4 on debian unstable, I get this (and no diagnostic from seq):
zsh$ perl -le 'print $SIG{PIPE}'
Use of uninitialized value in print at -e line 1.
With rawhide's zsh-4.3.4-4.fc8, I get this:
zsh$ perl -le 'print $SIG{PIPE}'
zsh$
Hmm... I wonder why the small difference? Both are perl-5.8.8.
Probably irrelevant.
If you could reproduce the problem by starting tcsh manually,
I'd suggest debugging (or just using strace) tcsh to see where
it's misbehaving.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes:
Jim Meyering [EMAIL PROTECTED] wrote:
Dan Nicolaescu [EMAIL PROTECTED] wrote:
...
Have you tried changing your login shell to bash?
Yeah, changing the login shell to bash works.
But so does running bash from tcsh and running tcsh from that bash.
I've tried setting my shell to tcsh (tcsh-6.15-1.fc8)
but still can't get it to fail the way it does for you.
Have you tried moving aside all of your ~/.??* files?
Maybe one of those is causing the trouble.
If you can reproduce it with an empty home directory,
at least we'll know it something specific to tcsh itself and/or
start-up files it reads from somewhere other than your home dir.
Are you beginning to see why some people prefer not to use tcsh? :-)
Here's a more direct way to test tcsh's sighandler. Run this:
perl -le 'print $SIG{PIPE}'
When I start tcsh from an environment where SIGPIPE is ignored,
(which is where you see the troubling behavior) it prints IGNORE:
I created a new account with /bin/tcsh as a shell, deleted all the dot
files in that new account, logged in on a linux console and run the
perl command above. It prints IGNORE.
tcsh is: tcsh-6.14-15
perl is: perl-5.8.8-23.fc7
So I have an older version of tcsh than you do.
I looked at the src.rpm for my version of tcsh and it has a patch that
tinkers with signal handling (not with SIGPIPE, but still...). I'll
try to install your version of tcsh tonight, and maybe build my
version without any patches.
If you could reproduce the problem by starting tcsh manually,
I'd suggest debugging (or just using strace) tcsh to see where
it's misbehaving.
What should I look for?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote: ... I created a new account with /bin/tcsh as a shell, deleted all the dot files in that new account, logged in on a linux console and run the perl command above. It prints IGNORE. tcsh is: tcsh-6.14-15 perl is: perl-5.8.8-23.fc7 Finally! So that version of tcsh may be at fault. So I have an older version of tcsh than you do. I looked at the src.rpm for my version of tcsh and it has a patch that tinkers with signal handling (not with SIGPIPE, but still...). I'll try to install your version of tcsh tonight, and maybe build my version without any patches. If you could reproduce the problem by starting tcsh manually, I'd suggest debugging (or just using strace) tcsh to see where it's misbehaving. What should I look for? In source, look for calls to signal, sigaction, sigprocmask. On recent Linux, they show up in strace output as calls to rt_sigaction and rt_sigprocmask. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: ... I created a new account with /bin/tcsh as a shell, deleted all the dot files in that new account, logged in on a linux console and run the perl command above. It prints IGNORE. tcsh is: tcsh-6.14-15 perl is: perl-5.8.8-23.fc7 Finally! So that version of tcsh may be at fault. I built tcsh-6.15 using the F8 rpm, and the problem still occurs with that one. When you tested this, did you try from an account that uses tcsh as the shell? Because if I start tcsh from bash things work... So I have an older version of tcsh than you do. I looked at the src.rpm for my version of tcsh and it has a patch that tinkers with signal handling (not with SIGPIPE, but still...). I'll try to install your version of tcsh tonight, and maybe build my version without any patches. If you could reproduce the problem by starting tcsh manually, I'd suggest debugging (or just using strace) tcsh to see where it's misbehaving. What should I look for? In source, look for calls to signal, sigaction, sigprocmask. On recent Linux, they show up in strace output as calls to rt_sigaction and rt_sigprocmask. strace did not show anything about SIGPIPE. Thanks for your help! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] wrote: ... I created a new account with /bin/tcsh as a shell, deleted all the dot files in that new account, logged in on a linux console and run the perl command above. It prints IGNORE. tcsh is: tcsh-6.14-15 perl is: perl-5.8.8-23.fc7 Finally! So that version of tcsh may be at fault. I built tcsh-6.15 using the F8 rpm, and the problem still occurs with that one. When you tested this, did you try from an account that uses tcsh as the shell? Because if I start tcsh from bash things work... Yes. I changed my shell to /bin/tcsh and logged in again. Have you tried on other systems? Did you already look at /etc/csh.*? Move them aside and try again, just in case. I'm running out of ideas, but you might want to use oprofile to trace everything from login to your first prompt. Do it twice. First with /bin/bash as your shell, then with /bin/tcsh. Then compare. So I have an older version of tcsh than you do. I looked at the src.rpm for my version of tcsh and it has a patch that tinkers with signal handling (not with SIGPIPE, but still...). I'll try to install your version of tcsh tonight, and maybe build my version without any patches. If you could reproduce the problem by starting tcsh manually, I'd suggest debugging (or just using strace) tcsh to see where it's misbehaving. What should I look for? In source, look for calls to signal, sigaction, sigprocmask. On recent Linux, they show up in strace output as calls to rt_sigaction and rt_sigprocmask. strace did not show anything about SIGPIPE. I wouldn't expect it to, since you can't reproduce the problem by starting tcsh manually. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] writes: Nope, nothing. Can you determine whether processes have SIGPIPE trapped somehow? If so, that's the problem; and you can try to track that down. For example, what does this shell command do? bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Paul Eggert [EMAIL PROTECTED] writes: Dan Nicolaescu [EMAIL PROTECTED] writes: Nope, nothing. Can you determine whether processes have SIGPIPE trapped somehow? If so, that's the problem; and you can try to track that down. For example, what does this shell command do? bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. The output is write error: Broken pipe. If I execute the same thing in a Linux console it never stops. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. The output is write error: Broken pipe. Then that is a pretty strong indication that your session is trapping SIGPIPE. You will have to debug that to root cause. Something, somewhere in the start path for you is trapping that and it will cause endless problems until it is found and fixed. If I execute the same thing in a Linux console it never stops. Do you mean that on the console that you do not get that error and everything seems to be working properly? That is what we would expect and should be the normal behavior in your other terminals too, but apparently is not. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
[EMAIL PROTECTED] (Bob Proulx) writes: Dan Nicolaescu wrote: Paul Eggert writes: bash -c '(while echo foo; do :; done); echo status=$? 2' | head If it eventually outputs write error: Broken pipe, you have SIGPIPE trapped, and that would explain your problem (which you need to track down). If it prints status=141 you do not have SIGPIPE trapped and we need to investigate the issue further. The output is write error: Broken pipe. Then that is a pretty strong indication that your session is trapping SIGPIPE. You will have to debug that to root cause. Something, somewhere in the start path for you is trapping that and it will cause endless problems until it is found and fixed. Advice on finding that would be welcome. If I execute the same thing in a Linux console it never stops. Do you mean that on the console that you do not get that error and everything seems to be working properly? That is what we would expect and should be the normal behavior in your other terminals too, but apparently is not. Please ignore my statement above, I made a typo on the command line. I run a few more experiments with the bash command above: - when run from an xterm it fails with the broken pipe error - when run from in an xterm like this: bash tcsh bash -c '(while echo foo; do :; done); echo status=$? 2' | head it prints 141. - when run from the Linux console it fails with the broken pipe error. In that case the pstree chain is like this: init - login - tcsh ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
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
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: ls: write error: Broken pipe
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
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: ls: write error: Broken pipe
-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: ls: write error: Broken pipe
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
ls: write error: Broken pipe
I have been using this alias: lt = 'ls -lt | head' for a long long time, on many systems. On Fedora 7 I get this from time to time: cd /usr/lib lt total 162508 drwxr-xr-x 10 rpm rpm 4096 2007-10-31 00:11 rpm/ drwxr-xr-x 13 root root 4096 2007-10-31 00:11 firefox-2.0.0.5/ drwxr-xr-x 3 root root 4096 2007-10-31 00:10 gthumb/ drwxr-xr-x 3 root root 4096 2007-10-31 00:10 scim-1.0/ drwxr-xr-x 4 root root 4096 2007-10-22 08:22 xemacs-21.5-b28/ drwxr-xr-x 4 root root 4096 2007-10-22 08:22 xemacs/ lrwxrwxrwx 1 root root 19 2007-10-22 08:22 libneXtaw.so.0 - libneXtaw.so.0.15.1* lrwxrwxrwx 1 root root 20 2007-10-22 08:22 libcompface.so.1 - libcompface.so.1.0.0* lrwxrwxrwx 1 root root 19 2007-10-22 08:22 libcanna16.so.1 - libcanna16.so.1.2.0* lrwxrwxrwx 1 root root 17 2007-10-22 08:22 libcanna.so.1 - libcanna.so.1.2.0* lrwxrwxrwx 1 root root 17 2007-10-22 08:22 libRKC16.so.1 - libRKC16.so.1.2.0* lrwxrwxrwx 1 root root 15 2007-10-22 08:22 libRKC.so.1 - libRKC.so.1.2.0* drwxr-xr-x 2 root root 4096 2007-10-19 10:16 tk8.4/ lrwxrwxrwx 1 root root 17 2007-10-19 10:16 tcl8.4 - /usr/share/tcl8.4/ lrwxrwxrwx 1 root root 27 2007-10-19 10:15 libsvn_swig_perl-1.so.0 - libsvn_swig_perl-1.so.0.0.0* drwxr-xr-x 2 root root 4096 2007-10-16 19:59 vte/ lrwxrwxrwx 1 root root 25 2007-10-11 06:54 libsvn_swig_py-1.so.0 - libsvn_swig_py-1.so.0.0.0* lrwxrwxrwx 1 root root 20 2007-10-11 06:54 libsvn_wc-1.so.0 - libsvn_wc-1.so.0.0.0* lrwxrwxrwx 1 root root 26 2007-10-11 06:54 libsvn_ra_local-1.so.0 - libsvn_ra_local-1.so.0.0.0* ls: write error: Broken pipe Is there any reason for this error to be printed? The strange thing is that I don't always get this error, I could run lt and not see the error, then run it again and see it. I am using: coreutils-6.9-3.fc7 Thanks --dan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] writes: ls: write error: Broken pipe Most likely you are trapping the PIPE signal. For example: 524-penguin $ ls -lR | head -1 .: 525-penguin $ trap '' PIPE 526-penguin $ ls -lR | head -1 .: ls: write error: Broken pipe 527-penguin $ This is on Debian stable, but Fedora should be similar. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
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. Some programs (like git) prefer not to diagnose this type of write failure, but coreutils makes a point of never suppressing such diagnostics, because sometimes they're legitimate. 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
