I shared a “Red Fire Bar” with some coworkers today, and we all agreed it was very good. It tasted a lot like Mexican Hot Chocolate, with the chili peppers rounding out the flavor quite nicely. I do not normally like dark chocolate, but peppers add a “richness” that compliments it well.
Despite the name, the candy was not spicy — I’d rate it about the same as mild salsa.
The best way to call a shell-command from Coca is by using an NSTask. Here are the three resources on using an NSTask that I found the most helpful:
CocoDev’s write up
A few quick exaples
NSTask Class Refrence
And here is some sample code to do it for you. You are free to use this code however you please, but attribution is always appreciated. The two principle functions are:
+ (NSString*) executeShellCommandSynchronously:(NSString*)command executes the command “command” with sh, wait until it finishes, and return whatever it printed to stdout and stderr as an NSString.
CAUTION: may deadlock under some circumstances if the output gets so big it fills the pipe. See http://dev.notoptimal.net/search/label/NSTask for an overview of the problem, and a solution. I have not experienced the problem myself, so I can’t comment.
executeShellCommandAsynchronously: will have sh execute command in the background, without blocking anything.
For quick hacks, the POSIX int system(const char* command) function, might be a good one-line solution. It synchronously evaluates command with sh.
Enjoy!
EDITED 2009-11-29: this code probably won’t have the same $PATH you would get if you used Terminal. See this question on stackoverflow for more details. A solution that seems to work is to do,
[task setLaunchPath:@"/bin/bash"];
NSArray *args = [NSArray arrayWithObjects:@"-l",
@"-c",
commandlineHere,
nil];
[task setArguments: args];
This launches bash (not in sh compatibility mode), and -l (lowercase L) tells it to “act as if it had been invoked as a login shell”. I haven’t tested this on systems where bash isn’t the default shell. There are lots of ways $PATH could be set, and I haven’t tested them all. But you are almost certainly going to be OK if everything you refer to is in /usr/bin:/bin:/usr/sbin:/sbin.
Most diction decisions, like choosing the keyword nil over NULL seem inconsequential. Sure, n-i-l is probably faster to type then shift+n-u-l-l, but the difference is too small to matter. Both terms are clear.
However after today I’m convinced that the C++ convention of using the keyword this, over self, was a mistake. “This” is just too common of a pronoun. It’s too easy to say something like “..this is invalid..”, and leave people wondering if you meant that-this or self-this.
I’d be interested to know the reasoning behind choosing the ambiguous keyword “this” over the precedent “self”.
I plan to refer to “this” as “self” whenever possible for a time, to see if it’s less confusing, even to habitual C++ users.
To easily create a new UUID (aka GUID) in Cocoa, add the following method as a category to NSString:
+ (NSString*) stringWithUUID {
CFUUIDRef uuidObj = CFUUIDCreate(nil);//create a new UUID
//get the string representation of the UUID
NSString *uuidString = (NSString*)CFUUIDCreateString(nil, uuidObj);
CFRelease(uuidObj);
return [uuidString autorelease];
}
That’s it, just 4 lines of code. There’s really no need to deal with an entire UUID class. All you ever need to do with UUIDs is create them, compare them, and store/retrieve them. + stringWithUUID handles creation. The string it returns responds to - isEqual:, and is easy to write or read using the mature Foundation APIs. What more could you ask for from a UUID object?
You might only need: [[NSProcessInfo processInfo] globallyUniqueString]. As the name implies, it gives you a UUID that can be used to identify a process.
If you want a UUID without messing with compiled code, the uuidgen command-line tool generates them, or you can use this website.
Powered by WordPress