> On Dec 7, 2014, at 4:03 PM, Ken Thomases <k...@codeweavers.com> wrote: > > On Dec 7, 2014, at 2:29 PM, SevenBits <sevenbitst...@gmail.com> wrote: > >> I have a sandboxed app destined for the Mac App Store. Inside of it is an >> embedded console program which I want to open in Terminal (i.e Terminal.app >> opens and the app runs in its window). Here’s what I’m doing: >> >> NSString *interactiveExecutablePath = [[[NSBundle mainBundle] bundlePath] >> stringByAppendingPathComponent:@"/Contents/MacOS/app"]; >> [NSTask launchedTaskWithLaunchPath:@"/usr/bin/open" arguments:@[@"-a", >> @"Terminal", interactiveExecutablePath]]; > > First, it never makes any sense for a program to spawn a subprocess to run > /usr/bin/open. /usr/bin/open is just a wrapper around Launch Services. So, > you could just call Launch Services directly or use NSWorkspace, which is > also a wrapper around Launch Services. > > Second, even using Launch Services isn't the best way to do this (sandbox > issues aside). It's better to run the equivalent of this AppleScript script: > > tell app "Terminal" > activate > do script "your command goes here" > end > > You can do that using NSAppleScript or the Scripting Bridge.
Okay, but out of curiosity, what makes AppleScript a better choice in this scenario? Doesn’t it ultimately fall back on Launch Services just like the other options? > > I don't know if this approach is more likely to work in a sandboxed app. I > doubt it, because it would be an enormous hole in the sandbox. If you can > direct Terminal to run arbitrary commands, what protection does the sandbox > provide? I get your point, but the fact is, I’m not trying to run an arbitrary command, and I don’t even care if Terminal inherits the sandbox from my process. I just need to run this command in a window so that the user can type input in and receive the results back. In other words, I’m looking for Terminal’s user interface, not its ability to run arbitrary commands. If it matters, the executable is a program that evaluates instructions using REPL (read-eval-print loop). > > >> I really need this to work as it’s an important aspect of my application. >> Can anyone advise? > > I suspect you have a serious problem, then. You will probably need to deploy > outside of the Mac App Store so that you don't have to sandbox your app. > Alternatively, you can build a terminal emulator UI into your app and run the > embedded console program within that, instead of Terminal. Depending on the > needs of your console program, that may be a relatively straightforward > prospect or a very complex one. Well, I’m stuck in the middle. On the one hand, implementing a full-brown terminal emulator along the lines of iTerms 2 for my app is overkill and isn’t worth the extra megabytes. But I don’t want to implement a kludgy NSTextField-based interface to feed in input using NSTask and output/input streams either, as it doesn’t look that great. However, unless someone can come up with a good way to provide a Terminal-like environment for REPL applications, the second approach is the one I’ll probably have to take… Thanks, — SevenBits > > Regards, > Ken >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
