• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays) (From: DeNigris Sean <email@hidden>)
 >Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays) (From: Alastair Houghton <email@hidden>)

  • Prev by Date: Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
  • Next by Date: Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
  • Previous by thread: Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
  • Next by thread: Re: NSUserDefault and Negative numerical arguments (Was: Posting mouse clicks with multiple displays)
  • Index(es):
    • Date
    • Thread