stimits at comcast.net
Mon Dec 11 21:50:17 MST 2006
Daniel Webb wrote:
>I know there's probably an easy answer for this, but I couldn't figure it out.
>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
More information about the LUG