bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #32564] Cannot start applications with the symbolic link created in


From: Wolfgang Lux
Subject: [bug #32564] Cannot start applications with the symbolic link created in the Tools directory
Date: Mon, 21 Feb 2011 21:53:55 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/531.21.8+(KHTML, like Gecko, Safari/528.16) Version/5.10.3 OmniWeb/622.14.0

URL:
  <http://savannah.gnu.org/bugs/?32564>

                 Summary: Cannot start applications with the symbolic link
created in the Tools directory
                 Project: GNUstep
            Submitted by: wlux
            Submitted on: Mo 21 Feb 2011 21:53:54 GMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Starting an application by entering the name of the symbolic link on the
command line does not work anymore. Applications started in that way will fail
with an error saying that they cannot find their main nib file. Starting the
application with openapp or by entering the full path of the main executable
file still works.

The problem can be observed on every platform where NSBundle's
GSPrivateExecutablePath returns a relative path when the application was
started without entering the full path of the application's main executable,
which seems to be every platform out there except Linux, and was introduced in
r32109 when NSString -stringByStandardizingPath stopped resolving symbolic
links. For instance, the path of an application's main bundle does not resolve
to the application directory but to the tools directory containing the
symbolic link instead.

Simply changing all calls to -stringByStandardizingPath into
-stringByResolvingSymbolicLinksInPath does not work either, apparently because
the latter method converts all relative paths into absolute paths by
prepending the current directory. (BTW, this behavior seems to be incompatible
with OS X as well; I tried that for a few simple cases including [@"."
stringByResolvingSymbolicLinksInPath] and [@".."
stringByResolvingSymbolicLinksInPath] and OS X doesn't seem to convert
relative paths into absolute paths.)





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?32564>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]