Subject: [clisp-list] inspector via browser: MS-IE solution

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Tue Mar 18 05:39:01 2003

Daniel Freudenthal writes:
>Disabling smart browsing, I notice that the address 
>displayed in the
>URL line is: "&". Netscape is then unable to resolve this host.

This shows that you did not successfully apply my patch - it specifically eliminated the "&".

Use (trace ext:run-program) and (trace ext:shell) and ignore the *@!#* package lock problem.
You will then see what gets used. The trailing "&" must go away on MS-Windows systems.

(trace ext:run-program)
** - Continuable Error
TRACE(EXT:RUN-PROGRAM): #<PACKAGE EXT> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
2. Break INSPECT-TMP-PACKAGE-615[13]> continue

Well, tonight I got the idea that MAKE-PIPE-INPUT/IO/OUTPUT-STREAM knows how to create asynchronous processes in CLISP on MS-Windows. So here's a working MS-IE setting (hack) for me:

(defun browse-url (url &key (browser *browser*) (out *standard-output*))
  "Run the browser (a keyword in `*browsers*' or a list) on the URL."
  (let* ((command
          (etypecase browser
            (list browser)
            (symbol (or (cdr (assoc browser *browsers* :test #'eq))
                        (error "unknown browser: `~s' (must be a key in `~s')"
                               browser '*browsers*)))))
         (args (mapcar (lambda (arg) (format nil arg url)) (cdr command))))
    (cond (command
           (when out
             (format out "~&;; running [~s~{ ~s~}]..." (car command) args)
             (force-output (if (eq out t) *standard-output* out)))
           (close (ext:make-pipe-output-stream
                   (format nil "\"~A\"~{ ~A~}" (first command) args)))
           ;;(run-program (car command) :arguments args :wait nil)
           (when out
             (format out "done~%")))
          ((format t "~s: no browser specified; please point your browser at
 --> <URL:~a>~%" 'browse-url url)))))

(inspect (list-all-packages) :frontend :http :browser '("C:\\PROGRA~1\\Internet Explorer\\IEXPLORE.EXE" "~A"))
;; running ["C:\\PROGRA~1\\Internet Explorer\\IEXPLORE.EXE" "http://127.0.0.1:4849/0/:s"]...
1. Trace: 
(EXT:MAKE-PIPE-OUTPUT-STREAM
 '"\"C:\\PROGRA~1\\Internet Explorer\\IEXPLORE.EXE\" http://127.0.0.1:4849/0/:s")
1. Trace: EXT:MAKE-PIPE-OUTPUT-STREAM ==> #<OUTPUT UNBUFFERED PIPE-OUTPUT-STREAM CHARACTER 980>done

[after clicking the "quit" URL:]
[160]> 

That's an intermittent hack, until CLISP #+Win32 gets proper run-program :wait nil support built-in *and* the hard-coded "&" UNIX hacks disappear from the source code.

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Tue Mar 18 07:13:30 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] inspector via browser: MS-IE solution"
> * Sent on Tue, 18 Mar 2003 13:45:26 +0100
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>

are you saying that CloseHandle does not terminate the process on
win32?!

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
A poet who reads his verse in public may have other nasty habits.

---

From: Arseny Slobodjuck <[email-masked]>
Date: Wed Mar 19 05:11:08 2003

Hello Sam,

> are you saying that CloseHandle does not terminate the process on

I think it doesn't. There is BOOL TerminateProcess(HANDLE,exitcode).
MSDN says that one can CloseHandle of process after it is created.

======
The created process remains in the system until all threads within the
process  have terminated and all handles to the process and any of its
threads have been closed through calls to CloseHandle. The handles for
both  the  process and the main thread must be closed through calls to
CloseHandle. If these handles are not needed, it is best to close them
immediately after the process is created.
======

Last time I checked run-program & friends it worked by running shell
(cmd.exe or command com) and then starting a program from this shell.
Why is this ? It looks strange for me. Only run-shell-command should
work like this, i.e. run-shell-command should call run-program, not
vice versa. Is this a unix way of thinking?

On system level for win32 we have only (shell) and
(make-pipe-*-stream) (I didn't look into it yet), (shell) has no :wait
ability. It seems to me that run-program should be C-coded to use all
the system features, priorities for example. How do you people think ?

If make-pipe-*-stream made like (shell) then it waits for process to
finish. Would it be right if it will never wait ? And how we can close
hanging pipe-stream, by close (adding TerminateProcess to it) ?

Joerg-Cyril Hoehle:

>More generally, some MS-Windows guru will have to add code to CLISP so that it can
>asynchronously start processes. That's what's needed here.

As for me, I am to meditate this week, sorry.

-- 
Best regards,
 Arseny

---

From: Sam Steingold <[email-masked]>
Date: Wed Mar 19 10:41:11 2003

> * In message <[email-masked]>
> * On the subject of "Re[2]: [clisp-list] inspector via browser: MS-IE solution"
> * Sent on Wed, 19 Mar 2003 23:14:35 +1000
> * Honorable Arseny Slobodjuck <[email-masked]> writes:
>

this is because SHELL and MAKE-PIPE-*-STREAM accept shell commands, not
program names, so this is the easy path.

> hanging pipe-stream, by close (adding TerminateProcess to it) ?

We need a single cross-platform function, say, EXECUTE:

(EXECUTE program &key (arguments '()) (wait t)
                      (input (if wait ':terminal))
                      (output (if wait ':terminal))
                      (if-input-does-not-exist ':error) 
                      (if-output-exists ':overwrite) 
                      (indirectp nil))

 ARGUMENTS: a list of string arguments (argv)

 WAIT: wait for termination or return right away

 INPUT: :terminal to use stdin
        :stream to create and return an input stream
        open input stream object to use this stream
        pathname designator to use this file [this does NOT contradict
          the use of file streams as pathname designators]
        NIL no input

 IF-INPUT-DOES-NOT-EXIST: action when INPUT is a pathname designator and
        the file does not exist (:ERROR or a valid INPUT arg)

 OUTPUT: :terminal to use stdout
        :stream to create and return an output stream
        open output stream object to use this stream
        pathname designator to use this file [this does NOT contradict
         the use of file streams as pathname designators]
        NIL no output

 IF-OUTPUT-EXISTS: action when OUTPUT is a pathname designator and the
        already file exists (:OVERWRITE or :ERROR or :APPEND or valid
        OUTPUT arg)

 INDIRECTP: use a shell

return value: when WAIT is T, return the exit status of the program.
when WAIT is NIL, return 3 values
        PID
        INPUT stream
        OUTPUT stream
        [what about the error stream?]

all other functions should be based on this one, e.g.,

 (defun make-pipe-input-stream (cmd)
   (nth-value 1
     (execute cmd :indirect t :input :stream :output nil :wait nil)))

and probably deprecated.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Fighting for peace is like screwing for virginity.