destroy and process

[newdep]

Hi Lutz,



According to the manual a pipe 0 is a unused channel ?



Executing this will stop newlisp itself..



>(process {/fuzzy/wuzzy/was/a/woman} 0 0 0)

13245

>(destroy 13245)

true

>

$prompt$>





Now this could be logical or not but i cant yet find a good reason...

because newlisp and the process are both different processes , not

linked. The only that is linked here are the pipes 0 0 0.

[Lutz]

'process' treats pipes specified as 0 (zero) as if no pipe was specified, i.e. no redirections on the stdin, stdout or stderr channels of the launched application are performed, when a 0 is specified for the respective pipe.



So doing (process "/usr/bin/app" 0 0 0) is the same as doing (process "/usr/bin/app")

[newdep]

But is it then logical that (destroy pid) kill newlisp itself?

[Lutz]

Not sure what you mean, can you give me a simple example, I can repeat? When the parent does (destroy pid) only the pid of the child process gets destroyed in my tests.

[newdep]

Owww.. I just tested it on Solaris 10..(SPARC)



What ever I do with process on Solaris 10,

It throws me out of the newlisp-prompt, looks like a return issue...



On linux I keep the newlisp-prompt..





i.e.



>(process "ls -al")

123434

me@promtp$>











when I do this, executing a shell script, a destroy throws me out of newlisp-prompt, on linux this keeps me inside.. ->



> (process "myfile.sh")

21342

>(destroy 21342)

true

me@prompt$>



Here the strange part is that im killing the PID not my own newlisp process..

[Lutz]

Try to redefine the SIGCHLD handler (probably signal number 20, look into signal.h on Solaris 10).



E.g. you could try to make it ignore the signal in the parent or set the OS default handler:

Code Select Expand

; ignore child signals
(signal 20 nil)

; set the OS default handler
(signal 20 true)


[newdep]

Yes on Solaris 10 its 18. (child status changed)



The default is already "ignore".. on Solaris 10,

aha I see in the Doc that newlisp fiddles with the Signals on wait-pid...



The signal trick worked, thanks..





Now my script also runs !!! (process {sdfgfssdfgfdf >/dev/null ...etc..})



pfiew...that was something that cost me some work to figure out..

[newdep]

Lutz,





How to suppress stdout on process?



(process "a-newlisp-script bla1 bla2") returns data to the stdout,

but i dont want this to be displayed..



this does not work (process "a-newlisp-script bla1 bla2 >/dev/null")

because the a-newlisp-script sees in then different main-args..



(process "a-newlisp-script bla1 bla2" 0 2 2) which would redirect

to the stderr of newlisp..but thats not working either..





I would like (silent (process "myscript")) to work ;-)



any idea?

[Lutz]

Create pipes for the process as shown in the manual using the newLISP 'pipe' function, then read the out-pipe from the process and discard the output. See the example in the manual.



Or just use 'exec' which collects stdout of the launched app in a list.

[newdep]

Yes thats why i uses 0 2 2 which are the newlisp, already open io,

..Well that worked once back in version 8.x..



I dont use (exec) for these reasons:

* exec is blocking, its not useful for programs that don't return instantly

  neither is it useful for some specific shell scripts that use 'nohup 'exec

  '&, stderr-only and some more...(they block newlisp)

* Its not returning a pid



So i'm stuck with process...because it always forks and returns a pid.



Let me put it this way... Im using newlisp as a full shell replacement

at the moment which is calling all kinds of scripts and programs.

The problem is, sometimes i need to use process and sometimes exec

because of the IO behaviour of the programs/scripts.. And i dont want

the newlisp script to be hanging on an exec or show stdio from a process..



process it will be next time...have a deadline to catch so cant rewrite the

code at the moment ;-(

[Lutz]

Yes thats why i uses 0 2 2 which are the newlisp, already open io

no, don't use those, try with creating those extra pipes using 'pipe'





ps: you always can simulate the old-style 'process' doing (fork (process ...))