kluge vs design

[H. Morrow Long [Systems Center]]

> .....
> It's NOT a kluge, it was DESIGNED that way. Why modify REAL CODE to do
> what you can with a PROFILE? What if Joe Blow wants the environment
> variable INPUT set to some special filename for his application? Are
> you going to go off to /usr/src & hack login.c for him too? Does
> everyone even HAVE the source? Program at the right level!!!
> 
>  .....
> Systems administrators LIKE to sing & dance. That's what they get paid
> for. The user sticks it to his own profile. Or asks the S.A. to do it.
> You have a point, tho. The shell field is largely useless and can be
> done away with altogether. `Exec' as the last line in .profile does the
> same thing at the expense of some extra startup time. 
> 
> 	jim
> */

	It appears that there is a basic misunderstanding here and I
	must side with Guy Harris.  Guy works for CCI, a company that
	sells Unix systems for office automation, to users in the, you
	know ...REAL WORLD.  This environment appears to be alien to
	'jim'.  End users want solutions, they could care less about
	the sanctity of the 'tools' philosophy or the purity of
	/usr/src/*.  In the large part they don't know, care to know
	and shouldn't have to know about '.profile's and environment
	variables.  Most of the Unix systems being sold today run XENIX
	(on PC's, Tandy's, Altos 586's, Intel 310's).  Will an
	auto-parts store with 3 or 4 people running the MBSI accounting
	package and Horizon word processing have a system admistrator
	who has an indepth knowledge of the shell?  Enough to diagnose
	and correct problems with TERM variables?  What about the
	retail computer store salesman?  Will he be able to help?  If
	the applications haven't been somewhat bulletproofed the small
	business may just say "No thank you.  We're returning this
	system".

	Although it is distasteful to many in many ways I think that
	modifying login.c to obtain the TERM variable is reasonable.
	It will be done in a central place (obviating the need for
	individual applications to prompt for it, or worse, store the
	information in their own databases) at the point of entry into
	the system and no one at the site will need a knowledge of the
	shell (an administrator's menu can handle the maintenence of
	the /etc/ttytype file - ala Microsoft's menu shell).

	The 'shell' field of the passwd entry is not 'useless', it is
	widely used here, most of the accounts have '/bin/csh' in it.
	I have an account that places me directly into a System V
	emulation shell.  We have secure uucp accounts with
	/usr/lib/uucico as the 'shell', student accounts with
	restricted shells, and a help account for the terminally
	bewildered.  As we acquire more non-programming oriented users
	I can see the utilization of this field for Gary Perlman's
	'menunix', Univ. of Maryland's window shell 'wsh', possibly
	'emacs' and maybe an account strictly for file transfers with
	PC's (with a kermit server shell and a home directory of
	/usr/spool/uucppublic).

	Unix(tm) will be truly popular when no one sees it.

	E Pluribus Unix

-- 

				H. Morrow Long
				ITT-ATC Systems Center,
				1 Research Drive Shelton, CT  06484
				Phone #: (203)-929-7341 x. 634
	
path = {allegra bunker ctcgrafx dcdvaxb dcdwest ucbvax!decvax duke eosp1
	ittral lbl-csam milford mit-eddie psuvax1 purdue qubix qumix 
	research sii supai tmmnet twg uf-cgrl wxlvax yale}!ittvax!long