Re: Strange problem with call-system, PATH, delivery, and errors
Hmmm, the plot thickens...
If I put that contain form in a file
and compile and load it, I get a tiny
window with ; /bin/sh as I'd expect.
In a Listener or with an Eval Last Form,
I get the behavior that I describe earlier.
Any ideas?
On 22/08/05, Joshua Taylor <joshuaaaron@gmail.com> wrote:
> Actually, I run into some problems here...
>
> When I try to do
>
> (capi:contain (make-instance 'capi:display-pane
> :text (with-output-to-string (*standard-output*)
> (setf ret
> (sys:call-system-showing-output '("/usr/bin/env")))))
> :title "env")
>
> say, from a Listener, all that happens is a new Terminal window opens
> with the contents:
>
> Last login: Mon Aug 22 08:36:56 on ttyp2
> /tmp/LWtemp.Wright.2021.1.command; exit
> Welcome to Darwin!
> ^_^ tayloj@Wright:~$ /tmp/LWtemp.Wright.2021.1.command; exit
>
> but the form doesn't return...
> Any thoughts ?
>
> On 19/08/05, Martin Simmons <martin@lispworks.com> wrote:
> > >>>>> On Wed, 17 Aug 2005 12:35:29 -0400, Joshua Taylor <joshuaaaron@gmail.com> said:
> >
> > J> Hi all,
> > J> A strange error, and I've an idea what's going on, but not much of an
> > J> idea how to deal with it,
> > J> or why exactly it happens.
> >
> > J> I'm on LWM 4.4.5 Pro, MacOS10.4.2
> >
> > J> I have a /usr/local/bin which is added to my PATH in my .bashrc file.
> > J> Terminal.app starts bash when creating a new window.
> > J> I have a file called 'testing' in /usr/local/bin" which has the following
> > J> contents
> > J> --------------
> > J> #!/bin/bash
> > J> echo "Testing with the Path..."
> > J> --------------
> > J> and has the proper permissions set to execute.
> >
> > J> I have a delivery file that has the following contents:
> > J> --------------
> > J> (defun test-fn (&rest r)
> > J> (declare (ignorable r))
> > J> (capi:contain (make-instance 'capi:display-pane
> > J> :text
> > J> (let* ((ret 0)
> > J> (op (with-output-to-string
> > J> (*standard-output*)
> > J> (setf ret
> > J> (sys:call-system-showing-output "testing")))))
> > J> (capi:contain (make-instance
> > J> 'capi:display-pane
> > J> :text
> > J> op))
> > J> (unless (zerop ret)
> > J> (error "There was an error"))))))
> >
> > J> (defun deliver-fn ()
> > J> (capi:contain (make-instance 'capi:push-button
> > J> :callback #'test-fn)))
> >
> > J> (load (make-pathname
> > J> :directory (pathname-directory (sys:lispworks-dir
> > J> "examples/configuration/"))
> > J> :name "macos-application-bundle"))
> >
> > J> (deliver
> > J> #'deliver-fn
> > J> (write-macos-application-bundle
> > J> (make-pathname :directory (pathname-directory *load-truename*)
> > J> :name "testing"))
> > J> 1
> > J> :interface :capi)
> > J> ----------
> > J> It's not beautiful code, but it illustrates my problem. I get an
> > J> Application bundle
> > J> as a result when I deliver this. When I double cilck on the application
> > J> I get a small window with a button.
> >
> > J> The first time I press the button, I get a display-pane with the contents:
> >
> > J> ; testing
> > J> ; testing: line 1 : testing : command not found
> >
> > J> As I would rather expect. The error opens a new Terminal window which has the
> > J> contents:
> > J> --------
> > J> Last login: Wed Aug 17 12:21:27 on ttyp3
> > J> Welcome to Darwin!
> > J> ^_^ tayloj@Wright:~$ /tmp/LWtemp.Wright.9089.1.command; exit
> >
> > J> Error: There was an error
> > J> 1 (abort) Quit process.
> >
> > J> Type :b for backtrace, :c <option number> to proceed, or :? for other options
> >
> > J> CL-USER 1 : 1 >
> > J> ------
> >
> > J> Notice the bash prompt as well. If I abort from the error, that is, enter ":a",
> > J> control is returned, and I can press the button again. Pressing the button again
> > J> gives me a display pane with
> > J> ; testing
> > J> ; Testing with the Path...
> > J> which shows that my .bashrc has been read, and the PATH being
> > J> exported evidentally
> > J> went all the way back to Lispworks.
> >
> > J> At the beginning I made it clear that I started the Application by
> > J> clicking on the icon. If I
> > J> do
> > J> open testing.app
> > J> from a Terminal (in which I'm already running bash) the testing shell
> > J> script is found
> > J> on the first button press (and thus I know that /usr/local/bin is on the PATH).
> >
> > J> So, I've got at least a few questions:
> > J> Certainly, call-system has PATH set to something, otherwise it
> > J> wouldn't be able to
> > J> work with things like 'ls', etc. However, it doesn't seem to spawn a
> > J> shell under as my
> > J> user, as the config files aren't being read.
> >
> > Call-system does run a shell, but it is named as /bin/sh by default (see the
> > :SHELL-TYPE argument).
> >
> >
> > J> How can I control the PATH
> > J> that call-system uses?
> >
> > The function (SETF ENVIRONMENT-VARIABLE) can be used to set PATH.
> >
> >
> > J> It's understandable that lispworks inherits the PATH from whatever
> > J> launches is, hence
> > J> /usr/loca/bin on the PATH when I lauch from Terminal, but does it make
> > J> sense that a
> > J> Terminal coming up in order to present the error continuations should
> > J> be able to
> > J> modify the PATH for subsequent calls to call-system?
> >
> > No, I don't think that is happening (something would be very very wrong if
> > that was even possible on a BSD system).
> >
> > What I think is happening is as follows:
> >
> > 1) The first time you do call-system, /bin/sh (i.e. bash) notices that its
> > stdin is connected to /dev/null (the default for a windowing application in
> > Mac OS X). It therefore doesn't read your .bashrc.
> >
> > 2) When you get the error, LispWorks starts up the Terminal and connects its
> > stdin to that Terminal.
> >
> > 3) The second time you do call-system, /bin/sh (i.e. bash) sees that it's
> > stdin is connected to something real so it reads you .bashrc.
> >
> > E.g. if you add the following to the start of test-fn:
> >
> > (capi:contain (make-instance 'capi:display-pane
> > :text (with-output-to-string (*standard-output*)
> > (setf ret (sys:call-system-showing-output '("/usr/bin/env")))))
> > :title "env")
> > (capi:contain (make-instance 'capi:display-pane
> > :text (with-output-to-string (*standard-output*)
> > (setf ret (sys:call-system-showing-output "set"))))
> > :title "set")
> >
> > then you can see how the environment seen by the command changes between runs.
> > The first form passes a list to call-system-showing-output, which makes it run
> > that executable directly without the shell so you can see what LispWorks is
> > passing down. The second form runs bash's "set" command and you can see that
> > this output changes to include everything set in your .bashrc on the second
> > attempt.
> >
> > --
> > Martin Simmons Email: martin@lispworks.com
> > LispWorks Ltd, St John's Innovation Centre TEL: +44 1223 421860
> > Cowley Road, Cambridge CB4 0WS, England. FAX: +44 870 2206189
> >
>
>
> --
> =====================
> Joshua Taylor
> tayloj@rpi.edu
>
--
=====================
Joshua Taylor
tayloj@rpi.edu