Fri 26 Feb 2010 02:22:00 PM UTC, original submission:
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.
|