jimomura@lsuc.on.ca (Jim Omura) (06/01/91)
I've been working with Gemini off and on for a while now and I hope somebody can pass these comments to the programming team. It's all regarding the "mupfel.mup" file: HOME is defined as the current "gemini" directory. This is a bad practice. You should tell people to define "HOME" to their current "working directory", whereever that is. On a Unix system, my normal HOME directory would generally be something like "/usr/mygroup/jimomura". This is the directory in which I do my usual work. The thing to emphasize is that it has *nothing* to do with the operating system or executables. In fact, it's mainly just text data files of my own concern. If you don't learn this concept early on your going to scr*w up your system organization by writing programs that look to the wrong places for the wrong things. 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? -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura
entropy@gnu.ai.mit.edu (maximum entropy) (06/01/91)
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. entropy -- entropy@gnu.ai.mit.edu entropy. . .it's not just a good idea, it's the second law. Boycott Lotus, Apple, Ashton-Tate and Xerox. Join the League for Programming Freedom! Write to league@prep.ai.mit.edu for more information.
jimomura@lsuc.on.ca (Jim Omura) (06/02/91)
In article <ENTROPY.91Jun1090434@pogo.gnu.ai.mit.edu> 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
bill@mwca.UUCP (Bill Sheppard) (06/02/91)
In article <1991May31.184317.26514@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes:
->I've been working with Gemini off and on for a while now and
->I hope somebody can pass these comments to the programming team.
->It's all regarding the "mupfel.mup" file:
...
->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?
If I recall, CDPATH is the path that mupfel will search when you type
"CD directory". It's sort of like Norton CD under DOS - you can type "CD
directory" without a partition letter and CD will look on the various paths
specified by CDPATH for that directory name, regardless of which drive it is
on.
--
##############################################################################
# Bill Sheppard -- bills@microware.com -- {uunet,sun}!mcrware!mwca!bill #
# Microware Systems Corporation --- OS-9: Seven generations beyond OS/2!! #
######Opinions expressed are my own, though you'd be wise to adopt them!######geert@ahds.ahold.nl (Geert W.T. Jonkheer CCS/TS) (06/03/91)
In article <1991May31.184317.26514@lsuc.on.ca>, jimomura@lsuc.on.ca (Jim Omura) writes: > > I've been working with Gemini off and on for a while now and > I hope somebody can pass these comments to the programming team. > It's all regarding the "mupfel.mup" file: > > Stuff deleted... > > 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? > -- CDPATH is not for CD Rom applications, it is very handy if you are using several disk partitions. You can tell gemini where to look for a directory name when you do a 'cd Directory'. It's also very handy when you are using a lot of directories. For example, if you are using the partitions C..F and you have a directory called 'UTILITY' and is located on drive E:, CD looks for the directory 'UTILITY' on drive E: only if you have specified drive E: in CDPATH (CDPATH=C:\;D:\;E:\;F:\). When you are for example in the directory 'C:\EDITOR\WORDPLUS\DOCS' and you do a cd UTILITY, gemini will succeed in finding it. When GEMINI finds it, it also prints the full path of the directory. Hope you now know where CDPATH is use for. Geert.
ue@nathan.ruhr.de (Udo Erdelhoff) (06/03/91)
In article <1991Jun1.214409.18541@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: > > 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, Sorry, but that's wrong. CDPATH defines a list(!) of directories where Gemini should search for the directory given as argument in the cd command. It's something similar to the PATH variable, which gives a list of directories where Gemini should search for the given command. I'll show you an example, perhaps you'll understand it more easily: Imagine you have a folder structure like this: c:\btx\ c:\btx\macros\texts\ c:\btx\macros\grphics\ c:\btx\pages\german\ c:\btx\pages\englisch\ c:\fido\ c:\fido\out\ c:\fido\in\ Now suppose you are currently working in d:\fido\out and want to change into c:\btx\macros\texts\ to examine a text. Normally, you'd have to type in the full path in order to get there. If you are using CDPATH, you can set: setenv CDPATH='.,c:\,c:\btx\,c:\btx\macros\,c:\btx\pages\,c:\fido\,d:\' etc. Now all you've got to type is "cd texts" and gemini will cd to c:\btx\macros\texts. Got it? This is very powerful tool, you'll save a lot of work, especially if you would normally be forced to use long paths... The list in searched from left to right, so it's a good idea to put the '.' in first place. Thereby Gemini will search in the current directory first. /s/ PS: Are You using the english or the german version of Gemini? Take a look at mupfel.doc, they explained the reason for CDPATH quite good. -- Udo Erdelhoff smart: ue@nathan.ruhr.de Am Westheck 170 Fido: Udo Erdelhoff on 2:245/52.1 W-4600 Dortmund 12 (FRG) Maus: Udo Erdelhoff @ DO Please keep your replies short - I have to pay for recieving mail
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) (06/03/91)
In article <1991Jun1.214409.18541@lsuc.on.ca>, jimomura@lsuc.on.ca (Jim Omura) says: > 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 Please explain: for what reason did you WANT to be sarcastic? >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 And BaSH, by the way... >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 Wrong. $HOME is the home directory of the user. As long there is no multi-user GEMDOS, there really is no need for soemthing like that on the Atari. $CDPATH however is a _list_ of paths, used only for `cd'. And, finally: why don't you take a look in other shells like BaSH, which also have $HOME and $CDPATH. Why don't you send your sarcastic comments to Brian Fox. Why didn't you send constructive comments???? >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. Again: $HOME points to a directory, $CDPATH is similar to $PATH -- it's a list of paths. How _could_ they both be used for the same purpose? > > 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. > In fact. >-- >Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 >lsuc!jimomura >Byte Information eXchange: jimomura ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
Lutz_Frank@ac2.maus.de (Lutz Frank) (06/04/91)
Hi Jim,
JO>Also, I have no idea what they are intending to use the "CDPATH"
JO>for. I've never seen it on a Unix system or an OS-9 system and
JO>I don't know what program would look for it. Is that supposed to
JO>be a path for CD Rom applications?
... the environment variable CDPATH is a Mupfel-feature, I think.
It is used to define where a "CD" (change dir) command - used in the
shell - should preferably look first.
Just a short look into the documentation ... (please excuse my
translation ;-))
cd [dir]
Changes to directory dir. Without arguments the value of
$HOME will be used. Dir may contain a drive specification
(eg. C:\BIN). If there is an CDPATH defined and a change
to dir is not possible, then Mupfel puts dir
at the end of each CDPATH-entry and tries to change
directory at this path.
example: cd TEST
path TEST not found
CDPATH defined as C:\FIRST, D:\SECOND
now Mupfel tries to make a
cd C:\FIRST\TEST
and cd D:\SECON\TEST
before issuing an 'dir not found' error
Kind regards
Lutz