[vox-tech] quick, stupid bash question
ok, i should know this... this redirects stderr to stdout and pipes the whole thing to grep: strace lsof 21 | grep System how do i grep *just* stderr and not both stderr and stdout? pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
On Wed, May 29, 2002 at 11:11:19AM -0700, Peter Jay Salzman wrote: ok, i should know this... this redirects stderr to stdout and pipes the whole thing to grep: strace lsof 21 | grep System Try something like: strace lsof 21 1 /dev/null | grep (For some reason, the other order (21 at the end) doesn't work) -bill! ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
begin nbs [EMAIL PROTECTED] On Wed, May 29, 2002 at 11:11:19AM -0700, Peter Jay Salzman wrote: ok, i should know this... this redirects stderr to stdout and pipes the whole thing to grep: strace lsof 21 | grep System Try something like: strace lsof 21 1 /dev/null | grep ok, haven't tried this, but this looks to me like: put stderr into stdout redirect stdout (and therefore stderr) into /dev/null pipe stdout (which should be null) to grep. yet it works. where is my thinking going wrong? pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
On Wednesday 29 May 2002 11:29 am, you wrote: begin nbs [EMAIL PROTECTED] On Wed, May 29, 2002 at 11:11:19AM -0700, Peter Jay Salzman wrote: this redirects stderr to stdout and pipes the whole thing to grep: strace lsof 21 | grep System Try something like: strace lsof 21 1 /dev/null | grep ok, haven't tried this, but this looks to me like: put stderr into stdout redirect stdout (and therefore stderr) into /dev/null pipe stdout (which should be null) to grep. yet it works. where is my thinking going wrong? here's my reading of the man page. redirects are processed L-R. 21 *duplicates* the stdout file descriptor and sends stderr there. then stdout (the original) is redirected to /dev/null. so this is what you needed. reversing the order sends stdout to /dev/null, *then* duplicates the stdout file descriptor and sends stderr there, so it too ends up in /dev/null. not what you wanted. shawn. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
On Wed, May 29, 2002 at 11:29:29AM -0700, Peter Jay Salzman wrote: begin nbs [EMAIL PROTECTED] strace lsof 21 1 /dev/null | grep ok, haven't tried this, but this looks to me like: put stderr into stdout redirect stdout (and therefore stderr) into /dev/null pipe stdout (which should be null) to grep. The order of operation of file operators is right to left. So the first operation | grep spawns a copy of grep on the stdout of a future output of a new pipe. The second 1 /dev/null takes stdout and throws it away. The third 21 takes stderr and redirects it to stdout. The command line you are looking for if you want stderr grepped and stdout to still be displayed is some variant of this: ( strace ls -R / 21 13 | grep open; ) 31 (which will show you each open call and the output that ls prints after each, alternating... sample output below, kinda cool). here is a breakdown of the command-line above in order of operation... = ( ... ) 31 open a file descriptor 3 and attach it to my current stdout. ( ... ) run the following in a subshell ... | ... run the thing on the left and direct it's stdout into the thing on the right. grep open look for the word open in my stdin. 13 redirect stdout to file descriptor 3. 21 redirect stderr to stdout. strace ls -R / strace the output of ls -R / = Note that the sample command above is just a sample, if you really wanted all the times strace detected an open call then give strace the option -e open ... which is much better. sample output from the new command: = msimons@star:~/debian$ ( strace ls -R / 21 13 | grep open; ) 31 open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or directory) open(/etc/ld.so.cache, O_RDONLY) = 4 open(/lib/librt.so.1, O_RDONLY) = 4 open(/lib/libc.so.6, O_RDONLY)= 4 open(/lib/libpthread.so.0, O_RDONLY) = 4 open(/dev/null, O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) open(/, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 open(/etc/mtab, O_RDONLY) = 4 open(/proc/meminfo, O_RDONLY) = 4 /: bincdrom etc ibm2lost+found proc share tmp vmlinuz boot cdrom0 floppy initrd mnt root test usr vmlinuz.old brick dev homelib opt sbin thor var open(/bin, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 /bin: arch dd fuser ls netstatsedtruezforce ashdf grep lspci pidof setserial umount zgrep bash dirgunzipmkdir ping sh uname zless catdmesg gzexe mknod ps sleep uncompress zmore chgrp dnsdomainname gzip mktemp pwdstty vdirznew chmod echo hostname morerbash su zcat chown ed kill mount readlink sync zcmp cp egrep lnmt rm tarzdiff cpio false loadkeys mt-gnu rmdir tempfile zegrep date fgrep login mv run-parts touch zfgrep open(/boot, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 /boot: System.map-2.4.18boot-menu.b boot.b map System.map-2.4.18-bf2.4 boot-text.b chain.b os2_d.b boot-bmp.b boot.0200config-2.4.18vmlinuz-2.4.18 boot-compat.bboot.0801config-2.4.18-bf2.4 vmlinuz-2.4.18-bf2.4 = ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
On Wednesday 29 May 2002 12:18 pm, you wrote: On Wed, May 29, 2002 at 11:29:29AM -0700, Peter Jay Salzman wrote: begin nbs [EMAIL PROTECTED] strace lsof 21 1 /dev/null | grep ok, haven't tried this, but this looks to me like: put stderr into stdout redirect stdout (and therefore stderr) into /dev/null pipe stdout (which should be null) to grep. The order of operation of file operators is right to left. [snip] The order of redirects is left to right. shawn. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
On Wed, May 29, 2002 at 12:32:45PM -0700, Shawn P. Neugebauer wrote: On Wednesday 29 May 2002 12:18 pm, you wrote: The order of operation of file operators is right to left. The order of redirects is left to right. Shawn, That is correct. I've just done some tests and things are operated on left to right, my understanding of how things operate is being revised... Thanks, Mike man bash: # REDIRECTION #Before a command is executed, its input and output may be redirected #using a special notation interpreted by the shell. Redirection may #also be used to open and close files for the current shell execution #environment. The following redirection operators may precede or #appear anywhere within a simple command or may follow a command. #Redirections are processed in the order they appear, from left to #right. [...] #Note that the order of redirections is significant. For example, the #command # # ls dirlist 21 # #directs both standard output and standard error to the file dirlist, #while the command # # ls 21 dirlist # #directs only the standard output to file dirlist, because the stan #dard error was duplicated as standard output before the standard out #put was redirected to dirlist. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
On Wed, May 29, 2002 at 03:18:08PM -0400, [EMAIL PROTECTED] wrote: On Wed, May 29, 2002 at 11:29:29AM -0700, Peter Jay Salzman wrote: begin nbs [EMAIL PROTECTED] strace lsof 21 1 /dev/null | grep ok, haven't tried this, but this looks to me like: put stderr into stdout redirect stdout (and therefore stderr) into /dev/null pipe stdout (which should be null) to grep. The order of operation of file operators is right to left. On Wed, May 29, 2002 at 12:32:45PM -0700, Shawn P. Neugebauer wrote: The order of redirects is left to right. Based on Shawn's comment I've done some tests and operation is very much left to right like he says. Now I have a better understanding of how dup2 works... but I hope I really don't need to use this anytime soon. ( strace ls -R / 21 13 | grep open; ) 31 Since I'm revising most of this email I would now recommend the following... ( exec 31 42; strace ls -R / 21 13 | grep open 14 ) It does a similar thing to the one above... but has the nicer property of after the ')' the grepped output from strace is still going to stderr and ls going to stdout, which the first version doesn't do (they are both going to stdout). This way you can redirect view them correctly or split them into other places later. strace lsof 21 1 /dev/null | grep So the first operation | grep spawns a copy of grep on the stdout of a future output of a new pipe. The second 1 /dev/null takes stdout and throws it away. The third 21 takes stderr and redirects it to stdout. In the parent A - '|' The first thing that happens is a pipe (see pipe(2) manpage) because '|' appears in the command. This call creates two fds (3 and 4) which are attached together... and is to handle communication between strace and grep. Fork child 1 A - '|' The child closes fd 3, which is for pipe reading. invokes dup2(4, 1) which attaches the fd 1 to the output channel on the pipe and closes fd 4. B - '21' Invoke the dup2(2, 1) system call, which closes the old stderr (which was going to the user's terminal) and makes fd 2 (point at the same place as stdout, which in this case can be thought of as the user's terminal). C - '1 /dev/null' Open /dev/null for writing, then dup2(X, 1) which attaches a new 'stdout' to the /dev/null file, and close(X). D - then exec the command strace ... Back in the parent A - the parent closes fd 4, since it is meant for writing by child 1. E - the parent forks another child A - the parent closes fd 3, since it is meant for reading by child 2. (there appears to be a bug in bash that the parent of a pipe creation closes both the input and output channels twice of a pipe twice). Fork child 2 F - Call dup2(3, 0) which attaches the input pipe fd 3 to this processes stdin. G - then exec the command grep ... Here are the actual calls captured by strace... the letters in the first column are supposed to help understand which step above is being processed at the time. in one window = msimons@star:~$ echo $$ 693 msimons@star:~$ strace ls / 21 1 /dev/null | grep open = in another window msimons@star:~$ strace -f -p 693 -e execve,close,dup2,open,fork A [pid 683] pipe([3, 4])= 0 [pid 693] fork() = 31806 A [pid 31806] close(3)= 0 A [pid 31806] dup2(4, 1) = 1 A [pid 31806] close(4)= 0 B [pid 31806] dup2(1, 2) = 2 C [pid 31806] open(/dev/null, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 C [pid 31806] dup2(3, 1) = 1 C [pid 31806] close(3)= 0 D [pid 31806] execve(/usr/bin/strace, [strace, ls, /], [/* 27 vars */]) = 0 A [pid 693] close(4)= 0 A* [pid 693] close(4)= -1 EBADF (Bad file descriptor) E [pid 693] fork() = 31808 A [pid 693] close(3)= 0 A* [pid 693] close(3)= -1 EBADF (Bad file descriptor) F [pid 31808] dup2(3, 0) = 0 F [pid 31808] close(3)= 0 G [pid 31808] execve(/bin/grep, [grep, open], [/* 27 vars */]) = 0 ( strace ls -R / 21 13 | grep open; ) 31 here is a correct breakdown of the command-line above in order of operation... = - fork a child_A for '31' - in child_A - dup2(1, 3) for '31' - create pipe for '|' - fork child_B for for 'strace' - close pipe out channel (twice) for '|' - fork child_C for grep - close pipe in channel (twice) for '|' - in child_B (strace) - close pipe input channel for '|' - attach stdout to pipe output channel, then close pipe out channel fd 5 for '|' - attach stderr to stdout for '21' - attach stdout to fd 3 for '31' - exec strace... - in child_C (grep) - attach stdin to pipe input channel,
Re: [vox-tech] quick, stupid bash question
begin [EMAIL PROTECTED] [EMAIL PROTECTED] On Wed, May 29, 2002 at 03:18:08PM -0400, [EMAIL PROTECTED] wrote: On Wed, May 29, 2002 at 11:29:29AM -0700, Peter Jay Salzman wrote: begin nbs [EMAIL PROTECTED] strace lsof 21 1 /dev/null | grep ok, haven't tried this, but this looks to me like: put stderr into stdout redirect stdout (and therefore stderr) into /dev/null pipe stdout (which should be null) to grep. The order of operation of file operators is right to left. On Wed, May 29, 2002 at 12:32:45PM -0700, Shawn P. Neugebauer wrote: The order of redirects is left to right. Based on Shawn's comment I've done some tests and operation is very much left to right like he says. Now I have a better understanding of how dup2 works... but I hope I really don't need to use this anytime soon. (snip) this was a very valuable thread -- i'm very glad i asked the question and even more glad people riffed with the theme. but the actual answer is completely unacceptable. i can't believe that this is so complicated under bash! i really wish that the bash developers would so something like: strace foo 2| grep bar i see this as a bash deficiency. :( but it _was_ a great lesson! pete ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] quick, stupid bash question
On Wed, May 29, 2002 at 11:11:19AM -0700, Peter Jay Salzman wrote: how do i grep *just* stderr and not both stderr and stdout? On Wed, May 29, 2002 at 02:40:25PM -0700, Peter Jay Salzman wrote: but the actual answer is completely unacceptable. You didn't ask for 4 characters or less... ;) i can't believe that this is so complicated under bash! Be glad it is at least it is possible in bash, if you wanted it. Unless things have changed that is not even possible in the c shell variants (*). What you are asking for is a very complicated (2) operation... Later, Mike *: I welcome any csh people to correct me if I'm wrong, without using temporary files, the '-o' option to strace, or fancy /dev or /proc entries... filter through grep the stderr of strace while leaving stdout intact. 2: Even if you implemented in C you would be making like 13 system calls (1 pipe, 2 fork, 2 exec, 5 dup2, 3 close) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
