Return to BSD News archive
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!psgrain!newsfeed.internetmci.com!EU.net!sun4nl!rnzll3!sys3.pe1chl!rob From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Ideal filesystem X-Newsreader: NN version 6.5.0 (NOV) Reply-To: pe1chl@wab-tis.rabobank.nl Organization: PE1CHL Message-ID: <DpA18x.2EK@pe1chl.ampr.org> References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4j0bmo$ftv@park.uvsc.edu> <jlemonDoqBq5.1Bx@netcom.com> <4jerrj$f12@park.uvsc.edu> <jlemonDp1GFM.H4I@netcom.com> <4jpjb6$77c@park.uvsc.edu> Date: Wed, 3 Apr 1996 08:07:44 GMT Lines: 55 Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20490 comp.unix.bsd.freebsd.misc:16460 In <4jpjb6$77c@park.uvsc.edu> Terry Lambert <terry@lambert.org> writes: >] >For a "binary" that was a directory, there is a need to search >] >every directory in every directory in the path for "a.out" or >] >whatever you call your actual non-fork binary. >] >] Um, no. If the directory has an 'executable' bit, then the search stops there, >] and the the actual binary within the directory is _assumed_. This gives the >] same behavior that we have today. (yes, the actual binary may not be present - >] this would be discovered when the user attempts to execute the program, and >] would be handled the same way as a corrupted binary) >Bzzzzzzzzzzzzzzzzzzt.$home/bin >% set path = ( $home/bin $path /usr/X11/bin) >% rehash >% /bin/ls $home/bin >foo ls >% /bin/ls $home/bin/foo >a.out icon eattr1 eattr2 >% /bin/ls $home/bin/ls >icon eattr1 >% ls >ls: Command not found >In other words, the hash will be true, but the search will be >false -- and the wrong ls will be given. >Whereas if you looked for the a.out, you would avoid this problem. This is irrelevant, and it is already happening. Make a file $home/bin/ls, and put in it: #!/bin/blabla make it executable. see what happens. THE SAME THING! You have created an invalid executable in the search path, it will be executed by the shell, and when that fails you get an error message. When the name of the executable "hides" an existing system program, it will be executed instead of that program. This is all standard UNIX behaviour. Most programmers have gone through the confusion resulting from writing a program "test" and leaving it in some own directory, causing miscellaneous other things to fail... Rob -- +------------------------------------+--------------------------------------+ | Rob Janssen rob@knoware.nl | BBS: +31-302870036 (2300-0730 local) | | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU | +------------------------------------+--------------------------------------+