[TUHS] Dash options

[George Michaelson]

I had an interesting conversation with people years gone by about the
logistical benefits or hindrances of being explicit about device in
the path, which vax/vms did sys$system: type statements. I'm now fully
acculturated to not want it, but in a world where the operating system
did less for you, explicitly flagging the device a la PIP (yes,
Decisms) had some basis in reality: you said what you expected the
device level events were, to achieve the outcome.

So distinguishing device semantically, for some people, reductionists,
worked. masking the device, by intruding (sorry, bad word) a path as a
blinding, anonymous namespace, with device inferred.. that was an
inferential leap. I think newcastle connection went further embedding
/.../ as a denotation of network-jump to move to other devices. WIsh
that had taken off, fitted the . and .. semantic model nicely inside
the /path/to/thing

I used at least one OS which had path.to.thing via dots, and rather
oddly, only DESCENT. you couldn't walk backwards. so directory descent
in the JCL was possible, but to go up one level you had to go down
from the top, N-1 path elements from position N. Bizarre, suggesting
it wasn't a doubly linked list?

switches, flags, options, three words for the same thing...

a lot of this stuff was being defined in a time when we still used
languages where file IO was bound to IO numbers and about batch entry
bindings where the 1..n range of devices was literally which "thing"
fed the input or output stream, not just an ioctl() convenience
binding. I never entirely got why in my fortran I was using IO 2 so
much. what happened to 0 and 1?

or the pascal file pointer. what an odd construct that was looking
backwards from more abstracted file position, but then think what
seek() is actually doing..

-G

On Wed, Nov 29, 2017 at 11:23 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Early on, when multics was understood to have
> one big, segemented address space, it was expected
> that PL/I name qualification ($) would serve to address
> segments. I do not know whether that idea was
> actually implemented.
>
> Doug