Bug 131010

I suppose apps with the behaviour you describe are sufficiently rare that you can do the following for them:
1. Right click in konqueror
2. Go to "Create new" -> "Link to application"
3. On the "application" tab, set the work path to the directory you want the app to run in

Thanks for your reply.

I do know about this method; but I think it's sometimes not very convinient for common users. Also, 99% of Windows programs have a behavior like this, so I think users will also unable to double-click the .exe files (to run it under Wine) directly in Konqueror.

And the GNOME file manager does change the directory into where the program is located before executing it. I don't want to start a GNOME vs. KDE flame war though :)

Thanks,
Wei Mingzhi

I ran into a similar issue using "Open using...".  I wanted to right click a file, use "Open with..." -> "Other...", and have the program output go to the same directory as the input file.  Unfortunately, the output went to $HOME instead, because $HOME was set as the working directory.  I expected the working directory to be set to the directory of the input file.

In other words, when I do the following from "konqueror":

1.  Start file manager
2.  Double click folder
3.  Right click file, select "Open with...", select "Other...", enter application name "foo"

my expectation was that it would be like doing the following from "konsole":

1.  Start "konsole"
2.  Enter "cd folder;ls"
3.  Enter "foo file"

Instead, it sounds like it is more like:

1.  Start "konsole"
2.  Enter "ls folder"
3.  Enter "foo folder/file"

To make this even more confusing, if I select "Show terminal emulator" or "Open terminal", it sets the current working directory to the displayed directory, not $HOME.  So some processes do seem to have their working directory reset when launched from Konqueror.

Personally, I think it makes more sense to treat opening a folder as "cd folder;ls" instead of "ls folder".

I was able to work around the problem by entering:

cd %d;foo %f

I would like the working directory to be changed as well. It's really nice when testing applications in my home directory.

I guess this is same as: https://bugs.kde.org/show_bug.cgi?id=157215
Fixing this would allow execution of script files by simply double-clicking them. I once accidentally nuked my home directory because of this wrong working directory passed to my script!

I am going to close this as INVALID if there are no further comments.

The problem is that the current directory is the directory that is used to access data files.  So, it is set to the Documents Directory as default.  If an application needs a different directory, then this needs to be set either in the 'desktop' file or in the script.

@James - Why'd you close the bug because there are 'no more comments'? Enough comments have been posted. And the current working directory is *NOT* the Documents directory, it's the user's home directory.
The report (and the comments) suggest that the home directoty of the executable be set to the same directory from where it was invoked (from Dolphin / Konqueror).

I can reopen it if I am convinced by further comments that it is valid.

This general issue has been addressed and it was decided that as the default that the working directory, when an application was launched using the KDE GUI, would be the Documents Directory.

Note that as a default that the Documents Directory is set to $HOME, but it can be changed in the Control Center (KDE3):

     System Administration -> Paths

or System Settings (KDE4):

     About Me -> Paths

Or, this can be changed in the 'desktop' file with: 'Path='.

When scripts are started directly, the current directory is set to $HOME.  That is probably a bug.

However, we do not want all programs starting with the current directory set to the directory where they are located.  For example if I have KWrite here:

     /usr/kde/bin/kwrite

I do not want it started with the current directory set to:

     /usr/kde/bin

because I do NOT want to store any data files in that directory and users shouldn't even have write access to that directory.  I want the current directory set to the Documents Directory.  Note that Documents Directory is a poor name but it wasn't changed when KDE4 was started, so we are stuck with it -- better to call it the UserFiles Directory. :-)

So, I recognize that there may be a problem with scripts and you are welcome to open a new bug for the specific case where a script is started by clicking on it in Konqueror.  However, a script can easily find where it lives with:

     program_name="$0"
     current_dir=`dirname "$progname"

so, I don't see this as a large issue.

IMHO, the case of /usr/kde/bin/kwrite is not comparable. And even in that case, if someone navigates to /usr/kde/bin (in Dolphin) and then clicks on kwrite, then there's nothing wrong in /usr/kde/bin being the current wd.

One use case is when I've a 'clean' script file in my project directory. When  double click that file, I expect it to run on that directory, deleting whatever needs to be deleted.
In fact I had done exactly this, and got my home directory wiped out!

Moreover, I just confirmed that a batch file in Windows get's the directory from which it was doubleclicked in explorer as its WD. I'm not saying that's a reference behaviour, but it sure makes things easier. I believe the way GNOME does is the same as KDE.

Re: Comment #9

> there's nothing wrong in /usr/kde/bin being the current wd.

Actually, there is something seriously wrong with that.  When the file selection dialog opens for loading or saving a file, the default directory is the "wd".  This is not acceptable.

> I expect it to run on that directory

The thing is that *NIX doesn't work that way.  You should really have the script in your $HOME/bin/ directory, but that means that you would have to open a Konsole to run it.  But, in that case, it would work as you expect.

However, as I said, you can have a script work that way as long as you start it with:

     program_name="$0"
     current_dir=`dirname "$progname"
     cd $current_dir

Re: Comment #10

While I would not say that *NIX should, in general, work the same as Windows, a case can be made that when you run a script by clicking on it that the Working Directory should be set to the location of the script.  However, this should only apply to scripts.  It should not be the general case that includes executable binaries.  If you think that that is how it should work.  Please open a new bug for just that -- this is a KDE3 bug and, therefore, I don't think that it should be recycled.

> Actually, there is something seriously wrong with that.  When the file
> selection dialog opens for loading or saving a file, the default directory is
> the "wd".  This is not acceptable.

Don't forget that the user, for some wierd reason, chose to navigate (in a file manager) to /usr/kde/bin and execute kwrite! It's not invoked from the menu, or a shortcut or from krunner.


> The thing is that *NIX doesn't work that way.  You should really have the
> script in your $HOME/bin/ directory, but that means that you would have to
> open a Konsole to run it.  But, in that case, it would work as you expect.

How about the use-case I posted in Comment #9? Should the current generation *NIX graphical environments make it mandatory to use the shell just to run a script? Yup, I do get the irony of it being a 'shell script' to begin with. :-)


> case can be made that when you run a script by clicking on it that the Working
> Directory should be set to the location of the script.  However, this should
> only apply to scripts.  It should not be the general case that includes
> executable binaries.

Can the file manager always correctly identify a script from a binay executable? Even then, I guess there are a lot of graphical programs which use a shell-script for startup.

Re: Comment #12

Perhaps I didn't give a good example.  A realistic example would be that the user clicked on an executable in $HOME/bin/.  Pepole probably actually do that.  I would expect the same behavior as if I started the application from the menu or a desktop icon; I would not expect the Working Directory to be set to $HOME/bin/ when starting a binary file that way.

> Should the current generation *NIX graphical environments make it mandatory 
> to use the shell just to run a script?

In a word: NO!  You can run a script by clicking it, so you should expect that to work OK.  I note that you can also run a script by using a 'desktop' file which would probably be better, but I don't do it that way either unless I need a script to start a binary after changing the environment.  So, you should expect the same behavior if you use the Konsole as if you click.  

The problem is that I'm not sure if this is possible.  If I start a script in the Konsole you are going to expect that the Working Directory will not change, but if you start it by clicking, the working directory is going to change to the location of the script.  I guess that is OK since the working directory can change when you start with the GUI and a 'desktop' file.

> Can the file manager always correctly identify a script from a binay

I can't say for sure.  However, I am sure that if it doesn't identify the file as a text file to be interperted by an interperter (Bash, Ruby, Perl, etc.) that it isn't going to be run.  Currently something different is happening because for a binary the Working Directory is set to the Documents Directory and for Bash scripts it is set to $HOME.  You won't notice the difference if you haven't set the Documents Directory to something other than the default (which is $HOME).

> Re: Comment #13
> If I start a script in
> the Konsole you are going to expect that the Working Directory will not 
> change, but if you start it by clicking, the working directory is going to
> change to the location of the script.

When invoked from the console, the working directory is the directory *from* which you invoked the script. We both agree on that being the standard behaviour.
Similarly, when invoked from a file manager, the working directory must also be the directory *from* where it is invoked. Don't think of it as 'the location of the script'. Think of it as the 'location from which the script is invoked' (same as Konsole case), which, for a file manager, is same as the 'location of the script'.
Once you start to think that way, why would the filemanager pass $HOME as the working directory, when Konsole doesn't? IMO, it'd make sense for Dolphin to also pass the current directory as the working directory, as done by Konsole (or any shell).

I don't think the open file dialog box is a critical issue, as when user do this in a terminal:

cd /usr/bin
./kwrite

...which is essentially the same thing as "navigating to /usr/bin and clicking the executable", and s/he will still get /usr/bin as the default directory for dialog box (like #3 said).

However, the problem is, no one will actually do the above thing, so does clicking the executable in /usr/bin.

IMHO having to creating a desktop file or a script, or I'll not be able to run many programs is kinda inconvient (I can name some other GNU/Linux programs which reads required data or libraries from the working directory).

btw, just a note, I just confirmed (in KDE 3.5.10), if I do something like this:

cd /usr/lib
/usr/bin/konqueror

and then any binaries I clicked in the opened Konqueror window will have /usr/lib as working directory.

Re: Comment #15

"I can name some other GNU/Linux programs which reads required data or libraries from the working directory"

I have to say that such programs should be able to determine where they live if they want to read data files.  SO Libraries are a different issue.  If the library directory isn't in the /etc/ld.so.conf file then you need to add it to: LD_LIBRARY_PATH.

There are certain conventions for running binary *NIX programs which I fully realize don't apply to PCDOS and MS-Windows.   IMHO, programs that do not follow these conventions, other than with the possible exceptions of games, are basically broken.  Such broken programs can be fixed with a script or a 'desktop' file.

However, I see your point that a script started by clicking on it -- something which I never do -- should expect that the working directory would be the directory where it lives.

Re: Comment #16

Yes, when you use the Konsole, the working directory is the directory where your currently are.  I hope the everybody can agree that that is the expected behavior.

The issue which remains unresolved is what should happen when you start a binary program by directly clicking on it.  I note that this is probably not a really good idea although I do it when installing software.  I can only state my preference here which is that the working directory should be set to the Documents Directory.  The only exception being a shell script.  Yes, it is true that when your run a binary program with the command line in a Konsole that the working directory is where you are -- not where the probram lives unless that is where you are.  

I do not have a strong preference since I don't normally do this.  I normally make a script and/or a 'desktop' file as part of installing software.

here's a patch on this:

for kdelibs/kio/kio/krun.cpp:

pid_t KRun::runCommand( const QString& cmd, const QString &execName, const QString & iconName )
{
  kdDebug(7010) << "runCommand " << cmd << "," << execName << endl;
  KProcess * proc = new KProcess;
  proc->setUseShell(true);
  *proc << cmd;
  KService::Ptr service = KService::serviceByDesktopName( binaryName( execName, true ) );
+ QStringList args = KShell::splitArgs( cmd );
+ for (QStringList::ConstIterator it = args.begin(); it != args.end(); ++it)
+   if (!(*it).contains('='))
+     proc->setWorkingDirectory((*it).mid(0, (*it).findRev('/')));
  return runCommandInternal( proc, service.data(), binaryName( execName, false ), execName, iconName );
}

hope this can be helpful for those who would like to get this behavior.

Did the patch above get applied to the current $vcs head?  Could this be reopened until a patch which changes the current working directory to the one opened in the Konqueror window gets applied?

We're hitting this with our software, which tries to find corresponding data files (GLSL shaders) paired in the current directory.  Users are reporting this on openSUSE 11.1 (among other distros, likely) and after considerable debugging it turns out this current directory problem is the root issue.

If there's no interest in changing the default $pwd for this, could perhaps some warning be issued to the user?  I've received this report many times now and have never been able to figure it out until a user physically collocated with me demonstrated the behavior.  With any luck, my users would mention, "btw, KDE gives me this warning when I start the app..." in future bug reports.

(In reply to comment #19)
> Did the patch above get applied to the current $vcs head?  Could this be
> reopened until a patch which changes the current working directory to the one
> opened in the Konqueror window gets applied?
> 
> We're hitting this with our software, which tries to find corresponding data
> files (GLSL shaders) paired in the current directory.

This behaviour is so annoying. But for some reason, the devs don't agree. The same use-case has been clearly put in comment #9, comment #14 & comment #15. We too experience the same problem with users complaining about not being able to launch the executable directly (GNOME 'launchers' don't even have an option to specify a working directory in the .desktop files).

Can some other dev please consider implementing this? As said in Comment #19 & Comment #20, this is quite a major irritation with applications that are not distributed as 'packages' (where binaries go to */bin and files go to some other directory - the *NIX way).
In my work-place, for example, we usually distribute our internally developed apps as a tar-ball that contains the executable as well as the supporting files. When started, the program looks for the supporting files in it's working directory.