[lug] /dev/stderr

[D. Stimits]

Daniel Webb wrote:

>I know there's probably an easy answer for this, but I couldn't figure it out.
>Why does
>
>echo test >/dev/stderr
>
>print "test" on Dom0 but not on DomU in Xen?
>
>I finally figured out that
>
>echo test >&2 
>
>works on both (in bash).  What's the difference (other than that one works)?
>
>  
>

I don't know anything about Xen...but there is a common theme which is 
historically because of the C roots of any UNIX type system. Files 
opened in C have a numeric file descriptor associated with them. There 
are four descriptors, numbered 0 through 3, which are reserved for 
standardized system interaction (part of POSIX I believe). 0 is standard 
input, 1 is standard output, 2 is standard error (non-buffered), and 3 
is standard log (buffered version of standard error).

If you go to /dev, especially on newer udev style systems, you'll find 
/dev/stderr is really a symbolic link pointing at /proc/self/fd/2. That 
corresponds to a login device context which is different for different 
logins, e.g., two people with two separate logins can both point at 
descriptor 2 without interference, it associates with the login. The 
syntax of the different shells essentially create different escape 
notation to indicate descriptors. With bash, it's c-like, such as 2>&1. 
With tcsh, it doesn't understand that syntax, and you have to use 
something like "command |& tee file.log" to log both standard and and 
standard error; other times it understands /dev/stderr by name, which 
could just as easily be pointed at another descriptor.

So...if Xen is different, it means that either you are using a different 
shell, or the descriptors are aliased in some other way (sadly, I've 
never used Xen). All of them are shortcuts to pointing at descriptor 0 
through 3. The /dev files themselves are all really kernel drivers and 
not really files, so perhaps the Xen kernel has a modified driver.

D. Stimits, stimits AT comcast DOT net