Re: NSTask: program launching another program, potential problem with path: how to do?
Re: NSTask: program launching another program, potential problem with path: how to do?
- Subject: Re: NSTask: program launching another program, potential problem with path: how to do?
- From: Keary Suska <email@hidden>
- Date: Thu, 10 Apr 2014 17:51:50 -0600
On Apr 10, 2014, at 3:34 PM, Colas B wrote:
> I am not an unix-ey guy...
>
> I don't specify explicitly a bash when I run my program (with NSTask) : I just give the path to the program. If I discover the path to the shell being used, does it mean that what used to be the path of my NSTask will become an argument?
Yes--launchPath is set to the shell, and the rest become arguments.
> About path and environment variable, I don't specify anything special when I run my program from the terminal.
Well, most shell configurations will come with a reasonably sensible environment, but I believe you get next to nothing when running an application. At a terminal prompt execute the "printenv" command to see the current environment. You could set the PATH variable on the task (using -setEnvironment:) and see if that works. If so, realize that this approach may be fragile in environments that you don't control (i.e. end-users). There also may be other variables needed...
> Envoyé depuis Yahoo Mail pour iPad
>
> From: Keary Suska <email@hidden>;
> To: Colas B <email@hidden>;
> Cc: Cocoa-Dev (Apple) <email@hidden>;
> Subject: Re: NSTask: program launching another program, potential problem with path: how to do?
> Sent: Thu, Apr 10, 2014 9:21:04 PM
>
> On Apr 10, 2014, at 2:52 PM, Colas B wrote:
>
> > Hi,
> >
> > thanks for your answers !
> > Your idea sounds good. What can I do if I want both shells invoked from programs and login shells to have the same initialization script? Shall I write a new script that runs first ~/.login and then myprogram ? Or is there a simplier way?
> >
> > In my case, myprogram is pdflatex (with the -shell-escape option) and myauxprogram is gnuplot.
>
> The best approach may be a complicated affair. IMHO it is better to explicitly inject the environment that you want for the task, possibly with preference settings to specify non-standard paths and additional environment variables. The problem with setting a login-like environment is that you need to know what shell is being used. There may be a way to discover that, and then you could invoke myprogram via the shell. E.g.:
> /path/to/bash -l -c myprogram arguments
>
> Syntax will likely be similar for all shells, and many IIRC will accept -l or --login to designate a login shell.
>
> Note that this approach comes with a number of security implications, and unix-ey folks like me would tell you to not do that and instead use the first approach I mention.
>
> > Le Jeudi 10 avril 2014 16h32, Jens Alfke <email@hidden> a écrit :
> >
> > On Apr 10, 2014, at 6:23 AM, Keary Suska <email@hidden> wrote:
> >
> >> This is more likely a shell scripting issue, rather than am NSTask issue, unless sandboxing is somehow interfering, and you are obscuring the issue by not telling us at least how myprogram is locating myauxprogram. The most likely culprit is that the invocation of myauxprogram in myprogram is a relative path that relies on the PATH environment variable that is properly set by the shell, but you don't set in NSTask.
> >>
> >
> > Agreed. A problem I’ve run into several times is that shells invoked from programs are not login shells, so they don’t run the same initialization scripts as the shell you use in a terminal. (For instance, a csh login shell runs ~/.login on startup as well as ~/.cshrc, but a non-login shell doesn’t. A similar thing happens with bash but I can never remember which scripts are involved.) If you customize your $PATH in the login-shell startup script, then a shellscript run outside a terminal window won’t have the same path.
>
>
> Keary Suska
>
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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