Marc Mertens <mmert...@vt4.net> writes: > I run CLISP in unix,linux or solaris and wants to get the process id of > the running lisp process. Can someone tell me how I can do this.
This assumes there's only one Lisp running on the system at a time.
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
This can't work - in particular it can't work if there is more than one image running. You need, somehow, to ask the process itself what its PID is. A horrible hack would be to spawn a bash and ask it for the value of $PPID, which will be its parent, and therefore, you. Better would be to compile some foreign call to getpid...
* Marc Mertens | I run CLISP in unix,linux or solaris and wants to get the process id of | the running lisp process. Can someone tell me how I can do this.
Have you tried (apropos "pid")?
(Curiously, the only Common Lisp implementation I have here that does /not/ accept the above is Allegro CL in their "ansi mode", in which they force you to write (apropos "pid" nil nil t) if you want case-insensitive matches -- there is no way to make the last argument default to true! No wonder case-sensitivity hurts more than it should.)
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <e...@naggum.no> writes: > * Marc Mertens > | I run CLISP in unix,linux or solaris and wants to get the process id of > | the running lisp process. Can someone tell me how I can do this.
> Have you tried (apropos "pid")?
in ilisp, C-c i on pid gives:
PID is the symbol PID, lies in #<PACKAGE COMMON-LISP-USER>, is accessible in the package COMMON-LISP-USER.
#<PACKAGE COMMON-LISP-USER> is the package named COMMON-LISP-USER. It has the nicknames CL-USER, USER. It imports the external symbols of the packages COMMON-LISP, EXT and exports no symbols, but no package uses these exports.
> * Marc Mertens > | I run CLISP in unix,linux or solaris and wants to get the process id of > | the running lisp process. Can someone tell me how I can do this.
> Have you tried (apropos "pid")?
Command: clisp i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `-+-' / 8 8 8 ooooo 8oooo `-__|__-' 8 8 8 8 8 | 8 o 8 8 o 8 8 ------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 1994-1997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 1999
[1]> (apropos "pid")
[nothing output]
Yes, and it did not find anything on my version of CLisp. Does it work on the most recent version?
can be wrapped up into a function, and is preferable to grepping ps and keeping your fingers crossed it doesn't pick up someone else's CLisp process.
> Erik Naggum, Oslo, Norway
Le Hibou -- Dalinian: Lisp. Java. Which one sounds sexier? RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders, drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd, with no life or social skills.
* Donald Fisk | Yes, and it did not find anything on my version of CLisp. | Does it work on the most recent version?
Well, I am just shocked. (APROPOS "PID") has produced useful functions on all the Common Lisp environments I have used under all the Unices I have used Common Lisp on, including all versions of CLISP. (I am in the process of becoming Certified Microsoft-Free, so if I admit to knowing anything about what happens in The Other Realm, my certification may be in jeopardy.)
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <e...@naggum.no> writes: > (Curiously, the only Common Lisp implementation I have here that does > /not/ accept the above is Allegro CL in their "ansi mode", in which they > force you to write (apropos "pid" nil nil t) if you want case-insensitive > matches -- there is no way to make the last argument default to true! > No wonder case-sensitivity hurts more than it should.)
Well, Lucid also chose the wrong default for APROPOS and APROPOS-LIST. It is trivial for a user of LCL to patch these functions to call the underlying LCL:APROPOS-DRIVER subroutine (where the real action happens) selecting the correct behavior, but these functions really ought to have had the more intuitive behavior out-of-the-box.
Lucid also dropped the ball by not having LCL startup in an ANSI compatible mode by default. To this day, one has to load an optional submodule in Xanalys Liquid Common Lisp to create the COMMON-LISP and COMMON-LISP-USER packages with ANSI symbols.
> * Donald Fisk > | Yes, and it did not find anything on my version of CLisp. > | Does it work on the most recent version?
> Well, I am just shocked. (APROPOS "PID") has produced useful functions > on all the Common Lisp environments I have used under all the Unices I > have used Common Lisp on, including all versions of CLISP. (I am in the > process of becoming Certified Microsoft-Free, so if I admit to knowing > anything about what happens in The Other Realm, my certification may be > in jeopardy.)
Le Hibou -- Dalinian: Lisp. Java. Which one sounds sexier? RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders, drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd, with no life or social skills.
* Donald Fisk <hibou00000nos...@enterprise.net> | I use: | | Command: clisp --version | CLISP 1999-07-22 (July 1999)
The crucial element appears to be whether you compile with exported syscalls or not. I have just tried to build 2.27, 2.28, 2.29, and 2.30 from the distributed tarballs, but all of them bomb during building, so I gave up on recovering the configuration options necessary to get `getpid´ in, e.g., the LINUX package. My heartfelt thanks go out to the people who take time out of their lives to build CLISP into Debian packages.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
On Tue, 22 Oct 2002 20:48:06 +0000, Tim Bradshaw wrote: > * Chris Beggy wrote: >> (run-program "/sbin/pidof" :arguments '( "lisp.run") :output >> "lisp.pid")
> This can't work - in particular it can't work if there is more than > one image running. You need, somehow, to ask the process itself what > its PID is. A horrible hack would be to spawn a bash and ask it for > the value of $PPID, which will be its parent, and therefore, you. > Better would be to compile some foreign call to getpid...
and this works in Linux but fails in Solaris the result of
(ext:run-shell-command "echo $PPID") is
[4]> (ext:run-shell-command "echo $PPID")
0
on Solaris.
I have tried (apropos 'pid) and its variants but my CLISP does not seems to support it (searching the CLISP documentation on pid or process did not revail anything usefull either).
* Marc Mertens <mmert...@vt4.net> | I have tried (apropos 'pid) and its variants but my CLISP does not seems | to support it (searching the CLISP documentation on pid or process did | not revail anything usefull either).
If you can get CLISP to compile, build it with --with-exported-syscalls. (Note that building from the last four available tarballs all bomb on a stock Debian 3.0 system, so it may not be your fault if you cannot build.)
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
UNIX-GETPID is an external symbol in the UNIX package. Function: #<Function UNIX:UNIX-GETPID {1029C9E9}> Function arguments: There are no arguments. Function documentation: Unix-getpid returns the process-id of the current process. Its defined argument types are: NIL Its result type is: (SIGNED-BYTE 32) On Wednesday, 4/10/02 01:25:46 pm [+1] it was compiled from: target:code/unix.lisp Created: Saturday, 3/23/02 06:50:14 pm GMT Comment: $Header: /home/CVS-cmucl/src/code/unix.lisp,v 1.48.2.8 2002/03/23 18:50:14 pw Exp $
With apropos and describe, one can go hunting for cool functions in one's lisp image all on one's own :)
>and this works in Linux but fails in Solaris the result of
>(ext:run-shell-command "echo $PPID") is
>[4]> (ext:run-shell-command "echo $PPID")
>0
>on Solaris.
On Linux, /bin/sh is really bash, which has the built-in $PPID variable. On Solaris, /bin/sh is Bourne shell, which doesn't.
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
* Marc Mertens wrote: > and this works in Linux but fails in Solaris the result of > (ext:run-shell-command "echo $PPID") is > [4]> (ext:run-shell-command "echo $PPID") > 0 > on Solaris.
Yes, this is because Solaris's default shell is actually a Bourne Shell, not bash dressed up (or something), and PPID is something that bash invented (or maybe some other sh derivative that got inherited by bash...).
In any case this is a *really* bad way of getting the pid of a process...
