[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #29012] Service executable cannot read the service's info dictionar
From: |
Wolfgang Lux |
Subject: |
[bug #29012] Service executable cannot read the service's info dictionary |
Date: |
Fri, 26 Feb 2010 14:22:01 +0000 |
User-agent: |
Mozilla/5.0 (Macintosh; U; PowerPC Mac OS X 10_4_11; en-US) AppleWebKit/531.9+(KHTML, like Gecko, Safari/528.16) OmniWeb/v622.10.0 |
URL:
<http://savannah.gnu.org/bugs/?29012>
Summary: Service executable cannot read the service's info
dictionary
Project: GNUstep
Submitted by: wlux
Submitted on: Fr 26 Feb 2010 14:22:00 GMT
Category: Base/Foundation
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
E.g., add the following lines to the main function of GSspell.service
NSLog(@"mainBundle = %@", [NSBundle mainBundle]);
NSLog(@"resourcePath = %@", [[NSBundle mainBundle] resourcePath]);
NSLog(@"infoDictionary = %@", [[NSBundle mainBundle] infoDictionary]);
Running the modified service executable yields the output
2010-02-26 14:34:40.278 GSspell[28696] mainBundle = <NSBundle: 0x33d1e08>
</usr/GNUstep/System/Library/Services/GSspell.service/Resources/GSspell>
2010-02-26 14:34:40.310 GSspell[28696] resourcePath =
/usr/GNUstep/System/Library/Services/GSspell.service/Resources/GSspell/Resources
2010-02-26 14:34:40.313 GSspell[28696] infoDictionary = {}
The problem is caused by NSBundle's -mainBundle method, which IMO implements
a wrong search order. It assumes that the executable is part of a bundle only
when the parent directory ends in one of the known application suffixes and
.service is not one of them. Of course, one could trivially add .service to
the list of known suffixes, but I think this is just a stop gap measure, since
it will break immediately when an application introduces its own kind of
executable plugin bundles. The inclusion of .gswa and .woa in the list of
known extensions looks to me a witness of this shortcoming.
I think that -mainBundle really should first check whether the executable is
part of a bundle regardless of the parent directory's extension, i.e., check
whether there is a Resources directory containing an Info.plist or
Info-gnustep.plist file in the same directory as the executable. Only if that
check fails, -mainBundle should look for a Resources directory in another
place.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?29012>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
- [bug #29012] Service executable cannot read the service's info dictionary,
Wolfgang Lux <=