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(a)cs.dartmouth.edu> wrote: