iacovou@cs.umn.edu (Danny Iacovou) (08/31/90)
I recently upgraded ELM2.3 from PL 4 to PL 6. I found 2
interesting "bugs?".
The first one is (well ok so this one has a part a and b)
that when I did a 'configure -d' two items changed in my config.
set up.
a) my domain name changed from .cs.umn.edu to .UUCP
(it's a good thing I noticed this one right off)
b) the shell changed from the 'C' shell to the 'Korn' shell
(is Korn shell THAT much better?)
I had no problem with that "bug?". What I really care about is
that now when a user types the magic letters elm for the first
time and answers yes to the question about making a .elm dir.,
and even though a .elm dir. is made, no elmrc file is put in it.
Anyone else get this problem?
--
neophytos iacovou
university of minnesota email: iacovou@cs.umn.edu
computer science departmentsyd@DSI.COM (Syd Weinstein) (08/31/90)
iacovou@cs.umn.edu (Danny Iacovou) writes: > The first one is (well ok so this one has a part a and b) > that when I did a 'configure -d' two items changed in my config. > set up. > a) my domain name changed from .cs.umn.edu to .UUCP > (it's a good thing I noticed this one right off) Check you config.sh file, the domain on a -d comes from there. If it choose .UUCP, then it was .UUCP in there or '' in there. > b) the shell changed from the 'C' shell to the 'Korn' shell > (is Korn shell THAT much better?) This comes from the SHELL environment variable while running Elm, or from the config.sh file. > I had no problem with that "bug?" neither is a bug. > What I really care about is > that now when a user types the magic letters elm for the first > time and answers yes to the question about making a .elm dir., > and even though a .elm dir. is made, no elmrc file is put in it. That is correct and expected behavoir, an elmrc file is not needed unless the defaults are being overridden. One will be created if the options menu is chosen and the options saved. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
pmm@mips.COM (Paul M. Moriarty) (09/01/90)
In article <1990Aug31.002402.8495@DSI.COM> syd@DSI.COM writes: >iacovou@cs.umn.edu (Danny Iacovou) writes: > >> What I really care about is >> that now when a user types the magic letters elm for the first >> time and answers yes to the question about making a .elm dir., >> and even though a .elm dir. is made, no elmrc file is put in it. >That is correct and expected behavoir, an elmrc file is not needed >unless the defaults are being overridden. One will be created if the >options menu is chosen and the options saved. It may not be a bug, but it certainly is a nuisance. It would be a lot nicer if I could just direct a user to his/her elmrc and tell them to modify to their heart's content rather than first telling them how to create a default elmrc. Why should the program say that the .elm directory is necessary immediately upon invoking Elm for the first time when it isn't planning on putting anything in the dir until you either create an alias or save off your elmrc from the options window? Seems to me that it shouldn't prompt you for creating the directory until it is actually needed. I'd strongly suggest that the default elmrc be written if .elm is being created or if .elm exists and elmrc doesn't. -- Paul M. Moriarty pmm@mips.com {ames,decwrl}!mips!pmm Sr Systems Administrator MIPS Computer Systems, Inc +1 408 524 8335
fitz@wang.com (Tom Fitzgerald) (09/06/90)
pmm@mips.COM (Paul M. Moriarty) writes: > It would be a lot > nicer if I could just direct a user to his/her elmrc and tell them to > modify to their heart's content rather than first telling them how to > create a default elmrc. People who want to muck with their elmrc's better have a good understanding of how it works, or they can badly burn themselves. I'd say let them learn how the defaults work before letting them modify anything. It's easy enough to create a default elmrc. > I'd strongly suggest that the default elmrc be written if .elm is being > created or if .elm exists and elmrc doesn't. I'd just as soon keep things the way they are. If elm 2.4 or 3.0 or whatever renames some option fields, or changes an option default, I don't want to have to modify the elmrc's of every user on this system. Any user who _has_ built a new elmrc should change it on his own, but presumably those people know what they're doing. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
scs@lokkur.dexter.mi.us (Steve Simmons) (09/08/90)
pmm@mips.COM (Paul M. Moriarty) writes: > It would be a lot > nicer if I could just direct a user to his/her elmrc and tell them to > modify to their heart's content rather than first telling them how to > create a default elmrc. fitz@wang.com (Tom Fitzgerald) writes: >People who want to muck with their elmrc's better have a good understanding >of how it works, or they can badly burn themselves. I'd say let them learn >how the defaults work before letting them modify anything. It's easy >enough to create a default elmrc. pmm@mips.COM (Paul M. Moriarty) writes: > I'd strongly suggest that the default elmrc be written if .elm is being > created or if .elm exists and elmrc doesn't. fitz@wang.com (Tom Fitzgerald) writes: >I'd just as soon keep things the way they are. If elm 2.4 or 3.0 or >whatever renames some option fields, or changes an option default, I >don't want to have to modify the elmrc's of every user on this system. >Any user who _has_ built a new elmrc should change it on his own, but >presumably those people know what they're doing. I disagree with most of the stuff written so far about the elmrc, and these two sum up the suggestions pretty well. My two cents: Admins should be able to configure elm on a site-wide basis with a master elmrc file. Users should be able to override the site stuff with their own elmrcs. The stuff about users being able to handle their own elmrcs isn't so. If the naive user changes one simple thing (such as changing his editor from vi to jove), all of his settings are saved. This is a problem two ways. First, it causes exactly the problem fitz describes. Second, the options displayed in the options are incomplete, so the naive user can't change them. We ought to (a) get *all* the options in there, and (b) when writing an elmrc file, save only those options which are different from the system default file.