On Dec 7, 2014, at 5:35 PM, SevenBits <sevenbitst...@gmail.com> wrote:
> On Dec 7, 2014, at 4:03 PM, Ken Thomases <k...@codeweavers.com> wrote: >> >> 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? Not exactly. AppleScript will use Launch Services to launch Terminal if it's not already running, but not otherwise. And Launch Services delivers Apple Events to tell Terminal to open a "document". The reason I consider the Apple Script (or Scripting Bridge) approach to be better is that it is more specific to what you're trying to do. It's not at all clear to me that "opening" an executable with Terminal is going to _reliably_ run that executable's path as a command in a new window. Directly telling Terminal to run a particular command with its AppleScript interface seems much closer to the specific thing you're trying to accomplish. >> 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. If Terminal is already running, it won't inherit your sandbox. > 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. There's no separating Terminal from its ability to run arbitrary commands. There's certainly no way that the system is going to have the insight into what you're doing to understand that it "should" be allowed. There are too many layers of indirection and interpretation of arguments. Among other things, any Terminal window is going to run a login shell, which is going to process /etc/profile and one of ~/.bash_profile, ~/.bash_login, or ~/.profile. > If it matters, the executable is a program that evaluates instructions using > REPL (read-eval-print loop). I'm guessing it doesn't need much in terms of terminal emulation. I.e. it's not using curses/ncurses, terminal control, color, etc. In that case, it may be a good candidate for driving via NSTask and pipes. You will want to make sure that it flushes standard output before blocking waiting for input. That's automatic when standard input and output are connected to a terminal device, but not when they're connected to pipes. Regards, Ken _______________________________________________ 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
