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/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep