Le lun 29/04/2002 � 12:58, Stefan Bodewig a �crit : > On 26 Apr 2002, Nicolas Mailhot <[EMAIL PROTECTED]> wrote: > > > I started auditing it to find what's wrong and ended up tweaking > > most of it. So here is the result. > > I wonder what caused the problems - we've had reports about stuff that > needed to be quoted and we've obviously not quoted everthing that > could be quoted (you've shown several places we forgot to touch), but > most of your other changes are either (1) replacing `` with $() > or (2) replacing > > if [...] then > command > fi > > with [...] && command > > While (2) is a question of style (and I prefer ours, YMMV),
Well, (2) is mostly to shrunk the size of these ifs, I've found it's much easier to miss redundant/conflicting assigments when they are separated by half a screen worth of fis. > we cannot > perform (1) if it is bash specific (I think it is). Do you know > whether Korn Shell supports this? Damn, didn't think about this. No I don't know. I do know bash doc marks ` as a deprecated construct, I don't use it because I find this kind of fly dung easy to miss, but I have no idea about ksh support (or not). Can any ksh user comment on this ? > I'm totally opposed to removing the AIX hack as it would break > backwards compatibilty. People don't need to set JAVACMD on AIX right > now. Well, as you've wrote it's a hack and I really don't think we should support all non-standard jvm layouts in the main script (plus it's a hellhole when you have many application scripts to support like we do at jpackege). Or else we should migrate to use the unified java-functions file we've been writing at jpackage right now (this was one of the jpackage's middle-term plan anyway) so this hack could be shared with tomcat and other java apps. As a short-term solution, we could reintroduce the hack with a clear warning it will be depracated in ant's next version, and users of such insane jvms should set JAVACMD (either in their env or in one of ant's config files). > > a sane clathpath builder (i.e. first jvm jars, then core ant jars, > > then local classpath). > > I'm not sure whether we could run into difficult to track down > backwards incompatibilities if we change the order of CLASSPATH. Why > do you think that putting tools.jar at the front is more sane than > putting it at the end? I really think internal jvm jars are important to the sanity of the system and should not be put lightly at the end of the classpath. But that's not the reason I changed this (while nice it's a purely cosmetic fix if no one reports any bug). If core ant jars (i.e the jaxp parser) are loaded in the classpath after the local classpath and the local classpath contains saxon jars the style task will bomb because it will detect the �lfred parser first, and this parser is not supported. Since I use saxon a lot, it's one of my pet bugs and I had it corrected in the rpms (both jakarta and jpackage) for ages before this script reintroduced it. The moving of tools.jar was only a side-effect of this correction (btw jpackage order right now is core ant jars, jvm jars, local classpath i.e. slightly different) Regards, -- Nicolas Mailhot
signature.asc
Description: PGP signature
