begin quoting Ralph Shumaker as of Sat, Mar 29, 2008 at 09:55:37AM -0700:
[snip]
> I don't know what programming or scripting language we're talking about
> here. Let's just say that I am almost completely unfamiliar with what
> scripting or programming language is needed for stdin, stdout, and
> stderr. I think someone said stdin is 0, stdout is 1, stderr is 2, and
> more numbers are available, but with no standard names. Stewart
> suggested possibly petitioning POSIX for a label of stdstatus, let's
> assume they agree and make that 3.
>
> Could someone please show me, as simply as possible, an example script
> or program that uses each of these? I don't know enough about it to
> envision it.
-----------------------------------------------------------------------------
#!/bin/psuedoscript
#
# Find all of the files with copyright notices
foreach f in $( find . -type f -iname '*.jpg' ) do
print -stdstatus "Processing file $f"
if ( ! -r $f ) then
print -stderr "Cannot read file $f"
fi
readjpgcmt $f | grep -i "copyright"
if ( $status ) then
print -stdout "$f"
fi
rof
-----------------------------------------------------------------------------
> And just for grins, let's say the author wants more output channels for
> whatever reason. Would he likely choose higher numbers than the next
> available numbers (just in case POSIX later decides to add more
> stdxxx)? Or would he likely use the next numbers available since stdin,
> stdout, and stderr have been the only ones for many many many years?
Bourne shell apparently allows this.
Consider:
-----------------------------------------------------------------------------
$ cat fdtest.c
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char **argv ) {
FILE *stdstatus;
fprintf( stdout, "stdout\n");
fprintf( stderr, "stderror\n");
stdstatus = fdopen( 3, "w" );
if ( stdstatus == NULL ) {
if ( argc > 1 ) fprintf( stderr, "Can't open file descriptor
#3\n");
return EXIT_FAILURE;
}
fprintf( stdstatus, "stdstatus\n");
return EXIT_SUCCESS;
}
$
-----------------------------------------------------------------------------
> Let's say that a user invokes that program. What will he see?
>
> Let's say that a user invokes that program with simple redirection to a
> file. What will he see?
-----------------------------------------------------------------------------
lancre> !gcc
gcc -o fdtest fdtest.c
lancre> ./fdtest
stdout
stderror
lancre> ./fdtest -v
stdout
stderror
Can't open file descriptor #3
lancre> sh
$ ./fdtest
stdout
stderror
$ ./fdtest -v 3>&1
stdout
stderror
stdstatus
$ ./fdtest -v 3>&1 1>out.1 2>out.2
stdstatus
$ cat out.1
stdout
$ cat out.2
stderror
$
-----------------------------------------------------------------------------
> I've had limited experience with this when I did "du -a > ~/du-a" and
> got what I assume is stdout in the file but what I assume is stderr
> still on the screen. It seems like, without redirection, both stdout
> and stderr outputs went to screen, but redirection split them. Is this
> observation correct?
Yup.
> I've seen fancy ~"> 2&"~ or whatnot (couldn't quote it accurately from
> memory since I never really understood it). Is there some resource that
> could explain such things, preferably simple explanations designed for
> total NOOBS?
1, 2, 3, etc. are file descriptors.
#>filename will redirect file descriptor # to the file filename
The file &# is special -- that's a target file descriptor, so when
you see A>&B (in a bourne shell), where A and B are numbers, that's
saying "point A to wherever B is right now".
-----------------------------------------------------------------------------
$ ./fdtest > out.1 2>&1
$ ./fdtest 2>&1 > out.2
stderror
$ cat out.1
stderror
stdout
$ cat out.2
stdout
$
-----------------------------------------------------------------------------
If you really wanted to, you could swap stdout and stderr...
-----------------------------------------------------------------------------
$ ./fdtest
stdout
stderror
$ ./fdtest > /dev/null
stderror
$ ./fdtest 2> /dev/null
stdout
$ ./fdtest > /dev/null 2>&1
$ ./fdtest 3>&1 1>&2 2>&3 > /dev/null
stderror
stdstatus
$
-----------------------------------------------------------------------------
--
All code in this post is released into the public domain. Duh.
Stewart Stremler
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
