GNOME Bugzilla – Bug 585506
Launching gedit via command line alias won't open file
Last modified: 2009-11-09 17:53:10 UTC
Please describe the problem: I have this alias on my MAC alias gedit='open -a '\''/Applications/gedit.app'\''' This allows me to run gedit from my prompt. If I run, from my prompt, gedit /path/to/file.txt, the editor opens with a blank untitled document. Steps to reproduce: 1. Open terminal 2. Issue: alias gedit='open -a '\''/Applications/gedit.app'\''' 3. Run gedit file_to_open Actual results: gedit opens with any empty untitled document Expected results: Have gedit open the file given as input Does this happen every time? Yes Other information:
*** Bug 586642 has been marked as a duplicate of this bug. ***
*** Bug 586643 has been marked as a duplicate of this bug. ***
Also, when telling osx to use gedit to open, for example, txt files and you double click on them, gedit opens, but with an empty document and not the file you wanted opened.
Does (from the command-line): /Applications/gedit.app/Contents/MacOS/gedit /path/to/file.txt work?
@ Daniel, your command gives me: /Applications/gedit.app/Contents/MacOS/gedit: line 59: /Users/peter//Applications/gedit.app/Contents/MacOS/gedit-bin: No such file or directory /Applications/gedit.app/Contents/MacOS/gedit: line 59: exec: /Users/peter//Applications/gedit.app/Contents/MacOS/gedit-bin: cannot execute: No such file or directory /Applications/gedit.app/Contents/MacOS/gedit: line 57: /Users/peter//Applications/gedit.app/Contents/Resources/libexec/gconfd-2: No such file or directory Also in latest version...
Sounds like a general pattern then: the .app contains a script that has no idea how to handle relocation (should find its components "relative to itself" or "using known absolute path" rather than mixing that with "relative to $PWD of launch"). Where exactly did you get this gedit.app bundle?
Got it from the osx download link at the main gedit site ( http://projects.gnome.org/gedit/ ).
(In reply to comment #7) > Got it from the osx download link at the main gedit site ( > http://projects.gnome.org/gedit/ ). I just downloaded and installed gedit-2.28.0.dmg from above link and I tried with the same results. I then did sudo su and cd / and this is what I got: ~ $ sudo su Password: sh-3.2# cd / sh-3.2# /Applications/gedit.app/Contents/MacOS/gedit /Users/danv/Desktop/simple.txt ** (gedit-bin:814): WARNING **: Throbber animation not found ** (gedit-bin:814): WARNING **: Throbber fallback animation not found either (gedit-bin:814): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed sh-3.2# ---- It did open the file! But I do not know how "CRITICAL" the error message really is. Obviously some work needs to be done in relation to opening files. I find this "Open with..." bug extremely annoying. To me a bug that affects the user every time they use a program should have more attention paid to it. -Dan
Careful not to overstate...it only affects one mode of using the program for some users. But it's still a bug. Your demonstration proved that *if* the filenames are passed and it can find itself, it works. From hacking on the .app/Contents/MacOS/gedit script a bit, it's expecting the filename(s) to come as command-line arguments, but OSX is not passing them that way--NOTGNOME on that. But I have no idea if it ever did work that way, or just someone assumed so (seems logical!) and put together a not-fully-tested script that has not worked in forever. I experimented with platypus, a program that generates .app bundle wrappers around user-supplied scripts. It has an option to enable drag'n'drop support, and when I do that, I can get the script to receive the filenames passed via either Finder drop or 'open' commandline call. The platypus-generated wrapper is a compiled binary that apparently calls the Cocoa, LaunchServices, or whatever other system tools to get the UI actions, then munges them into a commandline parameter list to run the script. Along the way, I also noticed that the script is not safe for filenames with spaces in them (it doesn't quote args when the gedit script exec's the gedit-bin actual program).
(In reply to comment #9) > Careful not to overstate... Sorry, I tend to whine about software bugs that annoy me personally ;-) I am an experienced systems programmer, but new to the MacOS and its "ways". I looked at the gedit script you mentioned and I see the faults you pointed out. This looks wacky even to me... tmp="`pwd`/$0" tmp=`dirname "$tmp"` tmp=`dirname "$tmp"` <-- TWICE? bundle=`dirname "$tmp"` ---- I think they were simply looking for: bundle=`dirname $0` One of several techniques to get the application directory. And the use of unquoted $* in the $EXEC line looks dangerous as well. I am unfamiliar with platypus, but sounds like it would do the trick. Does it handle filenames with spaces properly? Especially for multiple file selection? I hope so!... So, does this experiment foretell a fix to this bug? ;-Dan Vokt
Let me jump in here as the guy responsible for the port. First, this problem with opening files is known (at least from finder, etc.). Also, the script was never meant to be used from the command-line, and agreed there are some hackish things in there, but the goal at the time was to make it work. The proper way to fix this problem is twofold. First, cleanup the front-end script with regard to the problems as you state above (directory, escaping). Second, gedit should support the IPC that OS X uses to communicate opening files to applications. Doing this with something like platypus seems wrong to me (it sounds like a good solution to fix it right now if you want that), we should support this natively. There is already a bug open about this, but as I'm a busy man, I haven't gotten to it (and the OS X port is not a high priority for our little team).
(In reply to comment #8) > sh-3.2# cd / > sh-3.2# /Applications/gedit.app/Contents/MacOS/gedit /Users/danv/Desktop/simple.txt Does this also work (at least as well, maybe even with fewer warnings) if not as root user? That would suggest a bash-function solution: "just" need to cd to root-level, then call explicit paths to both the app and the file. Something like: gedit() {( fn="$PWD/$1"; /Applications/gedit.app/Contents/MacOS/gedit "$fn" );} (untested, I'm not near my Mac right now) (In reply to comment #9) > This looks wacky even to me... > > tmp="`pwd`/$0" > tmp=`dirname "$tmp"` > tmp=`dirname "$tmp"` <-- TWICE? > bundle=`dirname "$tmp"` The goal is to set a path relative to the program being run, going up a few levels of hierarchy. Would be clearer (and save CPU time!) to do: > tmp="`pwd`/$0" > bundle="$tmp/../../.." to get "up from the MacOS dir so can go down into a parallel dir to it"
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
On behalf of all us mac/x11 folks, many thanks for having the Mac GUI interaction be tied to gdk=quartz rather than platform=darwin!