Re: [ jEdit-devel ] Re: "settings" command line argument

[Randall R S. <rs...@so...>]

Ted,

Java does not really support the notion of a current working directory, 
at least not in a way that matches that of common operating systems. 
It's best to avoid it entirely. Consider, for example, the fact that 
there is nothing to ensure that the current directory in effect when 
your script is launched will be the current directory of that script.

No matter what system you deploy to, it is possible to obtain the actual 
installation directory within the script used to invoke the actual Java 
code. This is the best way to make your script + Java program position 
independent.

I pointed out how to do it on Linux. The same or something very similar 
will work on MacOS X (which is a FreeBSD Unix system). Likewise, 
Windows BAT files also have this capability in some form (I just don't 
know what it is). (Likewise for Unix shell scripts executed under 
Windows using MKS or Cygwin). Using this approach is the best way 
around this characteristic of late-model jEdits that is giving you 
trouble.

Randall Schulz


On Sunday 23 January 2005 17:00, tkosan wrote:
> Slava wrote:
> > No, its not a bug, I was just confused. The 4.2 behavior is
> > correct.
>
> I am trying to understand how the 4.2 behavior makes sense for
> applications that use JEdit as a base framework (like mine is :-)
>
> I want the user to download a .zip file, unzip it anywhere they would
> like and then execute a batch file or shell script in order to launch
> the application. I want the application to come up using initial
> settings that I have pre-configured in the settings directory which
> is in the same directory as the launch script.  I do not want to
> touch the user's home directory in any way at this time.
>
> Since I do not know where the user is going to unzip the zip file to
> I can not hardwire a complete path to my pre-configured settings
> directory in the launch script.
>
> The -Duser.home=. technique is okay as a temporary workaround but if
> my application ever wants to access the user's home directory in the
> future I do not know where it is now.
>
> To me, ./ means relative to the current directory.  If I put ./ in
> front of a directory that I pass through the settings argument, it
> should mean that the directory is relative to the directory where
> jedit was launched from.
>
> I can understand how giving a complete path in the settings argument
> will allow the home directory default to be overridden and I can also
> understand how passing a directory without ./ in front of it will
> always be relative to the home directory default.
>
> I don't yet understand, however, why ./ can not mean from where jedit
> is launched from, especially since my application needs this behavior
> :-)
>
> Ted
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive
> Reporting Tool for open source databases. Create drag-&-drop reports.
> Save time by over 75%! Publish reports on the web. Export to DOC,
> XLS, RTF, etc. Download a FREE copy at
> http://www.intelliview.com/go/osdn_nl