From owner-freebsd-hackers Thu Mar 6 19:12:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA06163 for hackers-outgoing; Thu, 6 Mar 1997 19:12:01 -0800 (PST) Received: from squirrel.tgsoft.com (squirrel.tgsoft.com [207.167.64.183]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA06144 for ; Thu, 6 Mar 1997 19:11:57 -0800 (PST) Received: (from thompson@localhost) by squirrel.tgsoft.com (8.8.5/8.6.12) id TAA03817; Thu, 6 Mar 1997 19:10:42 -0800 (PST) Date: Thu, 6 Mar 1997 19:10:42 -0800 (PST) Message-Id: <199703070310.TAA03817@squirrel.tgsoft.com> From: mark thompson To: james@wgold.demon.co.uk CC: hackers@freefall.freebsd.org In-reply-to: message from James Mansion on Thu, 06 Mar 1997 10:49:10 +0000 Subject: Re: java support under FreeBSD. Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: James Mansion Date: Thu, 06 Mar 1997 10:49:10 +0000 I have a suggestion wrt 'foo'class' rather than 'foo'. Would it be possible to write a layered filter file system and mount it onto some part or parts of the main system so that, if I try to stat or open 'foo', and 'foo' does not exist but 'foo.class' doesn't, then I see a read-only executable file called 'foo', maybe one that has contents '#!/somewhere/java foo.class' or therabouts? James aaaarrrgggghhhhh. This is getting worse and worse. Instead of bloating the kernel, how about about adding it to execvp (or whatever we can get the shells to agree on). You could even have it driven by a file in /etc... # exec wrapper for the shells... java % "java %.class -various magic params" perl % "perl %.pl" ... -mark