Setting working directories for applications?

[Igor Tarasov]

Hello.

This might be a known issue, but anyway: Some windows applications
need that shortcut (launcher) have working directory set, and that
working directory sometimes different from where the .exe is located.

In Linux, with gnome and kde it is not a big problem, since .desktop
launchers in these DE support Path attribute. But this becomes a
problem with systems that don't support this out of box.

As good as I am aware, XFCE have this problem - it's launchers ignore
path attribute. Also, AFAIK, there are similar problems with mac
version. There might be problems in other desctop enviroments, but I
am not aware of these.

Currently the only way to lauch such applications is either to use
terminal and cd to working directory and then run application, or
create custom bash launcher, which is too complicated for not
experienced users (I mean not to reproduce it step-by-step, but to
solve it by themselves).

Is there anything that could be done in this area?

[Jeff Zaroyko]

On Sun, Apr 12, 2009 at 4:29 PM, Igor Tarasov  wrote:
> Hello.
>
> This might be a known issue, but anyway: Some windows applications
> need that shortcut (launcher) have working directory set, and that
> working directory sometimes different from where the .exe is located.
>
> In Linux, with gnome and kde it is not a big problem, since .desktop
> launchers in these DE support Path attribute. But this becomes a
> problem with systems that don't support this out of box.
>
> As good as I am aware, XFCE have this problem - it's launchers ignore
> path attribute. Also, AFAIK, there are similar problems with mac
> version. There might be problems in other desctop enviroments, but I
> am not aware of these.
>
> Currently the only way to lauch such applications is either to use
> terminal and cd to working directory and then run application, or
> create custom bash launcher, which is too complicated for not
> experienced users (I mean not to reproduce it step-by-step, but to
> solve it by themselves).
>
> Is there anything that could be done in this area?
>
> --
> Igor

Hi Igor

There is Wine's start.exe which takes a /Unix option to start the
supplied file in unix path form, which both sets the working directory
and provides the commandline double quoting quirk which Windows
Explorer does.  So, instead of cd ~/.wine/drive_c/foo && wine bar.exe,
you can wine start /Unix ~/.wine/drive_c/foo/bar.exe

I think this is already used as part of DE, see tools/wine.desktop,
perhaps it would be a good idea to fix whatever is broken in XFCE and
others.

Jeff

[Igor Tarasov]

Hi Jeff
> There is Wine's start.exe which takes a /Unix option to start the
> supplied file in unix path form, which both sets the working directory
> and provides the commandline double quoting quirk which Windows
> Explorer does.  So, instead of cd ~/.wine/drive_c/foo && wine bar.exe,
> you can wine start /Unix ~/.wine/drive_c/foo/bar.exe

Well, I've already have looked into start.exe, and it does not provide
functionality I need.

Look: we have some program, prog.exe It is located it
~/.wine/drive_c/foo/ . But it needs it's working dir to be set to
~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way:

cd ~/.wine/drive_c/foo/bar
wine ../prog.exe

Start.exe won't help here, as I don't see any path-related options there.

When installing such application, wine woul convert .lnk into .desktop
that look like this (irrelevant options skipped):

[Desktop Entry]
Name=Da Prog
Exec[$e]=env WINEPREFIX="/home/user/.wine-wt" wine "C:\foo\prog.exe"
Path[$e]=$HOME/.wine/dosdevices/c:/foo/bar

XFCE ignores Path attribute, and prog.exe won't launch or would
complain it can't find some files and needs to be reinstalled.

Mac also have some problems with this.

BTW, according to freedesktop specification Path attribute is optional.
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-lates...

[James McKenzie]

Igor Tarasov wrote:
> Hi Jeff
> > There is Wine's start.exe which takes a /Unix option to start the
> > supplied file in unix path form, which both sets the working directory
> > and provides the commandline double quoting quirk which Windows
> > Explorer does.  So, instead of cd ~/.wine/drive_c/foo && wine bar.exe,
> > you can wine start /Unix ~/.wine/drive_c/foo/bar.exe
>
> Well, I've already have looked into start.exe, and it does not provide
> functionality I need.
>
> Look: we have some program, prog.exe It is located it
> ~/.wine/drive_c/foo/ . But it needs it's working dir to be set to
> ~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way:
>
> cd ~/.wine/drive_c/foo/bar
> wine ../prog.exe
>
> Start.exe won't help here, as I don't see any path-related options there.
>
> When installing such application, wine woul convert .lnk into .desktop
> that look like this (irrelevant options skipped):
>
> [Desktop Entry]
> Name=Da Prog
> Exec[$e]=env WINEPREFIX="/home/user/.wine-wt" wine "C:\foo\prog.exe"
> Path[$e]=$HOME/.wine/dosdevices/c:/foo/bar
>
> XFCE ignores Path attribute, and prog.exe won't launch or would
> complain it can't find some files and needs to be reinstalled.
>
> Mac also have some problems with this.
>
> BTW, according to freedesktop specification Path attribute is optional.
> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-lates...

The problem is that you are technically working in Windows and the
working directory may need to be set in the registry.  Please look at
this in a working Windows configuration.  I have found in these cases
that using regedit and duplicating the setup does tend to work.

And the fact that you are using a Mac does not have anything to do with
this situation, it is a 'broken' feature of Windows that Wine has to
reproduce properly.

James McKenzie

[Igor Tarasov]

2009/4/12 James McKenzie :
> The problem is that you are technically working in Windows and the
> working directory may need to be set in the registry.

Why? And where? Working directory in cases I've seen is specified in .lnk file.

Wikipedia: "Generally the effect of double-clicking a shortcut is
intended to be the same as double-clicking the application to which it
refers, but Windows shortcuts contain separate properties for the
target file and the "Start In" directory. If the latter parameter is
not entered, attempting to use the shortcut may generate "missing DLL"
errors not present when the application is accessed directly"
> Please look at this in a working Windows configuration.

I don't have windows box at hand, but I'll check that as soon as I can.

In my opinion, there are two ways to solve this:

1) depend on DE, creating .desktop or alias or whatever, and hope that
it would work. And we know that at least in XFCE it won't, and since
Path parameter is optional in freedesktop specification, there might
be more DEs where we'll have this problem.

2) create some kind of internal functionality so that wine could
reproduce .lnk behavior without need in relying on DE.

For instance, wine could associate itself with .lnk files (don't know
why, but I don't like this idea).

Or we could save all lnk files somewhere and have some tiny command
like wine /path/to/link.lnk that would read all options from .lnk file
and change working dir/do whatever required and launch the
application.

Currently wine can't launch .lnk files.

Another way to do this is to add optional parameter to wine, say
"--workdir", and wine would convert lnk to .desktop, but save StartIn
parameter not in Path, but in command line:

wine --workdir /work/dir /path/to/exe

[Igor Tarasov]

> Currently wine can't launch .lnk files.

I was wrong:

wine start /path/to/lnk.lnk

[Mikołaj Zalewski]

> Well, I've already have looked into start.exe, and it does not provide
> functionality I need.
>
> Look: we have some program, prog.exe It is located it
> ~/.wine/drive_c/foo/ . But it needs it's working dir to be set to
> ~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way:
>
> cd ~/.wine/drive_c/foo/bar
> wine ../prog.exe
>
> Start.exe won't help here, as I don't see any path-related options there.

Using:

wine start 'c:\windows\Start Menu\My App\App.lnk'

ususally does the trick. However, this can also be hard for a novice to 
guess.

Mikołaj Zalewski

[Rein Klazes]

On Sun, 12 Apr 2009 11:29:06 +0500, you wrote:
> Currently the only way to lauch such applications is either to use
> terminal and cd to working directory and then run application, or
> create custom bash launcher,

Third option:

In the existing launcher instead of:

wine "X:\pathto\program.exe"

change to:

sh -c 'cd somepath && wine "X:\pathto\program.exe"'

Works here using Gnome. Not very user-friendly either perhaps.

Rein.

[Damjan Jovanovic]

On Sun, Apr 12, 2009 at 8:29 AM, Igor Tarasov  wrote:
> Hello.
>
> This might be a known issue, but anyway: Some windows applications
> need that shortcut (launcher) have working directory set, and that
> working directory sometimes different from where the .exe is located.
>
> In Linux, with gnome and kde it is not a big problem, since .desktop
> launchers in these DE support Path attribute. But this becomes a
> problem with systems that don't support this out of box.
>
> As good as I am aware, XFCE have this problem - it's launchers ignore
> path attribute. Also, AFAIK, there are similar problems with mac
> version. There might be problems in other desctop enviroments, but I
> am not aware of these.

The Path attribute is definitely NOT optional. Its presence in a
.desktop file is optional ("If a key is OPTIONAL it may or may not be
present in the file" -- the spec), but a desktop must never ignore it
if it is given.
> Is there anything that could be done in this area?

You should file a bug with XFCE and any other buggy desktops.

Do our .desktop files even work on Mac?
> --
> Igor

Damjan

[Austin English]

On Tue, Apr 14, 2009 at 8:02 AM, Damjan Jovanovic  wrote:
> Do our .desktop files even work on Mac?

Out of curiousity, do we have testcases for this stuff? E.g., will it
show up as failing on platforms that don't support it on
http://test.winehq.org/ ?