Thanks for the bug report! I can reproduce this in the master branch (the file 'quxqux.txt' isn't created in 'Documents', but in  the home directory in my case, but that's still not what we want).

*** Bug 274256 has been marked as a duplicate of this bug. ***

The place in Dolphin where the script gets launched is in DolphinViewContainer::slotItemTriggered(const KFileItem& item); that function calls 'item.run()'. Then KFileItem::run(...) uses KRun to execute the script, where the working directory is set to KGlobalSettings::documentPath() in KRun::runCommand(...).

It seems that this was done intentionally (see bug 108510). It might be desirable to set the working directory to 'Documents' in some cases, but IMHO not for shell (or Perl/Python/...) scripts launched from Dolphin.

One possibility to resolve this would be to implement overloaded functions KFileItem::run(...) and KRun::KRun(...) that allow to pass the working directory from DolphinViewContainer.

@David: Do you have a better idea how to resolve this issue?

Hi Folks,

the idea that the WM determines where the current directory is, is simply mad. The current directory and the Documents directory have nothing in common and it should not be mixed up, this is Unix and not M$. To determine the document save path is part of the application logic and cannot be worked around with the PWD.

Since this seems to be broken in KDE4 in general, I would at least vote for fixing this when applications are started from konqueror or dolphin, if possible.
A distinction by file type would be another source of bugs. Why does KDE not set an environment variable, say $DOCUMENTPATH, and if it is not set then the application uses $HOME. All applications can be started with the correct PWD and fine. 
Would this not be resolveable in the core FileOpen Dialogs and the like?

Why do we care so much? You cannot graphically call any script's, since they don't know where they are started. (even setting the path=. in the desktop file does not work).

Regards,
  Georg

Created attachment 62120 [details]
Fix for this problem

This patch changes the working directory of launched file to currently active dolphin directory.

Thanks for the patch, but it doesn't compile for me - there is no matching member function in KFileItem.

*** Bug 282909 has been marked as a duplicate of this bug. ***

Created attachment 64035 [details]
Additional patch to kdelibs

(In reply to comment #6)
> Thanks for the patch, but it doesn't compile for me - there is no matching
> member function in KFileItem.

Oops forgot to attach kdelibs patch :)

Thanks for the quick reply and the kdelibs patch!

The approach looks good overall (but note that I'm not the maintainer of that code, so this still needs to be reviewed by other people).

There is a little problem though: If this patch should be included in kdelibs 4.x (and not only in the frameworks branch), binary compatibility must be maintained (see [1] for details).

Essentially, this means that you cannot add new parameters to a function, even if they have default values -> you need to add a new function, which has one parameter more. In the .cpp files, you can keep your modified functions though, and just add a small function with the old signature that calls the new function.

If you have any questions about that, don't hesitate to ask :-)

Could you try to update your kdelibs patch and submit it to http://reviewboard.kde.org/ ?

[1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

Created attachment 64104 [details]
New patch

Change my patch so that kdelibs changes are not required.

> Thanks for the quick reply and the kdelibs patch!
>
> The approach looks good overall (but note that 
> I'm not the maintainer of that code, so this
> still needs to be reviewed by other people).
>
> There is a little problem though: If this
> patch should be included in kdelibs
> 4.x (and not only in the frameworks branch), 
> binary compatibility must be maintained (see [1] for details).
>
> Essentially, this means that you cannot add new parameters 
> to a function, even if they have default values -> you need
> to add a new function, which has one parameter more. In 
> the .cpp files, you can keep your modified functions though,
> and just add a small function with the old signature
> that calls the new function.
>
> If you have any questions about that, don't hesitate to ask :-)
> 
> Could you try to update your kdelibs patch and submit it to
> http://reviewboard.kde.org/ ?
>
> [1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

Hm, actually I think that it is actually better to add the functionality to kdelibs, but I'm not the one who has the final say over that.

@Peter, David: do you have ideas about this?

I'm not sure - I'd also prefer if this is done in kdelibs instead of doing it on application level. David is very busy and usually cannot reply to bug-reports as he gets too much of them each day. The best thing to get this discussed by people who are more familiar with this topic than me is to provide a merge-request for kdelibs like Frank mentioned in comment #9. If the feedback there is that it should be done on application level then we will do this, otherwise interface issues etc. will get discussed on the reviewboard so that this can be pushed into kdelibs.

(In reply to comment #12)
> I'm not sure - I'd also prefer if this is done in kdelibs instead of doing it
> on application level. David is very busy and usually cannot reply to
> bug-reports as he gets too much of them each day. The best thing to get this
> discussed by people who are more familiar with this topic than me is to provide
> a merge-request for kdelibs like Frank mentioned in comment #9. If the feedback
> there is that it should be done on application level then we will do this,
> otherwise interface issues etc. will get discussed on the reviewboard so that
> this can be pushed into kdelibs.

I don`t think it is good idea to fix application bug/feature by creating API changes in some library(especially kdelibs). 
Plus if kdelibs changes are done they would require changes in dolphin too, so anyways we would have to fix it on dolphin too.

> I don`t think it is good idea to fix application bug/feature by
> creating API changes in some library(especially kdelibs). 

And this is exactly what is not clear for me: To me it looks like a general issue and not an application bug. Whether a fix in Dolphin is necessary or not is secondary to me: I'm fine doing a Dolphin only fix or doing a fix based on an added interface in kdelibs, but I need to be sure to do the "right thing" instead of introducing a workaround that might fail in other cases. For this I need the input of the maintainers from the KRun-interface (David) and we only get this by submitting a merge-request. It is also OK to submit a merge-request for Dolphin and add David Faure as review-person (as Konqueror is affected too by this).

Well, since this is only meaningful for local files, I would say that KFileItem could determine its parent directory all by itself, no need for an API change nor for changes in Dolphin.

Just do
if (d->m_bIsLocalUrl) {
    KUrl parent = url;
    parent.setPath(parent.directory());
    and pass parent.toLocalFile() to KRun.
}

Thanks David for the feedback, this sounds good.

@Tautvydas: Would you like to take care do apply David's proposal and submit a merge-request? That would be great but if you don't have the time I would take care for this.

(In reply to comment #16)
> Thanks David for the feedback, this sounds good.
> 
> @Tautvydas: Would you like to take care do apply David's proposal and submit a
> merge-request? That would be great but if you don't have the time I would take
> care for this.

Better you do that, couse I dont even have account at reviewboard.

Also wouldnt recommend changing kfileitem functionality this way couse probably lots of software depends on it.

Don't worry about reviewboard, what would really help is if you can make and test the patch :)

And don't worry about the KFileItem::run fix affecting other apps - it will, but that's the whole point. Anyone calling KFileItem::run should benefit from this bugfix (using the right current directory). I definitely wouldn't want a different behavior in other apps where the user can "run" a file item.

Created attachment 64363 [details]
patch for kdelibs

(In reply to comment #18)
> Don't worry about reviewboard, what would really help is if you can make and
> test the patch :)
> 
> And don't worry about the KFileItem::run fix affecting other apps - it will,
> but that's the whole point. Anyone calling KFileItem::run should benefit from
> this bugfix (using the right current directory). I definitely wouldn't want a
> different behavior in other apps where the user can "run" a file item.

Here is the patch. But it could only be done in KRun and not in KFileItem, so almost everything that uses KRun will be affected.

To me doing the patch in KRun instead of KFileItem::run() looks fine. @David: Is it OK if I commit the following change to KDE/4.7?

------------------------------- kio/kio/krun.cpp -------------------------------
index 0141a7c..c978576 100644
@@ -135,7 +135,7 @@ bool KRun::runUrl(const KUrl& u, const QString& _mimetype, QWidget* window, bool
     else if (isExecutableFile(u, _mimetype)) {
         if (u.isLocalFile() && runExecutables) {
             if (KAuthorized::authorize("shell_access")) {
-                return (KRun::runCommand(KShell::quoteArg(u.toLocalFile()), QString(), QString(), window, asn)); // just execute the url as a command
+                return (KRun::runCommand(KShell::quoteArg(u.toLocalFile()), QString(), QString(), window, asn, u.directory())); // just execute the url as a command

I think it is very bad idea to include this patch to 4.7, it should be included in at least 4.8 or 4.9

Patch looks good. I can't really think of a case where we might not want the url's directory as current directory in runUrl, so this looks safe.

Funny that you're pushing for it to be merged in later rather than sooner, usually people ask for the other way round :-)
But there's only 4.7.x and 5.x branches for kdelibs, so this should go into 4.7.x., it's a bugfix after all.

(In reply to comment #22)
> Patch looks good. I can't really think of a case where we might not want the
> url's directory as current directory in runUrl, so this looks safe.

Simple example is this shell script: touch test.txt

Before my fix it will create file in ~/Documents directory, after it will create in same directory as shell script

> Funny that you're pushing for it to be merged in later rather than sooner,
> usually people ask for the other way round :-)
> But there's only 4.7.x and 5.x branches for kdelibs, so this should go into
> 4.7.x., it's a bugfix after all.

It looks more like a feature to me, thats why it shouldnt be merged to stable version(4.7).

You misunderstood my first paragraph. I meant "yes, runUrl should probably always use the url's directory as current directory". Sorry for the double negation.

Git commit 693ca44eb71be65171aec8ecec6eee92e8c055b4 by Peter Penz.
Committed on 13/10/2011 at 20:00.
Pushed by ppenz into branch 'KDE/4.7'.

KRun: Use the URL-directory as current directory

Thanks to Tautvydas Andrikys for the patch!

BUG: 271824
FIXED-IN: 4.7.3

M  +1    -1    kio/kio/krun.cpp

http://commits.kde.org/kdelibs/693ca44eb71be65171aec8ecec6eee92e8c055b4

i just want to say i am experiencing this bug more or less. Whatever i am opening, binaries or scripts. They always are executed in the a completely different working directory then i am currently in dolphin.
I am on gentoo ~amd64. 

# kde4-config -v
Qt: 4.8.5
KDE Development Platform: 4.13.2
kde4-config: 1.0

I had to make scripts that change the working directory to the where the script is located before clicking .exe files. Just one example.

Yeah everything starts in $home even though i dont start the binaries or scripts in $home