cottrell@nbs-vms.ARPA (02/27/85)
/* > > Those users could have their .profile <set TERM and TZ>, then `exec' their > > <login shell> as the last statement. > > That can be done - it's what we did before we fixed "login" to permit > you to set TERM and TZ directly. However: > > 1) it's a kludge, the need for which can be obviated by a minor change > to "login"; 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!!! > 2) it requires the system administrator to go through a song-and-dance > to set up their account ("No, Fred, you don't just set their "shell" > field to "/op/op/programs/shell", you leave it blank and stick the > following in their .profile...") - i.e., it renders the "shell" field > of the password file largely useless. 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 */
guy@rlgvax.UUCP (Guy Harris) (02/28/85)
> /* > > > Those users could have their .profile <set TERM and TZ>, then `exec' their > > > <login shell> as the last statement. > > > > That can be done - it's what we did before we fixed "login" to permit > > you to set TERM and TZ directly. However: > > > > 1) it's a kludge, the need for which can be obviated by a minor change > > to "login"; > > It's NOT a kluge, it was DESIGNED that way. Yes. It was designed to assume everybody used the Bourne shell as their login shell. Feh. (P.S. Did you design it? Do you know the designer? If no, how do you know it was designed that way?) > Why modify REAL CODE to do what you can with a PROFILE? Because it's more convenient to set TERM directly than to explain that "well, yes, there is a "shell" field in the password file, but you can't always use it because Bell forgot that people don't always use the Bourne shell as their login shell". If .profile or /etc/profile are so wonderful, how come there's a "shell" field in the password file at all? Why wasn't it removed in V7? > 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? If it's truly a canned application, it's very unlikely that Joe Blow even knows what an environment variable, much less that they should set INPUT to some particular value. > Does everyone even HAVE the source? No, but we are a vendor and therefore have the source; we fix it once and all our customers get it. (AT&T fixes it and everybody who buys from AT&T gets it.) > > 2) it requires the system administrator to go through a song-and-dance > > to set up their account ("No, Fred, you don't just set their "shell" > > field to "/op/op/programs/shell", you leave it blank and stick the > > following in their .profile...") - i.e., it renders the "shell" field > > of the password file largely useless. > > Systems administrators LIKE to sing & dance. That's what they get paid > for. At our sites, most SAs are former secretaries or clerks and do a nice job of administering the systems using the utilities we provide. They get paid to add users, dump files, and understand the application and answer questions, not to figure out the intricacies of UNIX. The latter is what our support people are 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. And at the expense of taking a one-file user database and scattering the information in it across N .profile files. It's also nice not to have "uucp" have to go through the entire "/etc/profile" and ".profile" to log in (note the 4.xBSD ".hushlogin" facility to keep UUCP just from getting the message-of-the-day when it logs in; if you force them to run the entire /etc/profile you're wasting the remote site's money). Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
long@ittvax.UUCP (H. Morrow Long [Systems Center]) (02/28/85)
> ..... > 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
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (03/01/85)
> Unix(tm) will be truly popular when no one sees it.
Yes, yes! The traditional UNIX interface (via shell) is not
appropriate for Joe Q. Public. It is great for programmers.
People do not buy home computers very often to program (or,
if they do and are not professional programmers, they often
learn the hard way that programming is not for everyone).
Instead, they buy computers to get some specific job or jobs
done, such as keeping financial records and recipe files, or
text processing. UNIX makes a great base for applications
that address these needs, and that is the only reason that
Joe Q. Public should want a UNIX (since he can ultimately
expect a wider choice of solutions if he has a UNIX-based PC).
One problem remains, namely that software for the masses is
supplied in hardware-dependent form. This tends to favor the
few very-popular systems and the neglect of others. Fortunately
UNIX applications can be cheaply ported (especially under an
industry-wide system interface standard), so that the less-
popular systems still have a better selection if they run UNIX.