marcos@caus-dp.UUCP (Marcos R. Della) (11/17/87)
We just got a few ideas sent to us for the changing of PS1 to
show the current directory that you are on (/usr/lib$... etc...) but
have in the process managed to discover a few problems with our
Xenix system. We are trying to get this to work before we go over
to the Sperry 5000/80's at the end of December.
We are running Xenix Revision 3.4 from Intel and the Bourne shell
won't let us do things like the following...
export ps1
cd()
{
builtin cd $* &&
case "$1" in
"") PS1="$ps1" dir=$HOME ;;
/*) PS1="`basename $1`$ps1" dir=$1 ;;
..|*/..) dir=`/bin/pwd`; PS1="`basename $dir`$ps1" ;;
*/*) PS1="`basename $1`$ps1" dir= ;;
*) PS1="$1$ps1" dir= ;;
esac &&
export PS1
}
The program bombs at the cd() statment and returns the statment:
-sh: syntax error: `(' unexpected
Any ideas on whats wrong and what might be done in another method to
correct the problem that we seem to be having? We have tested this
on the Sperry and it seems to work, but not on the smaller Intel 310
machines.
Any help would be appreciated.
Marcos Della
--
...!lll-crg -> !csustan -\ | Whatever I said doesn't
...!sdsu ----->->!polyslo!caus-dp!marcos | mean diddly as I forgot
...!ihnp4 -> !csun ----/ | it even before finishing
...!dmsd ---/ | typing it all out!!!nic@marque.mu.edu (Nic Bernstein) (11/19/87)
In article <279@caus-dp.UUCP> marcos@caus-dp.UUCP (Marcos R. Della) writes: >We are running Xenix Revision 3.4 from Intel and the Bourne shell ^^^^^^ >won't let us do things like the following... > > export ps1 > cd() > { (function deleted) > } > >The program bombs at the cd() statment and returns the statment: >-sh: syntax error: `(' unexpected > I am not sure about Xenix, but Borne usually doesn't support functions and this is a funcion definition! Later, larger, big system Bourne shells have had an added feature to declare functions but I doubt that yours does. You can have functions in "csh" and "ksh" however. Interesting but, regular MSDOS users have had the benefit of the "csh" shell for some time, might there not be a version for Xenix? - Nic
bak@csd_v.UUCP (Bruce) (11/20/87)
In article <1926@marque.mu.edu>, nic@marque.mu.edu (Nic Bernstein) writes: > ^^^^^^ > >won't let us do things like the following... > > > > export ps1 > > cd() > > { > (function deleted) > > } > > > >The program bombs at the cd() statment and returns the statment: > >-sh: syntax error: `(' unexpected > > > I am not sure about Xenix, but Borne usually doesn't support > functions... The problem is not that the bourne shell doesn't support sys5 functions, it's that a function cannot replace a builtin. If you have ksh you can use an alias to do the job but in sh you must rename the command. Thus: $ ccd() > { > cd $* > PS1="`pwd`> " > } $ ccd /usr/bak /usr/bak> pwd /usr/bak /usr/bak> will do the job. However since the cd command is not disabled it is very easy for the prompt to be inaccurate, because of the tendency to use the 'cd' command instead of the 'ccd' command. So although I use a version of this in MSDOS and VMS systems, I don't use it in a UN*X system. -- Bruce Kern -- Computer Systems Design, 29 High Rock Rd., Sandy Hook, Ct. 06482 uunet!swlabs!csd_v!bak
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/20/87)
In article <279@caus-dp.UUCP> marcos@caus-dp.UUCP (Marcos R. Della) writes: > cd() > { > builtin cd $* && >... > } "builtin" is not a standard UNIX System V Bourne shell feature. It is found in the 8th and 9th Edition UNIX shells, in the BRL SVR2 Bourne shell, and possibly (I'm not sure) in the Korn shell. In fact, it isn't useful in standard SVR2 Bourne shells, because they don't permit defining functions that have the same name as built-ins. (However, you could define a "ch" function and get used to typing "ch wherever" to change directory.) SVR1, 4.nBSD, and other older shells don't support definition of shell functions at all.
stpeters@dawn.steinmetz (Dick St.Peters) (11/23/87)
In article <6704@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >found in the 8th and 9th Edition UNIX shells ... *9*th Edition? Just how far has AT&T carried this "Edition" stuff while I've been out of touch? Last I knew (admittedly some time ago), mere customers were supposed to settle for SYSV while Edition 8 was for AT&T internal use. That a company won't use its own product doesn't exactly help it push that product as a standard ... -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/23/87)
In article <7936@steinmetz.steinmetz.UUCP> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: >*9*th Edition? Just how far has AT&T carried this "Edition" stuff >while I've been out of touch? Last I knew (admittedly some time ago), >mere customers were supposed to settle for SYSV while Edition 8 was >for AT&T internal use. That a company won't use its own product >doesn't exactly help it push that product as a standard ... The 8th and 9th Edition UNIX series (aka V8 & V9) were developed by Bell Labs CS research staff for their own use and were also made available to a small select group of universities that could contribute to the development of the system. They were not made available for general commercial licensing and are not used by AT&T for "production" systems; the UNIX System V product line prevails there. Some of the innovations of 8th Edition UNIX have found their way into the UNIX System V product, generally after considerable rework to meet whatever criteria the official product demanded. Examples of such facilities include the File System Switch, STREAMS, RFS, and DMD (5620) software. There are many other interesting things in the Research UNIX systems that have not (so far) appeared in the commercial UNIX System V product. There is a famous quote: "UNIX is defined by whatever is running on Dennis Ritchie's machine."
jec@nesac2.UUCP (John Carter ATLN SADM) (11/24/87)
In article <7936@steinmetz.steinmetz.UUCP>, stpeters@dawn.steinmetz (Dick St.Peters) writes: > > *9*th Edition? Just how far has AT&T carried this "Edition" stuff > while I've been out of touch? Last I knew (admittedly some time ago), > mere customers were supposed to settle for SYSV while Edition 8 was > for AT&T internal use. That a company won't use its own product > doesn't exactly help it push that product as a standard ... But the internal use 'Edition' is (eventually) the next revision of the 'commercial' product. The internal Editions are not always a product you'd want to use in production - how many guru's of what degree do you have for local support? :-) -- USnail: John Carter, AT&T, Atlanta RWC, 3001 Cobb Parkway, Atlanta GA 30339 Video: ...ihnp4!cuea2!ltuxa!ll1!nesac2!jec Voice: 404+951-4642 (The above views are my very own. How dare you question them? :-)
kailhofe@puff.wisc.edu (Andrew D. Kailhofer) (11/24/87)
In article <279@caus-dp.UUCP> marcos@caus-dp.UUCP (Marcos R. Della) writes: >We are running Xenix Revision 3.4 from Intel and the Bourne shell >won't let us do things like the following... > [ src deleted ] > >The program bombs at the cd() statment and returns the statment: >-sh: syntax error: `(' unexpected > >Any ideas on whats wrong and what might be done in another method to >correct the problem that we seem to be having? We have tested this It doesn't work because the cd is one the few things that are really don in the kernel (you won't find /bin/cd anywhere), and the kernel doesn't like to alias the things that it does. What it thins you are doing is trying to cd to somewhere, but when it starts to get the somewhere, it finds an unknown and unlookedfor '(', and barfs ------ Andrew D. Kailhofer |507 VanVleck Hall | This third left Systems Consultant |Madison, WI 53706 | blank for reasons UW-Madison Math Department |(608) 263-4189 | of national kailhofe@weaver.math.wisc.edu |I wrote it, it's _mine_!| security (spooks and ...!uwvax!vanvleck!kailhofe |Bansplaft! | all that stuff).
stpeters@dawn.steinmetz (Dick St.Peters) (11/25/87)
In article <6721@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >The 8th and 9th Edition UNIX series (aka V8 & V9) were developed by Bell Labs >CS research staff for their own use and were also made available to a small >select group of universities that could contribute to the development of the >system. They were not made available for general commercial licensing and are >not used by AT&T for "production" systems; the UNIX System V product line >prevails there. Being at an R&D lab, I expect a company's research version of something to be beyond what it sells. However, at USENIX a few years ago when Edition 8 was the AT&T research version, AT&T employees gave the impression that a release of Edition 8 was in widespread use within AT&T, not just at BTL. AT&T employess turned GE employees have since confirmed the impression that Edition 8 was widely distributed and used within AT&T as an internal production version (on a scale exceeding anything that could reasonably be considered beta testing) substantially before any of its features were incorporated into what was promoted to paying customers as the commercial UNIX standard. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
wel@homxc.UUCP (11/25/87)
In article <6721@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > the File System Switch, STREAMS, RFS, and DMD (5620) software. There are > many other interesting things in the Research UNIX systems that have not (so > far) appeared in the commercial UNIX System V product. Details please Winston Lee "Hab' Ihnen den feinsten Cognac gebracht -- trinken nur die Angestellten"
eao@anumb.UUCP (11/25/87)
> >It doesn't work because the cd is one the few things that are really don in >the kernel (you won't find /bin/cd anywhere), and the kernel doesn't ^^^^^^ >like to alias the things that it does. What it thins you are doing is >trying to cd to somewhere, but when it starts to get the somewhere, it finds >an unknown and unlookedfor '(', and barfs >------ no - cd is done in the shell itself. Not the kernel. Well, of course, everything interesting is done in the kernel; but I think that in the sense you use it , shell is more appropriate. eric olson ihnp4!mvuxq!eao
ekrell@hector.UUCP (Eduardo Krell) (11/25/87)
In article <7972@steinmetz.steinmetz.UUCP> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: >Being at an R&D lab, I expect a company's research version of >something to be beyond what it sells. However, at USENIX a few years >ago when Edition 8 was the AT&T research version, AT&T employees gave >the impression that a release of Edition 8 was in widespread use >within AT&T, not just at BTL. I don't have hard numbers, but I doubt 8th Edition is in "widespread" use, even in Bell Labs. Most of the Computer Centers in Bell Labs run something called "R&D Unix" which is System V based, with extras. A lot of people run some version of System V. These are all supported products, and Computer Centers love to run those. In "independent" computer centers (run by a particular lab or department) people run whatever they want. Of course, you'll find 8th and 9th Edition running in computer centers in Research, where they come from. But it's far from being widespread. Our computer center has a collection of Vaxen from 750s to 8650s and they all run 4.3 BSD. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
mjr@osiris.UUCP (Marcus J. Ranum) (11/25/87)
In article <1311@puff.wisc.edu>, kailhofe@puff.wisc.edu (Andrew D. Kailhofer) writes:
]
] It doesn't work because the cd is one the few things that are really don in
] the kernel (you won't find /bin/cd anywhere), and the kernel doesn't
] like to alias the things that it does. What it thins you are doing is
] trying to cd to somewhere, but when it starts to get the somewhere, it finds
] an unknown and unlookedfor '(', and barfs
Oh, yeah ? Gee, that's one on me. Stupid kernel. How embarrassing :-P
] Andrew D. Kailhofer |507 VanVleck Hall | This third left
] Systems Consultant |Madison, WI 53706 | blank for reasons
Consultant ? I sure won't hire you.
--mjr();
--
"We're fantastically incredibly sorry for all these extremely unreasonable
things we did. I can only plead that my simple, barely-sentient friend and
myself are underprivileged, deprived and also college students."
- Waldo "D.R." Dobbs.gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/26/87)
In article <2277@homxc.UUCP> wel@homxc.UUCP (Winston Lee) writes: >In article <6721@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >> ... There are many other interesting things in the Research UNIX systems >> that have not (so far) appeared in the commercial UNIX System V product. >Details please Well, I'm not sure what good it will do, and I don't want to spend a lot of time on this, but here is a partial list of interesting Ninth Edition goodies that, so far as I know, are not found in any commercial UNIX release. Please don't bug me for further details, however. shell functions exported via environment enhanced version of "awk" improved typesetter support, including "pp" pretty-printer, citation and bibliography preprocessors (besides "refer"), script-driven document generator, and the "ideal" complex plane-based picture-drawing language a version of "cat" that has no options B-tree utilities and subroutines C++ compiler, library, and header files C interpreter "cyntax" & "cem" C syntax checker ("lint" replacement) reasonable remote-execution facility interactive directory editor "printf" formatted-echo utility superior process control/debugging facilities based on a process file system "hoc" interactive floating-point language interactive file comparison line-by-line profiler for C and Fortran-77 "mk" replacement for "make" automatic software distribution facilities (not BSD "rdist") interactive frame-buffer image editor Datakit support Ricoh scanner support various support for the mail system several handy shell programming utilities, including a sequence generator Snocone programming language TeX text formatter and typesetter support data communication protocol analyzer display of movie of a function of x,y,t (utility and library functions) Writer's WorkBench support for WWV-synchronized clock fast buffered I/O library (like stdio) garbage-collecting storage allocation functions functions for breaking a string into fields IPC library map projection generators expanded plot library and file format new variants of popen() PORT mathematical library for Fortran new formatted print routines more rational internet, TCP, and UDP support a variety of unique stream modules, line disciplines, etc. standardized bitmap and pixel file formats several games, including air traffic control and bridge various dictionaries, thesaurus, etc. Bell Labs library services interface a variety of digitized map databases and utilities macros to typeset bitmaps and cover sheets astronomical sky catalog and utility private/corporate phone book support PDP-11 cross-compilation support utility to find all processes using a specified device enhanced system/process status information utilities "upas" mail delivery system And there is a slew of software for AT&T (Teletype) model 5620 Dot-Mapped Display terminals that is not included in the packages commercially licensed by AT&T: "mux" stream-based terminal controller support for capturing portions of bitmaps in files, printing them, etc. "brush" and "paint" painting programs support for grayscale images, notably face icons, including a "vismon" variant of "sysmon" that shows visages of people who have sent you mail; also a network face server "flicks" movie graphics editor for combinatoric graphs font editor "ped" interactive drawing program "pi" spiffy debugger (along the lines of dmdebug but more so), including debugging host processes as well as DMD ones a "ruler" for measuring things on the screen "sam" editor with structural regular expressions and mouse support special H-P ThinkJet printer utilities and functions hierarchical menu support "pads" user interface package for browsing a network of windows "crabs" (as reported in September 1985 Scientific American) "gebaca" and "pengo" arcade games menu dropper to aid in setting up screen dumps for documentation purposes road-map display
esj@beach.cis.ufl.edu.UUCP (11/26/87)
In article <137@anumb.UUCP> eao@anumb.UUCP (e.a.olson) writes: > no - cd is done in the shell itself. Not the kernel. > Well, of course, everything interesting is done in the kernel; > but I think that in the sense you use it , shell is more appropriate. > > eric olson > ihnp4!mvuxq!eao Well, not exactly. The concept of current working directory is very much in the kernel of every unix system i've encountered. The shell uses the chdir system call to tell the kernal to change it. The problem is that the (standard) bourne shell evaluates something like PS1=$CWD or PS1=`pwd` once. At the point it encounters it. What you need to do is modify it (bourne shell) to evaluate that variable each time it uses it. Best-o-Luck. -- In Real Life: UUCP: ...ihnp4!codas!ufcsv!beach.cis.ufl.edu!esj Eric S. Johnson II Internet: esj@beach.cis.ufl.edu University of Florida esj@ufl.edu
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/27/87)
In article <9354@ufcsv.cis.ufl.EDU> esj@beach.cis.ufl.edu (Eric S. Johnson) writes: >The problem is that the (standard) bourne shell evaluates something >like PS1=$CWD or PS1=`pwd` once. At the point it encounters it. What >you need to do is modify it (bourne shell) to evaluate that variable >each time it uses it. Best-o-Luck. What garbage! If you want the time (or load average or ...) embedded in your prompt, then it would indeed want to be evaluated every time it is printed. However, since the only way to effect a change of current working directory in the shell is via the "cd" builtin, the prompt can be kept up to date with embedded CWD if some way can be found to make the "cd" command update $PS1. For the vanilla SVR2 Bourne shell, this is not possible (for "cd"), because builtins cannot be redefined. However, one could get in the habit of using some other shell function name such as "cwd" to change working directory, where "cwd" is defined as: cwd(){ if [ $# -lt 1 ] then cd else cd "$1" fi PS1=`pwd`'$ ' } If you have the "builtin" shell builtin, then you can name the above function "cd" and change the two occurrences of "cd" to "builtin cd". The "builtin" builtin is found in the 8th & 9th Edition UNIX and the BRL SVR2 Bourne shells. This is the approach we use in our fancy "myx"/630/BRL shell-based working environments. Very cozy. If you have a pre-SVR2 Bourne shell, then you probably don't have support for shell functions and you are indeed stuck, since chdir() done in a subshell (e.g. a shell script) will not affect the parent shell. (You could source the script, however, but that isn't as convenient as typing a 2- or 3-letter command name.)
ruiu@tic.UUCP (Dragos Ruiu) (11/28/87)
[discussion is about how to print your working directory as your prompt]
There is a way to do it, and it's not pretty.
You can use a different agent to change directories, and have that agent
change your prompt.
I'm not exactly sure how you would like to do this on the bourne shell, but
you could write a little script to perform all cd's... and use this script
instead of the cd. You could get as fancy as you like, all it would take
is retraining your fingers.
So you would use mycd instead of cd when you want to change directories,
and mycd would change your prompt too. I used a little kluge like this on
VMS to emulate the MS-Clunk :-) 'set prompt $p$g' setup.
On VMS I called it cd, but under bourne you would would have to call it
something else because the builtin cd takes precedence.
[On a related note, anybody know if Microport fixed the cwd bug in c-shell
in 2.3 or when they will bother to actually ship mine :-( ]
--
Dragos Ruiu Disclaimer: My opinons are my employer's, I'm unemployed!
UUCP:{ubc-vision,mnetor,vax135,ihnp4}!alberta!edson!tic!dragos!work
(403) 432-0090 #1705, 8515 112th Street, Edmonton, Alta. Canada T6G 1K7
Never play leapfrog wa, a, athat
nonreggie@pdnbah.UUCP (11/30/87)
In article <3217@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >In article <7972@steinmetz.steinmetz.UUCP> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: >>Being at an R&D lab, I expect a company's research version of >>something to be beyond what it sells. However, at USENIX a few years >>ago when Edition 8 was the AT&T research version, AT&T employees gave >>the impression that a release of Edition 8 was in widespread use >>within AT&T, not just at BTL. >I don't have hard numbers, but I doubt 8th Edition is in "widespread" >use, even in Bell Labs. Most of the Computer Centers in Bell Labs >run something called "R&D Unix" which is System V based, with extras. >A lot of people run some version of System V. >These are all supported products, and Computer Centers love to run those. Quite true! 8th Edition suposedly is quite difficult for a system administrator to play with and requires much more care than System V or BSD. >In "independent" computer centers (run by a particular lab or department) >people run whatever they want. Of course, you'll find 8th and 9th Edition >running in computer centers in Research, where they come from. I spent the last four years working for an organization within Bell Communications Research where we had "independent" computer labs as well as access to Bellcore Computer Center machines (system V). In our labs we ran BSD-based systems, including 8th Edition. The reason we had 8th Edition was that the original lab for our project was running 8th Edition on a dozen DEC VAX 11/750's with a Datakit Switch. At the time of the divestiture of the Bell System we were entitled to keep 8th Edition. Since that time the lab has been moved to another building, the Datakit was trashed, and most of the 750's are now either converted over to System V or are being used as paper weights! However, there still is one or two systems running 8th Edition, albeit an unsupported version. This is in Piscataway, NJ. I also understand that Brian Redman has a lab in Morristown running 8th Edition as well. I don't know if legally, Bellcore has any further rights to new developments under 8th or 9th Edition. I doubt it. I was a wonderful system to develop under. However, the capacity of the 750's and the general difficulty of obtaining third party software for 8th Edition, eg. database manager, has made 8th Edition's life at one lab in Bellcore minimal. I feel it is a real shame. 8th Edition is far superior to the commercial product from AT&T. George W. Leach Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826
john@frog.UUCP (John Woods, Software) (12/01/87)
In article <6736@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <2277@homxc.UUCP> wel@homxc.UUCP (Winston Lee) writes: > >In article <6721@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > >> ... There are many other interesting things in the Research UNIX systems > >> that have not (so far) appeared in the commercial UNIX System V product. > >Details please > ...here is a partial list of interesting Ninth Edition goodies... > ... > a version of "cat" that has no options This is probably the single greatest achievement of Computer Science to date. 1/2 ;-) "And if you order before midnight tonight, you get the real-leather-bound, three volume set of the ls manual page ABSOLUTELY FREE!" -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw@eddie.mit.edu "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart
snoopy@doghouse.gwd.tek.com (Snoopy) (12/01/87)
In article <840@nesac2.UUCP> jec@nesac2.UUCP (John Carter ATLN SADM) writes: >In article <7936@steinmetz.steinmetz.UUCP>, stpeters@dawn.steinmetz (Dick St.Peters) writes: >> *9*th Edition? Just how far has AT&T carried this "Edition" stuff >> while I've been out of touch? Last I knew (admittedly some time ago), >> mere customers were supposed to settle for SYSV while Edition 8 was >> for AT&T internal use. That a company won't use its own product >> doesn't exactly help it push that product as a standard ... >But the internal use 'Edition' is (eventually) the next revision of >the 'commercial' product. >The internal Editions are not always a product you'd want to use in >production - how many guru's of what degree do you have for local >support? :-) Plenty of people were running various unsupported versions long before AT&T offered support. Where do you think Unix got it's reputation? From system V? <cough> Perhaps you don't care to do your own support, but lots of people *are* willing to do their own support, and would like to be able to use some of the stuff in v8/v9. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
jc@minya.UUCP (John Chambers) (12/04/87)
After reading all the flames about the difficulty of getting a prompt
from the Bourne shell showing the current directory, I decided to see
if it was possible. It took about 5 minutes to determine that, yes,
it is possible, but you just might not like the solution.
Here's a script that I put into a convenient public directory under
the name "d":
cd $d;PS1="$d: "
How do you use this little sucker? Like this:
d=/foo/bar . d
which puts you in /foo/bar and gets you the prompt:
/foo/bar:
If you want to get back to your home directory, you might type:
d= . d
and you get just a ":" prompt. Lovely, isn't it? (;-)
Now I know that y'all would much prefer a sane syntax like that of "cd".
Well, you're just plumb out of luck, I guess. I haven't thought it out
yet, but I believe I can make a good argument that, with the generic
Bourne shell (i.e., no aliases or functions), you can't implement the
right syntax for this operation.
If someone out there can come up with a solution, I'd like to see it.
Feel free to use my weird script if you wish; I won't consider it to
be plagiarism if a good solution is built on mine.
[This is almost as much fun as real mathematics! :-]
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)