bug-gnustep
[Top][All Lists]
Advanced

[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/





reply via email to

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