Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.26/text0050.txt

Text File | 1992-02-21 | 3.8 KB | 98 lines

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> Jason Zions writes:
> > There is an expectation that one can open() a local
> > file, a remote file, a real-time message queue, a secure file, and a named
> > network connection, all with a function whose name is open() and has some
> > common parameters.

> *Why*?

Because the more things you can access via the open() system call, the more
powerful an environemnt you have. For example, older programs become able to
access more data sources and sinks without modification or recompiling.

For a concrete example, in AmigaDOS this expectation is taken further: you
can relatively easily create new objects that look like files, and pass
textual information to them in the open call. In general, "DEV:path" passes
the string "path" unmodified to the device "dev". This allows such nice
capabilities as:

    CON:0/0/640/200/Debug Window/WAIT

Which opens a (NTSC) full-screen window, titled debug window, which you can
print text strings to and which will hang around after close until you click
on the close box. Another example:

    APIPE:ps -ef

Reading from this file will give you the result of the "ps -ef" command. you
don't have to have the program calling popen with some syntaxes and not others,
you don't have to remember that some programs allow this and others don't. in
UNIX I can open a pipe, in various programs, by doing:

    :r !ps -ef
    open "ps -ef" pr
    ~|ps -ef

> Let's move on to the supposed simplicity of super-open() for programmers.
> Since when was it difficult to create, e.g., network connections with the
> BSD syscalls?

Not very, but it's hard to create one from your ".mailrc" file.

> Competent UNIX programmers write tools which stick to stdin, stdout, and
> stderr. Only a few specialized tools---cat, sh, inetd

A few specialised tools? cc, mail, diff, just off the top of my head. Not
everything is, or can be, a filter.

> also bloating the kernel for something which the vast majority of
> programs will never use.

The challenge is on... let's look though my System III (because it's older
and therefore more "pure") Xenix manual:

accton, awk, bdiff, bfs, chgrp, chmod, chown, cmp, comm, cp, cron, cu, diff,
diff3, ed, finger, join, ln, look, lpq, lpr, mail, make, more (and less),
mv, nohup, pr, rm, sdiff, tee, touch, and uucp (etc).

All these commands operate on, require, or provide access to named files in
ways that bare file descriptors can not easily be wedged in. This list also
brings up the question of security: all UNIX security is based on access to
files. Adding new ways to create file descriptors involves duplicating all
this security and causing a separate source of kernel expansion.

> Finally, let's consider super-open()'s advantages for users. Certainly
> it'd be nice for a user to be able to type something like, say,

>    % cat #[e-mail]

More like "cat /dev/telnet/athena.mit.edu/13".

> (disclaimer: I haven't given any thought to a good notation for this)
> and have cat read from a TCP socket connected to port 13 on athena. Does
> this mean that open() should support such notation? No!

I agree, in a way. It's not "open" that's doing the work... it's the virtual
file system mounted on /dev/telnet. If you rely in the shell to figure this
out and convert the call to something like

    + telnet athena.mit.edu 47| cat /dev/fd/47

then what do you do when you want to access this from "awk", or create a
(sumbolic) link to it called "/dev/weather"? And have this converted to a
link to a serial port with a heathkit WWV receiver when the network's down...

UNIX is more than just the shell.
--
-- Peter da Silva
-- Ferranti International Controls Corporation
-- Sugar Land, TX  77487-5012;  [phone]
-- "Have you hugged your wolf today?"


Volume-Number: Volume 26, Number 52