Date: Tue, 4 Mar 1997 11:26:04 -0800 (PST) From: "William R. Somsky" <somsky@dirac.phys.washington.edu> To: hackers@freefall.freebsd.org Subject: Re: java support under FreeBSD. Message-ID: <199703041926.LAA24593@dirac.phys.washington.edu> In-Reply-To: <199703040550.VAA26081@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Mar 3, 97 09:50:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Terry Lambert <terry@lambert.org> > > > - I can't see any decent way to automagically execute <name>.class when > > a user types <name>. If typing <name>.class is considered ok, why > > is typing 'java <name>' not? If the solution is to add a soft link, > > why not write a two-line script at once and avoid the need for kernel > > support altogether? > > There is no way to do this, short of hacking the shell, or doing the > expression expansion for path expressions in the kernel, rather than > in the shell (there are a lot of good reasons you'd want to do this, > actually, but it's complicated unless you do it precisely the right > way when you do it). Hmm... Although it would be useful, I'd argue that any path/extention/etc expansion does _not_ belong in the kernel's implementation of 'exec'. The kernel is told to 'exec' a specified _file_ by name. Now, it would IMHO, be valid for it to do whatever is necessary to execute _that_ file, but it shouldn't go groveling around to find some other file, otherwise you get into the problem (annoyance, possible trojan horse attack) where "/bin/foo" _used_ to be a valid command, but got deleted, or chmod -x'd, and then an exec of "/bin/foo" finds a completely different "/bin/foo.class" instead, with no warning whatsoever. Not good. SUID wrappers where you explicitly exec a file by full pathname, then get this unforseen vulnerability. Now, rather than making any 'file extension search' capability part of exec(2), where, as I argued above, it shouldn't go, the more reasonable place to put it (if you want it) is in execlp(3) and execvp(3) which are already doing searches through the PATH. Searches through extensions would logically go in the same place. However, I'd also argue against having _any_ "entention search" capability in either the system library _or_ any standard shell as being to "DOS-y" and not in the Unix spirit. If we have the command "foo" find and run the java "foo,class", do we also want "bar" to find and run the script "bar.sh" or (yuuch) "bar.bat"? And I've still seen people who insiste on compiling their program "bletch.c" into "bletch.exe" -- should "bletch" then find and run "bletch.exe"? And what about search order? What if you ask to run "blotch" and there exists /bin/blotch.class, /usr/bin/blotch, /usr/local/bin/blotch.sh, and ~/bin/blotch.exe? > I have no problem with "name.class"... if someone does, then they > need to rename their "exectuable" to "name" instead of "name.class". I agree with this. > > - If the kernel only keeps track of a single CLASSPATH (via sysctl or > > whatever), the user is limited to the code locations supported by > > the sysadmin. Kind of not being able to set my own PATH, uck :-( > > Maybe the kernel CLASSPATH should be appended to the users?? > > Yes. This is what I would suggest. The sysctl CLASSPATH is the > "default path". > > I would maybe go so far as to say that if the user specifies a CLASSPATH, > it should override, entirely, the sysctl CLASSPATH for invocations by > that user. Hmm... could we do something like one of the TeX implementations (Karl Berry's, and it might carry ofer into Thomas Esser's) does? A fully specified CLASSPATH (or perhaps EXECCLASSPATH if you want to keep it separate from other uses of CLASSPATH by netscape and other non-kernel uses) overrides the sysctl CLASSPATH, but if there is a leading/trailing/ doubled-internal ":", the sysctl CLASSPATH is inserted into that point. So if I just want to add my ~/bin/java to thefront of the EXECCLASSPATH, I just "setenv EXECCLASSPATH ~/bin/java:" Hmm... But do we really want a kernel(2) item to be reading stuff from the environment? Does any other "section-two" call use environmental information? If not, I'd argue against using any env info here. ________________________________________________________________________ Dr. William R. Somsky somsky@phys.washington.edu Department of Physics, Box 351560 B432 Physics-Astro Bldg Univ. of Washington, Seattle WA 98195-1560 206/616-2954
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703041926.LAA24593>