Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
- Subject: Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
- From: Chris Parker <email@hidden>
- Date: Tue, 11 Aug 2009 10:04:28 -0700
On 11 Aug 2009, at 9:47 AM, Alastair Houghton wrote:
On 11 Aug 2009, at 17:14, DeNigris Sean wrote:
If the command line is "MyApp -x -100 -y 100", NSUserDefaults
does not recognize the -100 as the value of the x argument - it
sets x to 0. If the '-' is removed, everything is fine. Is
this a bug? Is there a way around?
Yes-- -100 is parsed as an argument, not as a value to the
previous argument.
So, no, it isn't a bug. It is behaving correctly, for some values
of correct. Welcome to shell programming & the interface between
shell & process. Fragile space. Coder beware.
I consider that if a negative number is a valid value for an
option, and NSUserDefaults can not handle them, and this
restriction is not documented, then it's a bug.
So file a bug report.
Non-bug options would be:
a) handle negative arguments correctly
b) restrict numerical arguments to positive values and document
this restriction
The behavior of the object does not match the spec.
The documentation barely specifies how parsing works for command
line arguments at all.
Current behavior is that anything with a leading `-` is considered a
flag; therefore "MyApp -x -100 -y 100" looks like a command-line
invocation with three flags, one of which has a value (the `y` flag).
Without some additional information about expected types for a given
flag (or whether a given flag requires an argument, etc) we can't do
much better. You can file a bug against NSUserDefaults; it's likely to
wind up a dup of an existing bug we have to tell NSUserDefaults what
to expect for a particular flag.
For instance, it's clearly the case that YES and NO work for boolean
arguments. But that isn't documented anywhere and it means that if
you want a string containing "YES" or "NO" you're going to be out of
luck.
NSUserDefaults supports a few different accessors for values:
- (NSString *)stringForKey:(NSString *)defaultName;
- (NSArray *)arrayForKey:(NSString *)defaultName;
- (NSDictionary *)dictionaryForKey:(NSString *)defaultName;
- (NSData *)dataForKey:(NSString *)defaultName;
- (NSArray *)stringArrayForKey:(NSString *)defaultName;
- (NSInteger)integerForKey:(NSString *)defaultName;
- (float)floatForKey:(NSString *)defaultName;
- (double)doubleForKey:(NSString *)defaultName;
- (BOOL)boolForKey:(NSString *)defaultName;
So given this command-line:
./foo_tool -booleanOption YES
if you were to ask NSUserDefaults for -stringForKey:@"booleanOption"
you'd get back the NSString @"YES". If you were to ask NSUserDefaults
for -boolForKey:@"booleanOption" you'd get back (BOOL)1.
So I don't think it's a case of the behaviour not matching the
spec. There *is* no spec worth mentioning, so really if there's a
bug here, it's that the docs don't say how the argument domain works.
Please file a bug against the documentation to be clearer about what
to expect.
*Anyway*, my impression has always been that NSUserDefaults was not
intended to be used to obtain the command line arguments, and that
the argument domain feature was put there primarily (though perhaps
not exclusively) for debugging purposes, as a way of temporarily
overriding the settings in the defaults database.
As usual, it depends on what you're trying to do. Many command-line
tools use NSUserDefaults to get their arguments; it's a lot easier
than using getopt(3) most of the time. You're correct
If you want to process the command line arguments, you can either do
so from your main() function, before calling NSApplicationMain(), or
you can use NSProcessInfo to examine them once your app is running.
You can always do this if you know a particular key hasn't been
handled the way you expect via NSUserDefaults.
.chris
--
Chris Parker
iPhone (formerly Cocoa) Frameworks
Apple Inc.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden