After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341657 - Scripts don't work on the desktop
Scripts don't work on the desktop
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Scripts facilities
2.23.x
Other All
: Normal normal
: 2.24.x
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 429447 549910 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-13 15:42 UTC by Arvind Narayanan
Modified: 2008-08-30 10:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
patch (787 bytes, patch)
2008-03-31 13:27 UTC, Cosimo Cecchi
none Details | Review
patch (2.73 KB, patch)
2008-03-31 13:28 UTC, Cosimo Cecchi
none Details | Review

Description Arvind Narayanan 2006-05-13 15:42:34 UTC
Please describe the problem:
When a script is executed with a file on the desktop as argument, it is invoked
from $HOME instead of $HOME/Desktop and so the script cannot find the file.

Steps to reproduce:
Create a file on the desktop.

Create a script whose contents are 'rm "$1"' (without the single quotes)

Execute said script on said file.

Actual results:
Nothing. Fails silently.

Expected results:
The file should be deleted.

Does this happen every time?
Yes.

Other information:
It would be nice if nautilus were to report the exit status of a script.
Comment 1 Jimmy Angelakos 2007-03-25 10:14:06 UTC
I confirm this. The "Open Terminal" script leads you to your Home Folder, and the AudioConvert script fails as well (silently). This happens when trying to run scripts on the Desktop, but NOT when opening ~/Desktop as a folder.

Version is Nautilus 2.16.1 (Ubuntu Edgy)
Comment 2 Arvind Narayanan 2007-05-06 19:07:52 UTC
Same bug still exists in 2.18.
Comment 3 Arvind Narayanan 2007-05-17 02:07:59 UTC
It also doesn't work in the .Trash folder.
Comment 4 Tom Kirby 2008-03-29 20:59:24 UTC
I can confirm this in 2.22.0.

Create a script like this:

---------------------
#!/bin/bash

zenity --info --text=$*
---------------------

If you run it on any normal file, it gives the name of the file. If you run it from the desktop, it gives nothing.
Comment 5 Tom Kirby 2008-03-29 21:01:31 UTC
This bug shouldn't be "UNCONFIRMED" any more, and (presumably) should be labelled as applying to Gnome 2.22.0.
Comment 6 Tom Kirby 2008-03-29 21:02:44 UTC
And this bug should actually be marked as a duplicate of #429447. Sorry to flood the place with comments.
Comment 7 Cosimo Cecchi 2008-03-30 00:59:38 UTC
*** Bug 429447 has been marked as a duplicate of this bug. ***
Comment 8 Cosimo Cecchi 2008-03-30 01:03:45 UTC
Thanks Tom, confirming with 2.22.0.
Comment 9 Cosimo Cecchi 2008-03-31 13:27:58 UTC
Created attachment 108335 [details] [review]
patch

As suggested by Alex on IRC, this seems to be a better way to check for local/not local files, and it fixes this bug.
Comment 10 Cosimo Cecchi 2008-03-31 13:28:51 UTC
Created attachment 108336 [details] [review]
patch

Wrong patch attached, sorry for the spam.
Comment 11 Alexander Larsson 2008-03-31 13:36:42 UTC
I think that looks ok. However, I'm not sure why we just pass basename into the script instead of absolute paths. It will break if you're e.g. in a list view with a file in an expanded subdirectory selected.
Comment 12 Michael Monreal 2008-08-20 12:19:48 UTC
Can we get the patch into trunk now please? Else it won't make the target I fear...
Comment 13 Christian Neumair 2008-08-20 15:49:42 UTC
Thanks, I committed a patch to trunk in the spirit of Cosimo's work:

http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14502

However, I changed the actual command launch helper to accept an array of parameters, and quote each parameter separately. I also added a TODO comment for the issue mentioned by Alex in comment 11.

Closing as fixed.
Comment 14 Cosimo Cecchi 2008-08-30 10:11:31 UTC
*** Bug 549910 has been marked as a duplicate of this bug. ***