On Sat, 21 Aug 1999 19:25:43 -0400, Daniel Johnson
<················@worldnet.att.net> posted:
>Peter da Silva <·····@baileynm.com> wrote in message
>···············@web.nmti.com...
>> In article <············@bgtnsc01.worldnet.att.net>,
>> Daniel Johnson <················@worldnet.att.net> wrote:
>> >VMS is a lot like Unix,
>>
>> Compared to what? The AS/400?
>
>Windows. :D
>
>But yes, the AS/400 too.
>
>As I understand it, if you want a GUI you run X-Windows on VMS.
>That's Unix like, isn't it?
>
>VMS is heavy on the command line, though it does work differently. But
>it's kinda Unix like there too. Sorta.
Something that I'm starting to find is that the documentation to
Common Lisp and its associated standards represent invaluable guidance
in situations where it is necessary to be concerned about
inter-platform portability.
For instance, when dealing with hierarchies of files, CL defines the
notion of a "pathname" which has the ability to join together the
notable components:
- Host
- Device
- Directory
- Name
- Type
- Version
so as to provide the actual name of a file.
I don't believe that there's *any* platform on which *all* of these
components are simultaneously meaningful; it nonetheless provides a
relatively neutral way of constructing a filename.
> (make-pathname :name "this" :type "tex")
#"this.tex"
> (make-pathname :directory '(:absolute "usr" "bin") :name "zsh")
#"/usr/bin/zsh"
Here's an attempt to access several files with a view to using the
same names on a Lisp Machine, a VAX, and a UNIX box.
(dolist (case '(:common :local))
(dolist (host '("MY-LISPM" "MY-VAX" "MY-UNIX"))
(print (make-pathname :host host :case case
:directory '(:absolute "PUBLIC" "GAMES")
:name "CHESS" :type "DB"))))
On my system, this returns the following six filenames:
#"/public/games/chess.db"
#"/public/games/chess.db"
#"/public/games/chess.db"
#"/PUBLIC/GAMES/CHESS.DB"
#"/PUBLIC/GAMES/CHESS.DB"
#"/PUBLIC/GAMES/CHESS.DB"
NIL
On a system that actually was hooked up to a VAX and a LispM, you
might get:
>> #P"MY-LISPM:>public>games>chess.db"
>> #P"MY-VAX:SYS$DISK:[PUBLIC.GAMES]CHESS.DB"
>> #P"MY-UNIX:/public/games/chess.db"
>> #P"MY-LISPM:>public>games>chess.db"
>> #P"MY-VAX:SYS$DISK:[PUBLIC.GAMES]CHESS.DB"
>> #P"MY-UNIX:/PUBLIC/GAMES/CHESS.DB"
=> NIL
Admittedly, some of this is a tad arcane, and I haven't had call to
use this in practice.
However, with DrScheme, which has an (admittedly less sophisticated
scheme for this), I *do* have code that runs happily both on Win32 and
on UNIX via resorting to:
(define SCHEMEPATH (getenv "HOME"))
(define COOKIEPATH (getenv "HOME"))
(if (eq? (system-type) 'windows)
(begin
(set! SCHEMEPATH (build-path SCHEMEPATH "code" "scheme"))
(set! COOKIEPATH (build-path COOKIEPATH)))
(begin
(set! SCHEMEPATH (build-path SCHEMEPATH "public_html" "tmp" "scheme"))
(set! COOKIEPATH (build-path COOKIEPATH "etc"))))
And I'll then open files, not by specifying a specific path, but as
follows:
(let
((JAR (open-input-file (build-path COOKIEPATH "linuxcookies"))))
(do stuff with JAR))
See how slashes of either direction never enter the visible code.
This may not be super-duper-portable to any conceivable platform, but
there certainly are places where abstracting things like this can
cheaply get you away from gratuitous non-portability.
I am utterly convinced that anybody that designs a new language
without looking back to Common Lisp and its design insights is likely
to waste a lot of time giving themselves grief.
The issue is *not* to replicate what they did, but rather:
- To see what design compromises they found they had to make;
- To see some of the elegant solutions;
- To see some of the places where it was ugly;
- To see what abstractions proved necessary.
In effect, the goal is to make sure you *don't* replicate all of the
effort that they went through to come up with the compromises they
arrived at.
--
Honuphrius is a concupiscent exservicemajor who makes dishonest
propositions to all.
········@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
········@news.brownes.org (Christopher B. Browne) writes:
> For instance, when dealing with hierarchies of files, CL defines the
> notion of a "pathname" which has the ability to join together the
> notable components:
> - Host
> - Device
> - Directory
> - Name
> - Type
> - Version
>
> so as to provide the actual name of a file.
>
> I don't believe that there's *any* platform on which *all* of these
> components are simultaneously meaningful;
[From foggy memory (not in a position to check right now...)]
On a Lisp Machine:
local|cdrom0:>sys>site>some-file.lisp.newest
^ ^ ^ ^ ^ ^ ^
host device dir dir name type version
[...Numerous logical-pathname examples yanked from HyperSpec snipped...]
> Admittedly, some of this is a tad arcane, and I haven't had call to
> use this in practice.
Had you, you would have become accutely aware of shortcomings within
the system as defined in the ANSI CL spec. Specifically, accessing
mixed cased Unix pathnames using the logical pathnames facility is
painful to do in a conformant manner. (Allegro CL violates the
standard and doesn't uppercase logical-pathname words and this makes
things much easier and more intuitive.)
I just a few minutes ago finished a reply to some guy that posted to
cmucl-help confused by all the casing cruft. (And by some rather ugly
CMU CL behavior I might add.)
Christopher
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
······@2xtreme.net (Christopher R. Barry) writes:
I didn't see ho this conversation started and am not going to go back and
look, but I happened to glance at this one post and wanted to interject
something about it:
> ········@news.brownes.org (Christopher B. Browne) writes:
>
> > For instance, when dealing with hierarchies of files, CL defines the
> > notion of a "pathname" which has the ability to join together the
> > notable components:
> > - Host
> > - Device
> > - Directory
> > - Name
> > - Type
> > - Version
> >
> > so as to provide the actual name of a file.
> >
> > I don't believe that there's *any* platform on which *all* of these
> > components are simultaneously meaningful;
>
> [From foggy memory (not in a position to check right now...)]
>
> On a Lisp Machine:
>
> local|cdrom0:>sys>site>some-file.lisp.newest
> ^ ^ ^ ^ ^ ^ ^
> host device dir dir name type version
This isn't right, though I can see why you're misremembering. The
syntax you describe is a true one, but is explained wrong.
The Lisp Machine observed a convention called "host colon". It
said that the first ":" ALWAYS terminated the host name. Some
hosts allowed devices, so to specify a device, you had to either
specify "host:device:" or if you didn't want to specify a host,
you could write ":device:" and the host would default.
Hosts were normally a token but could be namespace|host so that things
like "INTERNET|127.0.0.1" were valid host names, as were "CHAOS|12345".
Logically, both FEP and CDROM on the Lisp Machine were "hosts", not
devices, because hosts were really "file hosts", not "network hosts".
So FOO.COM|CDROM4: was a host spec, as was INTERNET|127.0.0.1|FEP0:
On a Macivory, which was an embedded machine, HOST: referred to the
hosting machine, so HOST:MACVOLUME0:DIR1:DIR2:FILE was a way of naming
a file in the local mac file system, while LOCAL:>dir1>dir2>file.name
was a way of naming a file in the local lisp machine file system, and
FEP0:>dir1>dir2>file.name was a way of naming a file in the local FEP
file system. This was not a "device" spec (FEP/LOCAL/HOST) because
it selected in each case a different filename syntax&semantics, not
just a different file within the same file system. Each of these was
logically a different file host.
The "device" specification was originally intended for things like
ITS, TOPS20, VMS, and others which had syntax like
PS:<FOO>X.Y.37 ; tops 20
SRC:<FOO>X.Y.37 ; tops 20
where PS and SRC were either primitive disk packs or specified by
named search lists (where each dir in the path list was annexed as
part of the conceptual toplevel of the dir, and where a write to that dir
wrote to the first dir in the list).
VMS was similar with
DSK:[A.B]FOO.BAR;3 ; vms
and ITS used
SECOND:COMMON;NAME TYPE ; its
DP:COMMON;LINS 37 ; its
[ITS used either a type or a version, but not both, and it used whitespace
as a separator, not the "." used by logical pathnmes.]
Note that in all these cases, the use of a device was not something that
changed the filename syntax, but rather just changed where in the given
logical file system a given file was sought. Note that in some cases,
such as
DMAR3:KMP;NOSUCH FILE ; its
the "device" would select a file in another file system (in this case,
the AR3 archive device on the DM machine). But that's just an issue of
abstraction, pretty much like the choice of Unix to wedge devices into
things like
/amd/foo/x/y
/dev/tty3
which don't really map clearly to devices unless you want to say that
something in the filename parser actually rcognizes and understands them
as
:device #<host foo> :directory '(:absolute "X") ...
or :device #<tty 3> :directory :unspecific
Incidentally, regarding the remark about all components being simultaneously
visible, it's surely the case that the Lisp Machine pathname model used
all parts, but rarely all in one pathname. The only file system that comes
to mind that used them all at once was VAX VMS:
host::device:[dir.dir.dir]name.typ;ver
There was even the possibility of
host::host::host::device:[dir.dir...]name.typ;ver
which was something of a problem since it represented a uucp-style
path-to-host rather than the absolute name of a host, and that caused
all kind of identity problems for lisp and other things that wanted
to manipulate host identity. (presumably if the host had a simple
name, it wouldn't need complex routing. but if it did need complex
routing, more than one routing might suffice and be opaque.) I don't
think it's only Lisp that found this problematic.