Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!atha!lsuc!jimomura From: jimomura@lsuc.on.ca (Jim Omura) Newsgroups: comp.sys.atari.st Subject: Re: Gemini Standard Usages Message-ID: <1991Jun1.214409.18541@lsuc.on.ca> Date: 1 Jun 91 21:44:09 GMT References: <1991May31.184317.26514@lsuc.on.ca> Organization: Consultant, Toronto Lines: 67 In article entropy@gnu.ai.mit.edu (maximum entropy) writes: >In article <1991May31.184317.26514@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: >>Also, I have no idea what they are intending to use the "CDPATH" >>for. I've never seen it on a Unix system or an OS-9 system and >>I don't know what program would look for it. Is that supposed to >>be a path for CD Rom applications? > >I don't use Gemini, but I do know what CDPATH is, from using ksh and >bash. The CDPATH variable contains a list of directories to scan for >a directory name given to the 'cd' command. For example, if my CDPATH >is ":/usr:/usr/entropy:/usr/bob/pub/bin/bsd4.3/recreation" then >if I type "cd games" the shell will: > >1) cd to ./games if it exists (some shells don't do this if you have a CDPATH) >2) otherwise, cd to /usr/games if it exists >3) otherwise, cd to /usr/entropy/games if it exists >4) otherwise, cd to /usr/bob/pub/bin/bsd4.3/recreation/games if it exists > >CDPATH is very useful if you have long paths to very common storage >areas and don't like typing them all the time. > This point has become sort of interesting. If you read exactly what I said, it was a sort of a trick comment. Truth is, I was being sarcastic. I did realize that they were using it to define a search path for an empty 'cd' call. Truth is, also that I really haven't seen CDPATH used personally (though apparently it's 'csh' as well as 'ksh'. What I was getting at though is that it's not classic Unix standard because 'sh' simply looks for HOME. Though I'm starting to wonder now if some versions of 'sh' might have been re-written to go either way. But I was getting at a couple of points, albeit in retrospect, in an overly cleverly manner. First, it's simply unnecessary. If you think about the purpose of HOME and the purpose of CDPATH, they are essentially duplcations of each other. Second, as I pointed out earlier in my message, the Gemini team doesn't seem to understand what HOME is for, and if they did, they would have realized the unnecessary duplication. And I was hoping that it would become clear, in a Zen sort of way that unnecessary clutter in the environment is to be avoided. And also, as I said in my earlier posting, if you don't get your standard uses properly organized, you end up writing applications that look in the wrong places for things. For example, if you have one fellow using CDPATH and HOME for different purposes arbitrarily and someone else somewhere else using them differently, you could wind up with 2 applications that conflict. Like if 1 is looking for a '.signature' file in your HOME directory which is '/usr/grp1/user1' but CDPATH is 'usr/projects/contract1'. After all, if you have both then why not use them? Now if you're going to *look* like you're copying Unix usages, then you better be careful that you get some idea what standard usages really are. And that may go beyond the manuals. And I guess in this case I suggest that people simply define CDPATH=${HOME} unless they have a really good reason not to do so. And thinking about it, the best definition for the CONSOLDIR (I think that's what it was called) is simply "." rather than whatever they did (I think they set the console directory to the GEMINI directory or something like that). But it was really sloppy of me. I rarely post things so deliberately obscure, and frankly I just plain botched it. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura