Hallo Ben,
I've sent already an answer to this mail, but it seems that it never
got out...
* Ben Burton wrote:
>If writing it in Perl means we're more confident in its correctness in
>all cases, I say let's do it.
I have no idea about perl, so it's either my sh or someone elses perl :)
>After all, this is a script that will be
>used by *every* Java package.
In this case it doesn't matter if it is written in sh or perl: The
interface to the java startscripts will be the *output* (to stdout),
not any array or env-variable. Neither perl nor sh will let you
preserve 'words' there, it will all be one big string and the starter
script will have the control if that gets broken into words or not
(via quoting).
Another thing is, how you actually would write up this arguments, that
they are treated in that way. The only thing which comes to my mind is
writing it in perl itself, so that the 'java-config files' will be
includeable (or whatever accessable) from 'perl-findjava'. Another
thing would be XML...
To access this information would also mean that we have to write every
starter script in perl, as otherwise we don't have a way to pass this
information on. This would mean that a java maintainer has to learn
perl before he can package a java app. Ok, I had to learn sh, but
still...
Anyway, all this is IMO overkill, as in most cases it will include
some *very* simple arguments like '-server' or '-enable-jit' and in
most cases (=default), it will simple drop only one 'word', which will
be the java binary. I don't think that we have to worry about
'usr/bin/java command' (not the space in the file name...).
There is already anought to make 'black magic' a little brighter, so I
won't comment on that :) Oh, man bash has some nice para about it :)
So, how are we going on from here? Should I start writing the
bugreport against java-common?
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
