From: K-mart Cashier on
Let's say I run the 'who' command on the z-shell. Like the following..

[cdalten(a)localhost ~]$ who
cdalten pts/1 2010-06-17 16:42 (:0.0)
cdalten pts/2 2010-06-13 12:49 (:0.0)
cdalten pts/3 2010-06-05 18:32 (:0.0)
cdalten pts/4 2010-06-18 17:49 (:0.0)
cdalten pts/5 2010-06-29 15:26 (:0.0)
cdalten pts/6 2010-07-05 14:21 (:0.0)
cdalten pts/8 2010-06-10 20:51 (:0.0)
[cdalten(a)localhost ~]$

From my understanding, the output from 'who' goes to the stdout. The
question is, how does this go to my terminal? Does the shell access
the stdout stream?


Chad
From: pk on
On Mon, 5 Jul 2010 14:25:30 -0700 (PDT) K-mart Cashier <cdalten(a)gmail.com>
wrote:

> Let's say I run the 'who' command on the z-shell. Like the following..
>
> [cdalten(a)localhost ~]$ who
> cdalten pts/1 2010-06-17 16:42 (:0.0)
> cdalten pts/2 2010-06-13 12:49 (:0.0)
> cdalten pts/3 2010-06-05 18:32 (:0.0)
> cdalten pts/4 2010-06-18 17:49 (:0.0)
> cdalten pts/5 2010-06-29 15:26 (:0.0)
> cdalten pts/6 2010-07-05 14:21 (:0.0)
> cdalten pts/8 2010-06-10 20:51 (:0.0)
> [cdalten(a)localhost ~]$
>
> From my understanding, the output from 'who' goes to the stdout. The
> question is, how does this go to my terminal? Does the shell access
> the stdout stream?

stdout is file descriptor 1 in the shell, and the "who" process which is
a child of the shell inherits it.
To have the text appear on the terminal, file descriptor 1 must be
connected to a terminal device, so when something is written to file
descriptor 1, it is really written to the terminal.

Under most OSs, to see which terminal your shell is using, you can use
the "tty" command:

$ tty
/dev/pts/4

I suppose you're wondering what kind of device a terminal is. The accurate
answer is *very* complicated; for the purpose of your question, it can be
seen as a device driver in the OS kernel that knows how to read and
interpret your keystrokes and to write to the output device, be it a real
physical terminal (eg connected to a serial port) or a virtual one (for
example a console or an xterm).

So to recap (and simplifying): "who" writes something to file descriptor 1,
using write(); write() is implemented in the kernel, which sees that the
supplied descriptor 1 is connected to a terminal, and thus delegates the job
of writing to the terminal device driver, which knows how to do that (this
last action can itself involve quite a lot of other steps,
especially in a graphic environment).
From: Rainer Weikusat on
K-mart Cashier <cdalten(a)gmail.com> writes:
> Let's say I run the 'who' command on the z-shell. Like the following..
>
> [cdalten(a)localhost ~]$ who
> cdalten pts/1 2010-06-17 16:42 (:0.0)
> cdalten pts/2 2010-06-13 12:49 (:0.0)
> cdalten pts/3 2010-06-05 18:32 (:0.0)
> cdalten pts/4 2010-06-18 17:49 (:0.0)
> cdalten pts/5 2010-06-29 15:26 (:0.0)
> cdalten pts/6 2010-07-05 14:21 (:0.0)
> cdalten pts/8 2010-06-10 20:51 (:0.0)
> [cdalten(a)localhost ~]$
>
> From my understanding, the output from 'who' goes to the stdout. The
> question is, how does this go to my terminal? Does the shell access
> the stdout stream?

The stdout stream is an abstract object provided by stdio (part of the
C-library). The basic idea behind that is that people who want to do
'input' and 'output' can deal with logical units of data (eg
'characters' or 'lines') while the library takes care of a sensible
buffering strategy for interaction with the OS. The 'stdout' file
descriptor is file descriptor #1 and the file description (in the
kernel) associated with that refers to the 'output channel' of your
'terminal'. Usually, this will be a pty slave, as in your output
above.
From: Tim Harig on
On 2010-07-05, K-mart Cashier <cdalten(a)gmail.com> wrote:
> Let's say I run the 'who' command on the z-shell. Like the following..
>
> [cdalten(a)localhost ~]$ who
> cdalten pts/1 2010-06-17 16:42 (:0.0)
> cdalten pts/2 2010-06-13 12:49 (:0.0)
> cdalten pts/3 2010-06-05 18:32 (:0.0)
> cdalten pts/4 2010-06-18 17:49 (:0.0)
> cdalten pts/5 2010-06-29 15:26 (:0.0)
> cdalten pts/6 2010-07-05 14:21 (:0.0)
> cdalten pts/8 2010-06-10 20:51 (:0.0)
> [cdalten(a)localhost ~]$
>
> From my understanding, the output from 'who' goes to the stdout. The
> question is, how does this go to my terminal? Does the shell access
> the stdout stream?

The shell inherets its stdout from login. login inhereted stdout from
getty. Getty opened the file descriptor, which is probably a pipe to the
kernel's tty subsystem. The shell leaves its stdout open when it
fork()/exec()s and the file descriptor remains open after the exec(). who
may then write to stdout as it would to any other file descriptor.
From: bsh on
“K-mart Cashier” <cdal...(a)gmail.com> wrote:
> ...
> From my understanding, the output from 'who' goes to the stdout. The
> question is, how does this go to my terminal? Does the shell access
> the stdout stream?

And a few nits:

> pk wrote:
> > stdout is file descriptor 1 in the shell....

Uh, no. While I have seen some official manpages of shells so
egregriously imprecise as to actually use the terms "file
descriptor," there simply are no FDs in shells. It is "File Unit
Numbers,"
being the 0..9 (and more in modern shells), which comprise the
high-level abstraction of file descriptors.


> Rainer Weikusat wrote:
> > [The shell access the stdout stream via] the stdout stream
> > [which] is an abstract object provided by stdio (part of the
> > C-library) ...

Well, uh, not _exactly_.

Stdio is not even used by ksh93, which implements an enhanced
stdio.o emulation library named sfio.o, which is statically
linked into that shell.

Additionally, the notion of streams exists only from BSD Unix and
its many descendents. I cannot exactly recall, but didn't at
least SVR2 and earlier utilize round-robin allocated clists for pipes?


> Tim Harig wrote:
> > The shell inherits its stdout from login. login inherits
> > stdout from getty....

Just an aside...

_Canonical_ getty has not been used for ages now in modern Unices.
Despite the similar naming, Linux agetty is a total rewrite that is
aware
of modern network protocols. Solaris has even completely abandoned
this
framework in preference to the ttymon facility.

Excuse the nit-picking!

=Brian