better support for color ls on 256 color terminals
Modern terminals support 256 colors. It would be great if ls --color could take advantage of the higher number of colors to improve the way things are displayed. The 256 available colors can be seen by running the 256color2.pl script that comes with xterm, or by running env TERM=xterm-256color emacs -nw -f list-colors-display The problem is deciding which colors to use. It would be great if someone that has a good taste/knows something about colors or maybe is a graphic artist could pick which colors to use. ls --color does not need that many distinct colors. It would be good if the colors picked are easily readable when text that uses them as foreground is displayed on a black background and a white background terminal. Below is the code from dircolors.hin that was changed so that it uses the escape sequences used by a 256 color terminal, the colors were not changed. It would be great if someone could figure out what colors to use... # Configuration file for dircolors, a utility to help you set the # LS_COLORS environment variable used by GNU ls with the --color option. # Copyright (C) 1996, 1999-2007 # Free Software Foundation, Inc. # Copying and distribution of this file, with or without modification, # are permitted provided the copyright notice and this notice are preserved. # The keywords COLOR, OPTIONS, and EIGHTBIT (honored by the # slackware version of dircolors) are recognized but ignored. # Below, there should be one TERM entry for each termtype that is colorizable TERM xterm-256color # Below are the color init strings for the basic file types. A color init # string consists of one or more of the following numeric codes: # Attribute codes: # 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed # Text color codes: # 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white # Background color codes: # 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white # Extended color codes for terminals that support more than 16 colors: # (the above color codes still work for these terminals) # Text color coding: # 38;5;COLOR_NUMBER # Background color coding: # 48;5;COLOR_NUMBER # COLOR_NUMBER is from 0 to 255. NORMAL 00 # global default, although everything should be something. FILE 00 # normal file DIR 00;38;5;4 # directory LINK 00;38;5;6 # symbolic link. (If you set this to 'target' instead of a # numerical value, the color is as for the file pointed to.) FIFO 48;5;0;38;5;3 # pipe SOCK 00;38;5;5 # socket DOOR 01;38;5;5 # door BLK 48;5;0;38;5;3;01 # block device driver CHR 48;5;0;38;5;3;01 # character device driver ORPHAN 01;05;38;5;7;48;5;1 # symlink to nonexistent file, or non-stat'able file SETUID 38;5;7;41# file that is setuid (u+s) SETGID 38;5;0;43# file that is setgid (g+s) STICKY_OTHER_WRITABLE 38;5;0;48;5;2 # dir that is sticky and other-writable (+t,o+w) OTHER_WRITABLE 38;5;4;48;5;2 # dir that is other-writable (o+w) and not sticky STICKY 38;5;7;48;5;4# dir with the sticky bit set (+t) and not other-writable # This is for files with execute permission: EXEC 00;38;5;2 # List any file extensions like '.gz' or '.tar' that you would like ls # to colorize below. Put the extension, a space, and the color init string. # (and any comments you want to add after a '#') # If you use DOS-style suffixes, you may want to uncomment the following: #.cmd 00;38;5;2 # executables (bright green) #.exe 00;38;5;2 #.com 00;38;5;2 #.btm 00;38;5;2 #.bat 00;38;5;2 # Or if you want to colorize scripts even if they do not have the # executable bit actually set. #.sh 00;38;5;2 #.csh 00;38;5;2 # archives or compressed (bright red) .tar 00;38;5;1 .tgz 00;38;5;1 .svgz 00;38;5;1 .arj 00;38;5;1 .taz 00;38;5;1 .lzh 00;38;5;1 .zip 00;38;5;1 .z 00;38;5;1 .Z 00;38;5;1 .dz 00;38;5;1 .gz 00;38;5;1 .bz2 00;38;5;1 .bz 00;38;5;1 .tbz2 00;38;5;1 .tz 00;38;5;1 .deb 00;38;5;1 .rpm 00;38;5;1 .jar 00;38;5;1 .rar 00;38;5;1 .ace 00;38;5;1 .zoo 00;38;5;1 .cpio 00;38;5;1 .7z 00;38;5;1 .rz 00;38;5;1 # image formats .jpg 00;38;5;5 .jpeg 00;38;5;5 .gif 00;38;5;5 .bmp 00;38;5;5 .pbm 00;38;5;5 .pgm 00;38;5;5 .ppm 00;38;5;5 .tga 00;38;5;5 .xbm 00;38;5;5 .xpm 00;38;5;5 .tif 00;38;5;5 .tiff 00;38;5;5 .png 00;38;5;5 .mng 00;38;5;5 .pcx 00;38;5;5 .mov 00;38;5;5 .mpg 00;38;5;5 .mpeg 00;38;5;5 .m2v 00;38;5;5 .mkv 00;38;5;5 .ogm 00;38;5;5 .mp4 00;38;5;5 .m4v 00;38;5;5 .mp4v 00;38;5;5 .vob 00;38;5;5 .qt 00;38;5;5 .nuv 00;38;5;5 .wmv 00;38;5;5 .asf 00;38;5;5 .rm 00;38;5;5 .rmvb 00;38;5;5 .flc 00;38;5;5 .avi 00;38;5;5 .fli 00;38;5;5 .gl 00;38;5;5 .dl 00;38;5;5 .xcf 00;38;5;5 .xwd 00;38;5;5 .yuv 00;38;5;5 # audio formats .aac 00;38;5;6 .au 00;38;5;6 .flac 00;38;5;6 .mid 00;38;5;6 .midi 00;38;5;6 .mka 00;38;5;6 .mp3 00;38;5;6 .mpc 00;38;5;6 .ogg 00;38;5;6 .ra 00;38;5;6 .wav 00;38;5;6 ___ 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
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
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
[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
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
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
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
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
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
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:
...
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
