About the "principle of least surprise"
Olin Sibert
takes a cheap shot:
> In article <1993091007...@world.std.com> Bob_Fr...@frankston.com writes:
> > One of the guiding principles of Multics was the "principle of least
> > surprise". You should be able to work with the system and be adventurous
> > without getting hurt [too] badly.
>
> Random crashes because of a bug in a program you invoked five minutes ago
> are not surprising?
This is hardly an accurate characterization of the Multics user
interface. While the persistent address space does help make such
behaviour possible particularly when writing new programs, it's hardly
common (assuming, by "crash", you really mean "user-visible program
failure during a login session"; real crashes are FAR less likely).
Indeed, properties of the hardware's addressing architecture actually
protect against it to a large degree.
I've had enough years of experience with both to reach a conclusion
about which of Multics or UNIX is more plagued by programs that cause
"random crashes", whether right now or five minutes later. It's not a
comparison in which UNIX systems fare particularly well.
--
Olin Sibert |Internet: Sib...@Oxford.COM
Oxford Systems, Inc. |UUCP: uunet!oxford!sibert
Robert Coren
|> In <CD7yp...@sugar.NeoSoft.COM>, pe...@NeoSoft.com (Peter da Silva)
|> takes a cheap shot:
|>
|> > In article <1993091007...@world.std.com> Bob_Fr...@frankston.com writes:
|> > > One of the guiding principles of Multics was the "principle of least
|> > > surprise". You should be able to work with the system and be adventurous
|> > > without getting hurt [too] badly.
|> >
|> > Random crashes because of a bug in a program you invoked five minutes ago
|> > are not surprising?
|>
|> This is hardly an accurate characterization of the Multics user
|> interface. While the persistent address space does help make such
|> behaviour possible particularly when writing new programs, it's hardly
|> common (assuming, by "crash", you really mean "user-visible program
|> failure during a login session"; real crashes are FAR less likely).
|> Indeed, properties of the hardware's addressing architecture actually
|> protect against it to a large degree.
But, to be fair, there's an intermediate possibility on Multics, which
could be pretty serious, and ferociously difficult to debug: if your
program scribbles on the base of the stack, the chances are that the
process (meaning the whole login session, in practice) is likely to
either die or become so screwed up as to require euthanasia. If it
scribbles in the linkage area, it can in fact have unforeseen and
apparently inexplicable down-the-road effects.
On the other hand, if your Multics program references through a null
or otherwise invalid pointer, you've got a good chance at getting an
intelligible error message, and a preserved stack to debug, without
having to wait endless seconds for your entire address space to be
written to a file with a highly-descriptive guaranteed-non-unique
name.
Peter da Silva
> In <CD7yp...@sugar.NeoSoft.COM>, pe...@NeoSoft.com (Peter da Silva)
> takes a cheap shot:
It's not intended as a cheap shot. It's a problem I've seen time and time
again in a number of operating systems, where performance or functionality
has been used as a reason for tearing down a wall of memory protection
between unrelated (in terms of authorship or trust) execution domains.
MS-DOS. MacOS. Windows. AmigaDOS. These are the classic examples of this
problem, of course, and here the consequences show up far more obviously
and blatantly than in Multics.
> This is hardly an accurate characterization of the Multics user
> interface. While the persistent address space does help make such
> behaviour possible particularly when writing new programs, it's hardly
> common (assuming, by "crash", you really mean "user-visible program
> failure during a login session"; real crashes are FAR less likely).
Yes, I mean 'user-visible program failure during a login session'.
One point you have to consider is that in Multics you had far fewer
opportunities for this sort of problem than in the systems I named
above. Fewer than in UNIX, for that matter. Why? A far smaller user
base, and no pool of potentially buggy shrinkwrapped programs.
Now I'm quite happy to believe that the greater protection afforded
by UNIX led to a larger number of buggy programs. I'm quite happy to
admit that there are a shitload of dumb bugs that have long worn out
their welcome: awk's line length limits, for example. However I can
not be persuaded that, simply because this hole remained less than
critical in the comfortable environment Multic was blessed with, it's
any less a problem. Nor that it's one that wouldn't have bitten people
badly had Multics taken off.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Hefur thu fadhmadh ulfinn i dag?
'U`
"Det er min ledsager, det er ikke drikkepenge."
Michael Padlipsky
So what you mean IS meaningless in the context of a DESIGN principle,
since it applies to accidents of implementation, and the whole 'thread'
is irrelevant to user interface issues, which it purported to be about.
cheers, map
Peter da Silva
I don't follow. The design principle I'm talking about is where you execute
multiple user-visible commends within the same execution context, in such a
way that a command can damage the environment in such a way that subsequent
commands fail to complete successfully and predictably.
If you can't make command start-up cheap enough, because you have to create
a new execution context for each command, the user interface is going to of
necessity be different than if you can just branch to an existing routine.
As an example in another system: program start up and user response is faster
under AmigaDOS than under X, but under AmigaDOS there is this inherent
uncertainty as to whether a program has broken something. You only learn
through trial and error not to run this or that utility because it breaks
things later on.
Overall, the Amiga user interface is superior to X, because there's no way you
can *make* X as responsive within any reasonable budgetary constraints even
seven years later. X, however, has the sterling quality of robustness: it's
difficult for a non-malicious program to break things such that the user's
work environment is quietly addled. (yes, it's possible for a malicious program
to do some nasty things... I'm not entirely happy with X myself)
I don't believe that the implementation can be separated so clearly from the
design. The basic assumptions you make in designing the implementation are
going to change what you can do with the interface. After all, without any
implementation constraints your ideal user interface works like:
"I'd like a glass of water, Hal."
"Here you are, Dave."
"How many questions have I asked you in the past week?"
"Two thousand, three hundred, and fourteen... including that one."
--
Peter da Silva. <pe...@sugar.neosoft.com>.
Paul Dickson
>their welcome: awk's line length limits, for example. However I can
>not be persuaded that, simply because this hole remained less than
>critical in the comfortable environment Multic was blessed with, it's
>any less a problem. Nor that it's one that wouldn't have bitten people
>badly had Multics taken off.
One thing that hasn't been mentioned so far is the difficulty of
overwriting the stack in Multics PL/1. Clobbering info on the stack
is more difficult than it is in C, although its still possible to do
it.
Peter da Silva
> One thing that hasn't been mentioned so far is the difficulty of
> overwriting the stack in Multics PL/1. Clobbering info on the stack
> is more difficult than it is in C, although its still possible to do
> it.
I'll grant you that. II've been involved in translating a bunch of PL/I code
to C (though C++ would probably be better... damn, have I actually found a
use for C++?), and PL/I is a much higher level language.
I think it's a damn shame that the only high level language that's nearly
as easy to write really portable code in as C, and with enough implementations
out to make it worthwhile, is Fortran. I've tried using Modula, but I can
barely manage to write code that ports from one compiler to another on the
same platform! The basic I/O library isn't even standardised! And DEC PL/I
and Unisys PL/I and IBM PL/I might as well have been different languages,
so far as I can tell by the code I've seen.
Paul Stachour
>One thing that hasn't been mentioned so far is the difficulty of
>overwriting the stack in Multics PL/1. Clobbering info on the stack
>is more difficult than it is in C, although its still possible to do
>it.
I wrote PL/I programs on Multics for about 5 years.
I **NEVER** had an error in any program that I wrote
that resulted in the stack-frame of any other execution-unit
(other than the block or subprogram that was executing)
being over-written.
I now write in C. I make much greater effort to avoid
over-writing, because the likelihood of a program-fault
on an over-write is much lower; thus the program keeps going,
with likely wrong results, untill the crash that is hard to debug.
In addition, the *WALL* between executing programs meant that
wild go-to's didn't have the effect of strange loss-of-control.
Sure, I know that C (on unix machines, but not on most others)
has the process mechanism for separation. However, for me, the
*WALL* was good enough; I never wound up going by it. Sure would
be neat to have a *WALL* between programs on MS-DOS and similar
OSes.
..Paul
--
Paul Stachour SCC, 2675 Long Lake Road
stac...@sctc.com Roseville, MN 55113
[1]-(612) 628-2782
Alan Bawden
stac...@sctc.com (Paul Stachour) writes:
In addition, the *WALL* between executing programs meant that
wild go-to's didn't have the effect of strange loss-of-control.
Sure, I know that C (on unix machines, but not on most others)
has the process mechanism for separation. However, for me, the
*WALL* was good enough; I never wound up going by it. Sure would
be neat to have a *WALL* between programs on MS-DOS and similar
OSes.
Hmmm.. I'm sure I remember talk of a "wall" back when many of my friends
were Multing, but I can't now reconstruct anything about what it was all
about. I seem to recall that the way the wall worked was a subject of some
controversy -- some aspect of its behavior was changed and then changed
back a few years later, or something like that.
Perhaps this would be a good topic for someone to compose one of those
informative little retrospective essays: "What was the Wall?" Any takers?
BTW, another environment in which everthing took place in the same address
space was the Lisp Machine environment. And yes, it did occasionally
happen that some errant program would screw something up so badly that the
entire operating environment would be lost -- but this was really rare.
I'm not sure what all the factors were that made it so rare. Certainly an
important factor was having dynamic type checking to prevent most kinds of
"scribbling in memory" errors.
--
Alan Bawden Al...@LCS.MIT.EDU
MIT Room NE43-538 (617) 253-7328
545 Technology Square
Cambridge, MA 02139 06BF9EB8FC4CFC24DC75BDAE3BB25C4B
Olin Sibert
program error), a condition handler (usually default_error_handler_)
is activated to handle the condition. In the interactive environment,
for most conditions, this results in suspending the executing program
and establishing a new command listener. From that point, one can issue
arbitrary new commands to perform other functions, abandon the suspended
execution, start a debugger, restart the suspended execution, or request
that the suspended program return to a specified "program_interrupt"
point (this last typically for interactive subsystems, which would come
back and prompt for a new subsystem request).
[This mechanism is rightly criticized as being none too friendly for
unsophisticated users, who don't usually want all those choices, and
would usually be happy to abandon the program they interrupted. In a
sense, Multics always acts like one's typed ^Z, regardless of why the
interruption occurred.]
The only thing I can think of that could be called a "wall" in Multics
environment is the stack frame owned by default_error_handler_$wall,
which serves only to intercept detected error conditions (e.g.,
overflow, null pointer de-reference) and not let them propagate to still
earlier stack frames. This isn't a "wall", though, in any important
sense--it's just one of many possible implementation mechanisms to
localize the semantics of PL/I conditions.
In <1993Sep19....@sctc.com>, stac...@sctc.com (Paul Stachour) writes:
> In addition, the *WALL* between executing programs meant that
> wild go-to's didn't have the effect of strange loss-of-control.
This isn't really an accurate characterization: a non-local go-to will
in fact bypass the wall, unwinding stack frames as it goes (this is, to
a first approximation, how "release" works). Wild go-tos in Multics are
rare for different reasons: first, the target must be an executable
program segment, not random data; second, Multics pointers are typed (as
pointers) such that much random data (but not, alas, a word of all
zeros) will immediately fail if used as a pointer; and third, a
non-local go-to must name a valid target stack frame as well as a
location in code, and a fair amount of validation is done on that
assumption in the process of attempting the go-to.
Barry Margolin
>BTW, another environment in which everthing took place in the same address
>space was the Lisp Machine environment. And yes, it did occasionally
>happen that some errant program would screw something up so badly that the
>entire operating environment would be lost -- but this was really rare.
>I'm not sure what all the factors were that made it so rare. Certainly an
>important factor was having dynamic type checking to prevent most kinds of
>"scribbling in memory" errors.
I believe the reason is the use of a high-level language. The Lisp Machine
does have facilities for direct memory/hardware manipulation, but they are
used very rarely outside the bowels of the OS. Everything else is done in
terms of high-level objects. Lisp's automatic memory management is another
important factor -- one of the most difficult types of problems to debug in
C and PL/I is free-store management errors. Also, related to your mention
of dynamic type checking, and probably even more important, is array bounds
checking (available as a compile-time option in Multics PL/I, but not
generally used).
--
Barry Margolin
System Manager, Thinking Machines Corp.
bar...@think.com {uunet,harvard}!think!barmar
Michael Padlipsky
> environment is the stack frame owned by default_error_handler_$wall,
> which serves only to intercept detected error conditions (e.g.,
> overflow, null pointer de-reference) and not let them propagate to still
> earlier stack frames. This isn't a "wall", though, in any important
> sense--it's just one of many possible implementation mechanisms to
> localize the semantics of PL/I conditions.
Before 'rings', the protection of the supervisor was often called 'the
Chinese Wall' by Corby. (I of course reminded him that the bodies
of the workers who died abuilding the Great Wall helped fill the Great
Wall, on many occasions.) Perhaps this is what the original 'poster'
had in mind?
On the other hand, I also remember a young fan asking Theodore Sturgeon
about a story of 'his' that was probably by somebody else entirely and he
more or less tactfully replied that if he'd written it it was so long
ago it must have been virgin Sturgeon, so perhaps 'the wall' is actually
a TSS/67 artifact.
cheers, map
Gregory A. Baryza
Stachour) wrote:
>
> dic...@enuxhb.eas.asu.edu (Paul Dickson) writes:
>
> >One thing that hasn't been mentioned so far is the difficulty of
> >overwriting the stack in Multics PL/1. Clobbering info on the stack
> >is more difficult than it is in C, although its still possible to do
> >it.
>
I taught PL/I programming on Multics internally at Ford for a couple of
years. I seem to remember that there were many places in the PL/I manual
which said something like, "The results of continued execution are
undefined." I always told my students that this meant that, if they didn't
handle the particular issue and they were really, REALLY lucky, their
program would fail immediately.
Seriously, it was pretty easy to overwrite the stack. You just had to make
a poor declaration of what you thought you were working with (incorrect
based structure, string too long, array of the wrong size) and then do
something perfectly valid with it. Not very much different from today,
really, I think.
<G>
Green Eric L
> In addition, the *WALL* between executing programs meant that
> wild go-to's didn't have the effect of strange loss-of-control.
>Hmmm.. I'm sure I remember talk of a "wall" back when many of my friends
>were Multing, but I can't now reconstruct anything about what it was all
There wasn't really a "wall", so to speak, but rather a hardware vestige.
Local go-tos were 18-bit addresses within the currently-executing segment.
Thus flow-of-control within a single segment couldn't result in jumping
into other segments.
Note, however, that due to the dynamic linking there was a whole lot
of procedure calls to routines in other segments. All of your
"operating system" calls were pointers to other segments that you did
an indirect call upon (initial call, of course, being to resolve the
reference). As far as PL/1 was concerned, however, it was just doing a
subroutine call rather than messing with pointers, so you couldn't
explicitly access those pointers from PL/1 (not easily, anyhow!).
Accidental overwriting was difficult, too, because you'd have to
munge up a pointer to the segment where the linkage data lived and then
start mucking about. Your heap was in a seperate segment, as was your
stack, so from PL/1 it was hard to casually screw up your linkage data.
In fact, since much of that stuff lived at lower rings, it was pretty
impossible for a user program to munge it up.
On the other hand, it wasn't difficult to mess up data belonging to
something else that lived in your address space, possibly resulting
in weirdness that would result in your being booted off the system or
a lockup of your process. I remember several times when I managed to
lock myself up so much that I had to have the operator log me out. Of
course I was running scuzzy software at the time (stuff mostly written
by local hacker types), but still, that shows it was possible.
>about. I seem to recall that the way the wall worked was a subject of some
>controversy -- some aspect of its behavior was changed and then changed
>back a few years later, or something like that.
Hmm? Perhaps you mean the "wall" between processes? If so, that worked
sort of like Unix -- everybody had their own address space, including
their own unique segment-number-to-filename mapping, if I recall correctly.
Access to other people's segments depended upon the Access Control List of
that segment as to what operations would be allowed. Each process also
had its own unique process directory which contained its heap, stack, and
linkage data. Access to another process's process directory was difficult
at best -- I did it sometimes, but only when the other process was
cooperating (e.g., I'd have the other process write the name of its
process directory into a file somewhere known, and grab it from there).
And again, even when you did have the other process's process directory
name, access to data therein depended upon the ACL.
This did, however, allow the possibility of shared data between
cooperating processes in an easy way. All you would have to do is
have a segment somewhere that both processes could read/write.
Shared data is still a point of major contention in various Unixes...
without the segment concept, you have to figure out where to put the
data in each process's single address space, and whether it lives at
the same address in each address space or whether it is totally relocatable
code (easy enough with the 68030, difficult with many RISC chips), etc.
etc. etc... needless to say, on segmented machines none of this is an
issue.
Eric Lee Green e...@usl.edu (318) 984-1820
Dan Weinreb
the "condition wall" that Olin described. It prevented a condition
signalled on one "side" of the "wall" from being handled by a
condition handler on the other "side", more or less effectively
causing each "wall" to establish a new environment (mapping from names
to handlers) of condition handlers.
Alan Bawden
d...@odi.com (Dan Weinreb) writes:
The term "wall" was in current use at MIT in the late 1970's to mean
the "condition wall" that Olin described....
Bingo. Yes, the phrase "condition wall" is the key that unlocks my memory
on the subject. I guess at the time I didn't realize that this was some
local MIT jargon -- which explains, I guess, why several other people have
generated differing reconstructions of what was meant by "the wall".
By the way. Talking about imperfect memories reminds me that I still have
some PL/1 code sitting in my mailbox that was forwarded to me during the
"Multics vs. Unix arg parsing" thread a couple of months ago. It shows a
typical command (`delete' I think) using `cu_$arg_count' and `cu_$arg_ptr'
in a way that is so close to the way a typical Unix command uses `argc' and
`argv' that it casts considerable doubt on the claim that Multics command
argument parsing was somehow less "ad-hoc". (Everybody agrees that Multics
commands were more consistent in their argument parsing, but this code
would seem to demonstrate that this was achieved mostly through willpower.)
When I find the time, I'm hoping to probe around a bit in the sources still
here at MIT and see if I can figure out just what it was that generated my
aging memory that argument parsing was somehow "better" on Multics.
Perhaps it has to do with the fact that wildcard expansion was under the
control of the command, rather than being imposed by the shell? I can
certainly think of a number of Unix jokes that are the result of shell-driven
wildcard expansion, but I no longer trust my memory well enough to assert
(without further research) that Multics-style command-driven wildcard
expansion was entirely joke-free.
Dan Weinreb
It shows a
typical command (`delete' I think) using `cu_$arg_count' and `cu_$arg_ptr'
in a way that is so close to the way a typical Unix command uses `argc' and
`argv' that it casts considerable doubt on the claim that Multics command
argument parsing was somehow less "ad-hoc".
Yes, I think I was the source of this misinformation, due to my own
mismemory. I thought I confessed to this in an earlier posting, but
maybe I forgot to. I *am* pretty sure that Multics commands called a
subroutine to parse star-names, unlike Unix, which has good points and
bad points.
Tom Van Vleck
cu_$arg_count and cu_$arg_ptr very much like the UNIX
environment uses argc and argv. In Multics, requiring
each command to expand starnames required logic and
complexity to be repeated in every command. For example,
hcs_$star returned stuff by allocating it in a PL/I area,
so commands that called it had to arrange for cleanup.
Commands that took multiple arguments, any of which might
be a starname, had to have nested loops and if statements
to behave correctly. From the programmer's point of view,
it is harder to write and debug a standard Multics command
than it is to write a UNIX command.
The user-visible differences between Multics and UNIX came
from different human interface design conventions. For
instance, Multics allowed control arguments that affected
the whole command invocation to come anywhere in the command
line; this was more work for the programmer, who had to loop
over the arguments an extra time, but more convenient for
users who typed part of a command and then remembered the
-brief arg.
Remember, we tried it both ways. The UNIX shell implements
many of the features of the original Multics shell. That
shell was so complicated and slow that we invented the
"mini_shell," which did no trick processing. You could
send a command line to the full shell by prefixing it with
a period. Then we added code to send the command to the full
shell if any metacharacters were typed. Then we replaced the
whole thing by a simpler and cleaner algorithm. In the process,
responsibility for star processing and command options moved
from the shell to the individual command, and the shell moved
into the single user process.
C. D. Tavares
> One thing that hasn't been mentioned so far is the difficulty of
> overwriting the stack in Multics PL/1. Clobbering info on the stack
> is more difficult than it is in C, although its still possible to do
> it.
Arf! As a student learning Multics in 1969, I came to the conclusion that
if the first few runs of your program didn't result immediately in a fatal
process error (trashing all possible debugging information), chances were
that you must have accidentally commented out most of your source code.
The biggest culprit, at least in my case, tended to be "substr"...
--
c...@rocket.sw.stratus.com --If you believe that I speak for my company,
OR c...@vos.stratus.com write today for my special Investors' Packet...
C. D. Tavares
> typical command (`delete' I think) using `cu_$arg_count' and `cu_$arg_ptr'
> in a way that is so close to the way a typical Unix command uses `argc' and
> `argv' that it casts considerable doubt on the claim that Multics command
> argument parsing was somehow less "ad-hoc".
Not the actual parsing itself -- just the conventions.
I saw my first example of non-ad-hoc parsing when I moved to Stratus and
learned all about Steve Webber's s$parse_command subroutine. Baroque in
the extreme, but a nice piece of engineering for what it does.
> (Everybody agrees that Multics
> commands were more consistent in their argument parsing, but this code
> would seem to demonstrate that this was achieved mostly through willpower.)
And sweat.
Paul Amaranth
>Alan Bawden is right. Argument parsing on Multics used
>cu_$arg_count and cu_$arg_ptr very much like the UNIX
>environment uses argc and argv. In Multics, requiring
>each command to expand starnames required logic and
>complexity to be repeated in every command.
The command iteration features of the command processor made implementing
this optional. If the command only worked on a single seg, it was a
simple matter to say
command ([segs *.foo])
and get the same effect from the user viewpoint. I think, in general,
commands only expanded starnames when it made sense to do so. Equal
names were another aspect of having the commands, rather than the shell,
perform name expansion. I don't think you would be able to easily write a
command like
rn **.fee ==.foo
which, if I remember my syntax correctly, would rename all
multicomponent names ending in fee to the same name ending in foo.
Writing this in Unix would be terribly ad-hoc and a general mess. What
you would do in Unix is write a dumb little script to do it.
I find writing shell loops to handle command iteration a real pain in
the simple cases where all I want to do is 'command ([segs *.foo])'.
In the discussion on the (ir)relevant output of Unix commands, I noticed
that nobody brought up the point that Multics commands _knew_ when they
were called as an active function and when they were called as a command.
In general, their behavior changed to be appropriate for the context, with
more verbose output when called as a command.
Nothing other than 20 years of accumulated baggage keeps Unix from doing
something similar, probably in a less elegant manner, but that won't happen.
--
Paul Amaranth Manager User Services - office: (313) 370 4541 (also voicemail)
(internet) amar...@vela.acs.oakland.edu | Amaranth's Law of Economics:
(bitnet) amaranth@oakland | Brit Sports cars + horses
(uucp) ...!uunet!umich!vela!amaranth | = $0
Peter da Silva
> I find writing shell loops to handle command iteration a real pain in
> the simple cases where all I want to do is 'command ([segs *.foo])'.
Given that the multics shell was first written over 20 years ago, it can't
have been a very complex program by today's standards (this isn't, by the way,
any sort of slam on the thing: I *like* simple programs). Given the general
similarity between the interfaces at a program level. Given the ease of writing
a radically new shell (look at all the people running 'rc' or clones on UNIX).
Given all this, would it be actually useful to have a Multics shell for UNIX?
I'd sure like to play with one, see where we came from and all that. And there
seems to be enough of the pent-up frustration that inspires such projects
around.
> Nothing other than 20 years of accumulated baggage keeps Unix from doing
> something similar, probably in a less elegant manner, but that won't happen.
Why not? I mean, it probably won't, but I can't think off the top of my head
of any technical problems. Including knowing if you're being run interactively
(isatty 0)...
Paul Amaranth
>> Nothing other than 20 years of accumulated baggage keeps Unix from doing
>> something similar, probably in a less elegant manner, but that won't happen.
>
>Why not? I mean, it probably won't, but I can't think off the top of my head
>of any technical problems. Including knowing if you're being run interactively
>(isatty 0)...
The problem is not just the shell, but all of the commands that would
have to be changed to work correctly. I think there was some discussion
a while ago about having Multics-like commands that could be used by
a Multics type shell in their own directory.
I don't see any technical problems either. It's more of a question of
a lot of pain for little gain. If someone wants to do that, I think
it would be great (in fact, I think there was a Multics shell implementation
for MS-DOS), but it won't be me. Unix works well enough most of the time
to not seriously inconvenience me (occasionally annoy, yes :-)
There was a little discussion with ACTC during the Multics->Unix migration
project about a Multics shell. ACTC thought there were no technical
obstacles, but that it really wasn't worth doing. Although the subject
pops up here from time to time, that seems to be the general consensus
here as well (or is someone proving me wrong, even as I type? :-)
Capt Jennifer Lyon
> Path: vela.acs.oakland.edu!destroyer!gumby!yale!yale.edu!newsserver.jvnc.net!howland.reston.ans.net!agate!netsys!pagesat!decwrl!uunet!odi!dlw
> From: d...@odi.com (Dan Weinreb)
> Newsgroups: alt.os.multics
> Subject: Re: The wall -- Imperfect Memories
> Date: 21 Sep 93 15:01:29
> Organization: Object Design Inc., Burlington, MA
> Lines: 14
> Reply-To: d...@odi.com
> Nntp-Posting-Host: butterball.odi.com
> Content-Length: 686
>
> In article <ALAN.93Se...@parsley.lcs.mit.edu> al...@lcs.mit.edu (Alan Bawden) writes:
>
> It shows a
> in a way that is so close to the way a typical Unix command uses `argc' and
> `argv' that it casts considerable doubt on the claim that Multics command
> argument parsing was somehow less "ad-hoc".
>
> mismemory. I thought I confessed to this in an earlier posting, but
> maybe I forgot to. I *am* pretty sure that Multics commands called a
> subroutine to parse star-names, unlike Unix, which has good points and
> bad points.
>
>
Wasn't that hcs_$star or expand_pathname_ or something like that??
--jsl
Peter da Silva
> The problem is not just the shell, but all of the commands that would
> have to be changed to work correctly.
How much would have to be changed, really? Even without the commands doing
their own wildcard expansion (and that could be faked pretty easily with a
tiny common wrapper) what are the big differences?
I've never used Multics. This is about the only way I'd be able to really
get a taste of it.
Rich Salz
>I don't think you would be able to easily write a command like
> rn **.fee ==.foo
There is the "ren" program now called mmv which does exactly that kind of
thing:
ren "*.C" #1.cc
I use ren, the first version, now and then. Very handy. Check a
comp.sources.unix archive.
/r$
Stephen O. Lidie
In article <tom_van_vleck...@tvv.taligent.com>
tom_va...@taligent.com (Tom Van Vleck) writes:
>Alan Bawden is right. Argument parsing on Multics used
>cu_$arg_count and cu_$arg_ptr very much like the UNIX
>environment uses argc and argv. In Multics, requiring
>each command to expand starnames required logic and
>complexity to be repeated in every command.
The globbing problems in Multics/Unix are handled cleanly in NOS/VE IMHO.
Every NOS/VE comand simply calls CLP$EVALUATE_PARMATERS for command line
argument processing. Wildcards are handle by the system call and not the
application. Every NOS/VE parameter is of a known type and every type can
be a list.
Lists are expressed on the command line by surrounding the elements with
parentheses:
(1.2, 4, 5e-10)
('hello world', 'list item two')
(true, false, 1, 0, no, yes)
(file1, file2, file)
Lists can also be expressed using wildcard notation:
file?
abc*def
This is possible because the application and CLP$EVALAUTE_PARAMETERS both
have all neccessary command line parameter information. VMS people use a
similar mechanism via CLDs (Command Line Descriptions?), but the VE way
is much cleaner and easier to use and maintain.
Every application developer creates a Parameter Description Table for the
application. A PDT is a simple text file that describes each command line
argument, exactly analogous to C function prototypes. The PDT specifes
the parameter name, alias, type, default value and whether or not its a
list,
plus other stuff I'll ignore.
A PDT could look like this:
PDT display_catalog_tree, disct (
catalog, c: list of file = $working_catalog
depth, d: integer 1 .. 1024 = 1024
output, o: file = $output
vt100_graphics, vg: boolean = TRUE
status: (VAR, BY_NAME) status = $optional
PDTEND
CLP$EVALAUTE_PARAMETERS knows that the catalog parameter can be a list of
catalog names - the actual application code receives a pointer to a list
which it uses to loop through.
A program called generate_pdt(genpdt) would take a PDT like that above as
input and create an output file of compiler declarations that would then be
included in the application. Using this PDT information
CLP$EVALUATE_PARAMERTERS knows exactly how to parse the arguments for any
given command. This is the reason for NOS/VEs global consistency.
We are all Unix here now, so not suprisingly I have developed a C version
of
CLP$EVALUATE_PARAMTERS that works in an analagous manner. It is suprising
how easy it is to handle argument processing now, and to add/change command
line arguments. There is also enhanced consistency and something I haven't
mentioned yet: consistent command line parameter help. Since the PDT
information is available to evaluate_parameters it automatically handles a
-help parameter and spits out the PDT in a human readable form - any
program
using evaluate_parameters has a consistent -help output rather than the
Unix
way: either none or one of a million different Usage: messages!
Take care,
SOL
Paul_...@vos.stratus.com
>I saw my first example of non-ad-hoc parsing when I moved to Stratus and
>learned all about Steve Webber's s$parse_command subroutine. Baroque in
>the extreme, but a nice piece of engineering for what it does.
>
According to my memory, and to the modification history, Larry Johnson
wrote s$parse_command in August 1980. I don't see why you think it is
baroque...here is the entire executable source code for the VOS ccd
(ala Multics cwd) command:
call s$parse_command (my_name, code,
'new_directory:pathname,=''(home_dir)''', current_dir,
'end');
if code ^= 0
then return;
call s$change_current_dir (current_dir, code);
if code ^= 0
then call s$error (code, my_name, current_dir);
This command takes one, optional argument (you would see the
attribute ",required" if it was required). It is a pathname.
It's default value is the user's home directory, which is
obtained via a command function at runtime.
I'd say that the code is terse, readable, to the point, and not
baroque.
Examples:
ccd # change to home dir
ccd fred # change to subdir named fred
ccd not_there # oops
change_current_dir: Object not found.
%es#lang3>Languages>Green>not_there
ccd -usage # show usage
Usage: change_current_dir [new_directory]
ccd -form -usage # show form usage
------------------- change_current_dir -----------------
new_directory: %es#lang3>Languages>Green
Every command accepts -usage and displays a linear summary of the
arguments. Every command accepts -usage -form and displays a picture
of what the full-screen form looks like. Every command accepts just
-form and pops up the full screen form.
Very consistent, very powerful, saves a ton of work when writing
commands.
If there are problems with s$parse_command, it is that it
handles many different data types and combinations, and can get
pretty complicated after a while (it can expand star names, can
have cycle fields, computed defaults, argument dependencies,
etc.). Or that there are some things it just can't do, by
design (switch arguments that apply only to subsequent names,
for example. Ugh**10, which is why we left it out).
The source code for s$parse_command is about 5500 lines of PL/I,
so it is not a simple program, but it gets rid of many, many
possibilities for irritating variations and just plain bugs in
argument parsing.
My own view of why Multics argument handling is more consistent
is just that we had more years and more desire to get it right.
I can remember that it took me a long time before I felt
comfortable writing argument parsing code for Multics...it was
like working in assembly language, and it was very easy for your
code to have glitches...we built on each other's work like a
pyramid. If one person would improve a convention, the rest of
us would pick it up. I take credit for only one
convention...fixing the Multics pl1 compiler so that saying
pl1 foo.pl1
would not produce the error message:
pl1: Entry not found. foo.pl1.pl1
but would instead compile the program found in the file "foo.pl1".
This idea that the suffix that HAD to be on the file was
OPTIONAL on the command line was, I think, mine. Prior to that,
pl1 and other commands just blindly appended ".pl1" to the file
name. You could NOT put it on the command line. Had we not
fixed this, then
pl1 ([segs *.pl1])
would have had to have been
pl1 ([strip_entry ([segs *.pl1]) pl1])
or somesuch.
Like all good Multics conventions, we eventually incorporated
this one into a subroutine (expand_pathname_$suffix?) so
everyone would have the benefit of the same feature and so we
would only have to debug it once. This last point is not a
minor one; error handling is just tricky enough that it is
really hard to get right every time. (For example, you can't
append ".pl1" if there is no room for it).
PG
--
Paul Green | Mail: Paul_...@vos.stratus.com
Senior Technical Consultant | Voice: (508) 460-2557 FAX: (508) 624-7488
Stratus Computer, Inc. | Video: PictureTel/AT&T by request.
Marlboro, MA 01752 | Disclaimer: I speak for myself, not Stratus.
Roland Schemers
>In <27pnqo$2...@vela.acs.oakland.edu> amar...@vela.acs.oakland.edu (Paul Amaranth) writes:
>>I don't think you would be able to easily write a command like
>> rn **.fee ==.foo
>
>There is the "ren" program now called mmv which does exactly that kind of
>thing:
> ren "*.C" #1.cc
>
Don't forget the rename program shipped with perl :-) Not very user-friendly,
but very powerful:
rename 's/\.C$/.cc/' *.C
Or:
rename 'y/A-Z/a-z/' *
To translate uppercase names to lower. Since you can use any perl
expression it is quite powerful.
Roland
--
Roland J. Schemers III | Networking Systems
Systems Programmer | 414 Sweet Hall +1 (415) 723-6740
Distributed Systems Operations | Stanford, CA 94305-3090
Stanford University | sche...@Slapshot.Stanford.EDU
Roland F. McKenney
Wasn't that hcs_$star or expand_pathname_ or something like that??
--jsl
Checking the index to the Multics Subroutines and I/O Modules manual we have
star convention
check_star_name_
check_star_name_$check_st_n
check_star_name_$entry
check_star_name_$path
hcs_$star_
hcs_$star_dir_list_
hcs_$star_list_
match_star_name_
For the curious, and even if you are not curious, here is a page from a Multics
manual:
---------------- ----------------
match_star_name_ match_star_name_
---------------- ----------------
Name: match_star_name_
The match_star_name_ subroutine implements the Multics star convention by comparing
an entryname with a name which may contain stars or question marks, called a
starname.
USAGE
declare match_star_name entry (char(*), char(*), fixed bin(35));
call match star_name_ (entryname, starname, code);
ARGUMENTS
entryname
is the string to be compared with the starname. Trailing spaces in this string are
ignored. (Input)
starname
is the string with which the entryname is compared. Trailing spaces in this string
are ignored. (Input)
code
is one of the standard status codes listed below. (Output)
LIST OF STATUS CODES
0
the entryname matches the starname.
error_table_$nomatch
the entryname does not match the starname.
error_table_$badstar
the starname does not have an acceptable format.
NOTES
See the description of the hcs_$star_ entrypoint in hcs_ to find how to list the
directory entries that match a given starname. See check_star_name_ to find how to
validate a starname. See starname.gi.info for the rules governing the formation and
interpretation of starnames.
2-583 AG93-05
--
== Roland F. McKenney Bull HN Information Systems Inc. ==
== Phone 1-508-294-3686 US Applied Research Lab MA30-821A ==
== Fax 1-508-294-4361 300 Concord Road ==
== R.McK...@ma30.bull.com Billerica, MA 01821-4186 USA ==
Capt Jennifer Lyon
> Newsgroups: alt.os.multics
> Path: vela.acs.oakland.edu!destroyer!sol.ctr.columbia.edu!spool.mu.edu!cass.ma02.bull.com!petra!skyros!mckenney
> From: mcke...@skyros.ma30.bull.com (Roland F. McKenney)
> Subject: Re: The wall -- Imperfect Memories
> Sender: ne...@petra.ma30.bull.com (Network News)
> Reply-To: mcke...@skyros.ma30.bull.com (Roland F. McKenney)
> Organization: Bull Worldwide Information Systems
> Date: Fri, 24 Sep 1993 12:37:54 GMT
> Content-Length: 2413
I programmed on a Multics...
--jsl
Peter da Silva
> PDT display_catalog_tree, disct (
> catalog, c: list of file = $working_catalog
> depth, d: integer 1 .. 1024 = 1024
> output, o: file = $output
> vt100_graphics, vg: boolean = TRUE
> status: (VAR, BY_NAME) status = $optional
> PDTEND
Looks pretty similar to the command description structure in Eric Allman's
'parseargs' package for UNIX. I've extended it to accept Amiga or MS-DOS
style options, using the same table, and Brad Appleton at Harris added VMS.
That way, a single source will automatically match the native command line
syntax compiled on any of these systems.
Peter da Silva
UNIX-trained eyes.
Tom Van Vleck
> Most amusing. That Multics manual page looked *so* ver familiar to these
> UNIX-trained eyes.
It looks familiar to CTSS-trained eyes too.
CTSS was the inspiration for many features of both Multics and UNIX.
Not only the format of man pages, but the idea of a help command
that could access usage information on-line originated with CTSS.