Hallo Ben,
I have no idea, *when* my mail will arrive at the list (the last mails
took four days each :( ), but anyway...
* Ben Burton wrote:
>Right. So when you have single command-line arguments that could
>contain spaces and/or quotes, things can become very hairy very quickly.
Yes. Bot are
Hallo Ben,
I have no idea, *when* my mail will arrive at the list (the last mails
took four days each :( ), but anyway...
* Ben Burton wrote:
>Right. So when you have single command-line arguments that could
>contain spaces and/or quotes, things can become very hairy very quickly.
Yes. Bot are
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 :)
>Afte
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 :)
>Afte
> Bash (that's what it is written in currently. But I guess, that plain
> sh isn't different here) will seperate all 'words' in your
> commandline, if you don't quote them. Words in this case means,
> everything, which is seperated by one of the chars in $IFS.
Right. So when you have single comm
> Bash (that's what it is written in currently. But I guess, that plain
> sh isn't different here) will seperate all 'words' in your
> commandline, if you don't quote them. Words in this case means,
> everything, which is seperated by one of the chars in $IFS.
Right. So when you have single comm
Hallo Ben,
* Ben Burton wrote:
>On the other hand, Perl deals with things like quoting and other
>problems resulting from unanticipated command-line arguments somewhat
>better than sh does (e.g., you can start the JVM by passing its
>command-line arguments as an array, not by some piece of sh blac
Hallo Ben,
* Ben Burton wrote:
>On the other hand, Perl deals with things like quoting and other
>problems resulting from unanticipated command-line arguments somewhat
>better than sh does (e.g., you can start the JVM by passing its
>command-line arguments as an array, not by some piece of sh blac
Hallo Grzegorz,
* Grzegorz B. Prokopski wrote:
>Is anyone willing to create "Debian Java_Home" document draft?
>Or maybe you don't like the idea?
Before you do that, please read the discussion, which has taken place
since my first proposal. The first one did try to mandate a
'java-environment' an
In message: <[EMAIL PROTECTED]>
"T. Alexander Popiel" <[EMAIL PROTECTED]> writes:
>
>Inserting and/or modifying does get complex; shift and unshift
>and modifying IFS quickly become instrumental.
That should be '...shift and set and modifying...'. Today has
not been a good day for a
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>> FWIW, the black magic is "$*" (including the quotes).
>
>Do you mean "$@"? If so, this (and "$*") become somewhat more
>troublesome when you need to modify command-line arguments or insert
>your own.
Yes, I
Hallo Grzegorz,
* Grzegorz B. Prokopski wrote:
>Is anyone willing to create "Debian Java_Home" document draft?
>Or maybe you don't like the idea?
Before you do that, please read the discussion, which has taken place
since my first proposal. The first one did try to mandate a
'java-environment' an
Hallo Ean,
* Ean Schuessler wrote:
>For instance, I can now set JAVA_HOME on my machine to /usr/lib/kaffe
>and run the standard startup scripts for Catalina, JBoss or OFBiz and
>they will make a real attempt to run. Of course, there are still
>shortfalls in the base class libraries but that is a
In message: <[EMAIL PROTECTED]>
"T. Alexander Popiel" <[EMAIL PROTECTED]> writes:
>
>Inserting and/or modifying does get complex; shift and unshift
>and modifying IFS quickly become instrumental.
That should be '...shift and set and modifying...'. Today has
not been a good day for a
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>> FWIW, the black magic is "$*" (including the quotes).
>
>Do you mean "$@"? If so, this (and "$*") become somewhat more
>troublesome when you need to modify command-line arguments or insert
>your own.
Yes, I
> FWIW, the black magic is "$*" (including the quotes).
Do you mean "$@"? If so, this (and "$*") become somewhat more
troublesome when you need to modify command-line arguments or insert
your own.
Ben.
Hallo Ean,
* Ean Schuessler wrote:
>For instance, I can now set JAVA_HOME on my machine to /usr/lib/kaffe
>and run the standard startup scripts for Catalina, JBoss or OFBiz and
>they will make a real attempt to run. Of course, there are still
>shortfalls in the base class libraries but that is a
> FWIW, the black magic is "$*" (including the quotes).
Do you mean "$@"? If so, this (and "$*") become somewhat more
troublesome when you need to modify command-line arguments or insert
your own.
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Co
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>[...] some piece of sh black magic
>that gets the quotes right and separates arguments - some of which
>may contain spaces - at exactly the right places [1]).
FWIW, the black magic is "$*" (including the quotes
In message: <[EMAIL PROTECTED]>
Ben Burton <[EMAIL PROTECTED]> writes:
>
>[...] some piece of sh black magic
>that gets the quotes right and separates arguments - some of which
>may contain spaces - at exactly the right places [1]).
FWIW, the black magic is "$*" (including the quotes
> What is findjava going to be written in again? Perl? That would suck if
> that's the case. Surely we can find a way to launch a Java language
> runtime without using the Perl language runtime.
On the other hand, Perl deals with things like quoting and other
problems resulting from unanticipated
> What is findjava going to be written in again? Perl? That would suck if
> that's the case. Surely we can find a way to launch a Java language
> runtime without using the Perl language runtime.
On the other hand, Perl deals with things like quoting and other
problems resulting from unanticipated
Hallo Etienne,
* Etienne Gagnon wrote:
>libraries in /usr/lib/sablevm, and its executable in /usr/bin. Where
>shouls JAVA_HOME point? [rhetorical question]
Mandated by the new policy would be to point the JVM property
(System.get...) java.home to /usr/lib/sablevm. In there should be
the 'java-s
Hallo Etienne,
* Etienne Gagnon wrote:
>libraries in /usr/lib/sablevm, and its executable in /usr/bin. Where
>shouls JAVA_HOME point? [rhetorical question]
Mandated by the new policy would be to point the JVM property
(System.get...) java.home to /usr/lib/sablevm. In there should be
the 'java-s
On Mon, 2003-09-22 at 13:32, Ean Schuessler wrote:
> We want Java programs to run the interpreter using a common commandline
> and directory layout. Many Java programs rely on the JAVA_HOME layout
Well - it's abvious that we *don't want* every single program to
separately support each single JVM.
On Mon, 2003-09-22 at 13:32, Ean Schuessler wrote:
> We want Java programs to run the interpreter using a common commandline
> and directory layout. Many Java programs rely on the JAVA_HOME layout
Well - it's abvious that we *don't want* every single program to
separately support each single JVM.
We want Java programs to run the interpreter using a common commandline
and directory layout. Many Java programs rely on the JAVA_HOME layout
even though it is an ill-defined non-standard. The path of least
resistance is to formalize a definition of this standard and then tune
up the behavior of pa
We want Java programs to run the interpreter using a common commandline
and directory layout. Many Java programs rely on the JAVA_HOME layout
even though it is an ill-defined non-standard. The path of least
resistance is to formalize a definition of this standard and then tune
up the behavior of pa
Hallo Ean,
* Ean Schuessler wrote:
>> After having this discussion, because they are not 'similar enough' to
>> rely on the alternative system.
>Well, they *could be* similar enough if we specify exactly what Debian
>expects a JAVA_HOME setup to provide.
It's not the java.home or anything else. T
Dalibor Topic wrote:
I think that JAVA_HOME is quite pointless, as the only good use for it
seems to
be to locate JNI headers. It's an ill-defined ad-hoc 'standard' that isn't even
supported by Sun. Programs that rely on JAVA_HOME to be able to access
internals of the VM are inherently broken, the
Hallo Ean,
* Ean Schuessler wrote:
>> After having this discussion, because they are not 'similar enough' to
>> rely on the alternative system.
>Well, they *could be* similar enough if we specify exactly what Debian
>expects a JAVA_HOME setup to provide.
It's not the java.home or anything else. T
Dalibor Topic wrote:
I think that JAVA_HOME is quite pointless, as the only good use for it seems to
be to locate JNI headers. It's an ill-defined ad-hoc 'standard' that isn't even
supported by Sun. Programs that rely on JAVA_HOME to be able to access
internals of the VM are inherently broken, they
--- Ean Schuessler <[EMAIL PROTECTED]> wrote:
> I'm still not clear on why we cannot require every VM to provide a more
> specifically detailed version of the JAVA_HOME ad hoc standard. We
> should have a document that lists all of the $JAVA_HOME/bin/..foo..
> $JAVA_HOME/lib/..bar.. locations tha
--- Ean Schuessler <[EMAIL PROTECTED]> wrote:
> I'm still not clear on why we cannot require every VM to provide a more
> specifically detailed version of the JAVA_HOME ad hoc standard. We
> should have a document that lists all of the $JAVA_HOME/bin/..foo..
> $JAVA_HOME/lib/..bar.. locations tha
On Sun, 2003-09-21 at 17:03, Jan Schulz wrote:
> sh. bash in this case, as I have not enough knowledge to make sure
> thats 'sh-only'.
Well, we can count on bash being there so that's ok.
> After having this discussion, because they are not 'similar enough' to
> rely on the alternative system.
On Sun, 2003-09-21 at 17:03, Jan Schulz wrote:
> sh. bash in this case, as I have not enough knowledge to make sure
> thats 'sh-only'.
Well, we can count on bash being there so that's ok.
> After having this discussion, because they are not 'similar enough' to
> rely on the alternative system.
Hallo Ean,
* Ean Schuessler wrote:
>What is findjava going to be written in again? Perl?
sh. bash in this case, as I have not enough knowledge to make sure
thats 'sh-only'.
>I'm still not clear on why we cannot require every VM to provide a more
>specifically detailed version of the JAVA_HOME a
Hallo Ean,
* Ean Schuessler wrote:
>What is findjava going to be written in again? Perl?
sh. bash in this case, as I have not enough knowledge to make sure
thats 'sh-only'.
>I'm still not clear on why we cannot require every VM to provide a more
>specifically detailed version of the JAVA_HOME a
What is findjava going to be written in again? Perl? That would suck if
that's the case. Surely we can find a way to launch a Java language
runtime without using the Perl language runtime.
I'm still not clear on why we cannot require every VM to provide a more
specifically detailed version of the
What is findjava going to be written in again? Perl? That would suck if
that's the case. Surely we can find a way to launch a Java language
runtime without using the Perl language runtime.
I'm still not clear on why we cannot require every VM to provide a more
specifically detailed version of the
Hallo Dalibor,
* Dalibor Topic wrote:
>Hm, this is another 'stupid by design' issue. Sun has specified jni.h but
>hasn't specified the contents of jni_md.h. So it shouldn't be needed to build
>JNI apps. But Sun's jni.h apparently includes jni_md.h without specifying its
>search path. Unfortunately
Hallo Dalibor,
* Dalibor Topic wrote:
>Hm, this is another 'stupid by design' issue. Sun has specified jni.h but
>hasn't specified the contents of jni_md.h. So it shouldn't be needed to build
>JNI apps. But Sun's jni.h apparently includes jni_md.h without specifying its
>search path. Unfortunately
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> >> The 'findjava' algo was described in one of my mail.
> >Hmm, I remember seeing it but I don't remember anyone suggesting that it
> >be made compulsory.
>
> Dalibor argued quire havily for it :)
Yes, I did. I think if debian had a java runtime selec
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> >> The 'findjava' algo was described in one of my mail.
> >Hmm, I remember seeing it but I don't remember anyone suggesting that it
> >be made compulsory.
>
> Dalibor argued quire havily for it :)
Yes, I did. I think if debian had a java runtime selec
Hallo Ben,
I like academic discusions :)
* Ben Burton wrote:
>> * editors or other interactive things (telnet, www-browser)
>> * different version of the same tool (autoconf, gcc, shells)
>> * apps which do not require commandline apps (x-session-manager)
>> * things which behave the same (x-curs
Hallo Ben,
I like academic discusions :)
* Ben Burton wrote:
>> * editors or other interactive things (telnet, www-browser)
>> * different version of the same tool (autoconf, gcc, shells)
>> * apps which do not require commandline apps (x-session-manager)
>> * things which behave the same (x-curs
> IMO the 'alternative system' is not used for this. Looking what
> alternatives are installed in my system, they are either
> * editors or other interactive things (telnet, www-browser)
> * different version of the same tool (autoconf, gcc, shells)
> * apps which do not require commandline apps (
> IMO the 'alternative system' is not used for this. Looking what
> alternatives are installed in my system, they are either
> * editors or other interactive things (telnet, www-browser)
> * different version of the same tool (autoconf, gcc, shells)
> * apps which do not require commandline apps (
Hallo Ben,
* Ben Burton wrote:
>> So we understand something differen when we talk about the
>> 'alternative system' :). IMO your usecase would be called 'default
>> system'.
>Hmm? By "alternative system' I'm talking about packages using
>update-alternatives in thier postinst scripts, etc.
me to
> >Well, IMO the alternative system exists so that users don't need to
> >learn how each different package works around it in its own different
> >way. Instead it provides a standard system for setting system-wide
> >defaults.
>
> So we understand something differen when we talk about the
> 'alt
Hallo Ben,
* Ben Burton wrote:
>> So we understand something differen when we talk about the
>> 'alternative system' :). IMO your usecase would be called 'default
>> system'.
>Hmm? By "alternative system' I'm talking about packages using
>update-alternatives in thier postinst scripts, etc.
me to
Hallo Ben,
I've just uploade a new java_scripts.tar.gz package, with all the
changes from today:
* included the /etc/... possebility
* the old scripts still refered to 'package.jars' files insetad of just
'package'
* instead of the jars files I added a unit test script:
test_java-scripts. Edit
Hallo Ben,
* Ben Burton wrote:
>Well, IMO the alternative system exists so that users don't need to
>learn how each different package works around it in its own different
>way. Instead it provides a standard system for setting system-wide
>defaults.
So we understand something differen when we ta
> >Well, IMO the alternative system exists so that users don't need to
> >learn how each different package works around it in its own different
> >way. Instead it provides a standard system for setting system-wide
> >defaults.
>
> So we understand something differen when we talk about the
> 'alt
Hallo Ben,
I've just uploade a new java_scripts.tar.gz package, with all the
changes from today:
* included the /etc/... possebility
* the old scripts still refered to 'package.jars' files insetad of just
'package'
* instead of the jars files I added a unit test script:
test_java-scripts. Edit
Hallo Ben,
* Ben Burton wrote:
>Well, IMO the alternative system exists so that users don't need to
>learn how each different package works around it in its own different
>way. Instead it provides a standard system for setting system-wide
>defaults.
So we understand something differen when we ta
> IMO you don't need to use teh alternative system, if you just 'work
> around' it. YMMV...
Well, IMO the alternative system exists so that users don't need to
learn how each different package works around it in its own different
way. Instead it provides a standard system for setting system-wide
Hallo Ben,
* Ben Burton wrote:
>We're talking about using it by default _if_and_only_if_ it's in the
>list of known working JVMs. This is exactly the same thing you were
>wanting from the findjava script. Your argument about incompatible JVMs
>is not relevant to the point at hand, and if it were
> IMO you don't need to use teh alternative system, if you just 'work
> around' it. YMMV...
Well, IMO the alternative system exists so that users don't need to
learn how each different package works around it in its own different
way. Instead it provides a standard system for setting system-wide
Hallo Ben,
* Ben Burton wrote:
>We're talking about using it by default _if_and_only_if_ it's in the
>list of known working JVMs. This is exactly the same thing you were
>wanting from the findjava script. Your argument about incompatible JVMs
>is not relevant to the point at hand, and if it were
60 matches
Mail list logo
