Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!att!mtuxo!mtgzz!avr
From: avr@mtgzz.att.com (a.v.reed)
Newsgroups: comp.windows.x
Subject: Re: xinit lacks init in it (FLAME!)
Summary: Canned applications can be scripts
Message-ID: <4484@mtgzz.att.com>
Date: 5 Sep 88 02:16:59 GMT
References: <4479@mtgzz.att.com> <8809021533.AA04630@EXPO.LCS.MIT.EDU>
Organization: AT&T, Middletown NJ
Lines: 69

In article <8809021533.AA04630@EXPO.LCS.MIT.EDU>, jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes:
> > It is called a "SHELL"! Try it. You'll like it.
> I have.  And for some things I do.
> However, end users justifiably don't want anything to do with it.  That's
> why developing good tools for building quality User Interfaces is such
> an important area of development. 
> > This works perfectly, giving me exactly the server and clients I put in it.
> You can understand it, but the vast majority of end users would barf if they
> were told that they had to do something like that.  Instead, they want a 
> simple, convenient way to restart their world in a nice state and shut it down
> when they are done.  All without having to do any UNIX garbage.
>     ....
> Programmers are no longer the most important group of UNIX users,
> end application customers are.

I happen to agree with all of the above. End users want canned
applications, and I am as willing as anyone to provide them. The
issue we disagree on is not whether or not to can applications, but
what to put in the can. There is nothing to prevent a canned
application from using shell scripts for things that a shell does
best, namely setting up a working environment and spawning and
interconnecting processes.  My approach to building a canned
application would be to place in */bin/xrun a script which looks at
a user's environment, asks a few questions, prepends the
appropriate aliases to the user's $ENV, and writes the customized
running script to the user's $HOME/.xrun. The user needs to learn
just two commands, "xrun" to start and "xkill" to finish. That's
less "UNIX garbage" then learning the format of arguments to xinit.
So who's friendlier?

> > Correction: most people use [xinit] only because they don't understand
> > UNIX, which has to do with knowing what tools are available,
> > and using the right tool for the job.
> 
> Or they want a little more robustness than an ugly hack will give them.  

I learned something about "robustness" when I ran "xinit" with $SHELL
set to /bin/ksh. People who live in glass houses, etc. The bug
responsible for the problem was not exactly easy to find in xinit.c.
Which is another argument for using shell scripts: a script is typically
1/10th the length of an equally legible C program that does the same
job. And its bugs can be found in 1/10th the time.  OK, so everybody
can let a bug through now and then. The ability to find the bugs in
minimum time is a VERY good reason to NOT use a compiled C program when
a shell script will do the job.

> > To us tool-users, the very existence of an "xinit" is proof that not 
> > everyone plays with a full toolbox.
> Right, because it is woefully inadequate.  Session managers will make life
> much nicer.

Yes, but for maintainability I want these session managers to be built
out of small, understandable modules. And the shell will remain my
tool for putting the modules together, and for customizing their
operation. We programmers use the shell to build our own applications
for those very reasons. That's why cc, lint, and make are all managed
by shell scripts. Why should we lower our standards when building for
end users?

>  X is not UNIX-specific.

Neither is ksh; I've used it on OS-9 and MS-DOS, and I'm told it has
been ported to just about any OS you can find a C compiler on. Xinit,
on the other hand, is about as UNIX-specific as you can get; every C
program that tries to do the shell's job somehow turns out that way.
Letting the shell do its job is the best way of maximizing
portability between operating systems. Another reason, etc.

				Adam Reed (avr@mtgzz.ATT.COM)