[fpc-pascal]Signals revisited

[md]

Please ignore my earlier posting on signals.

I have found an explanation of many signals at the following web
address:

http://step.polymtl.ca/~ldd/syscalls/syscalls_99.html

Notice on the web page it refers to 
"terminates" and "stops" in parentheses.  
What do you think that means?

Are there signal handlers that actually freeze the process and how do we
override this
behavior if it is true.  Every process should keep executing regardless
of signal handled.

What is still unclear is how to have a signal handle perform internal
processing
and still allow for system default core dumping and process termination.

The core dump is helpful for debugging purposes.

Any help appreciated,

Mark


Michael.VanCanneyt at wisa.be wrote:
> 
> On Tue, 31 Oct 2000, md wrote:
> 
> > FPC developers:
> >
> > Here is a brain teaser.
> >
> > Let us say we have two environments:
> >
> > 1) Normal BASH shell with prompt in TTY1 -  The TERM environment
> > variable will be set to linux
> > 2) KDE Destktop - The TERM environment variable will be set to xterm
> >
> > Under the non-x window environment, how do we fork() / execlp( ) another
> > process so that the new child process
> > will use a different Ttty console to output its writeln( ) information
> > to.
> >
> > Under KDE, I can execute a fork() with execlp( ) and the command line
> > will be as follows 'konsole -e /bin/application arg1'
> >
> > The net effect of this is that the parent process continues in its own
> > console window and the child process will execute
> > in a separte console window. The input/output of each process is now
> > separate to each window.
> >
> > Under non-xwindows environments, .i.e. normal bash shell, How do we
> > fork() / exec( ) a process so that it will be assigned a different TTY
> > or some other means of having a separate console for each process.
> 
> under bash, one would type:
> 
> command args >/dev/ttyX 2>&1 </dev/ttyX &
> 
> or under csh
> 
> command args >& /dev/ttyX </dev/ttyX
> 
> (replace X with the terminal number)
> 
> The /dev/ files need the correct permissions, of course.
> 
> under FPC you would do the following;
> 
>   fork
>   if pid=0 then
>      // Child
>     begin
>     // Same effect as below may be gotten with dup2() !!
>     Close(input);
>     Close(output);
>     Close(stderr);
>     Assign(Input,'/dev/ttyx');
>     Assign(output,'/dev/ttyx');
>     Assign(stderr,'/dev/ttyz');
>     Reset(input);
>     Rewrite(output);
>     Rewrite(stderr);
>     Execlp('command','args')
>     end
>   else
>     begin
>     // Parent
> 
>     end;
> 
> >
> > What this also means that the login process for a given TTY is skipped
> > or avoided so the processes that are started from
> > the runlevel 3 inittab file can spawn processes that will take over a
> > given console.
> 
> You'd better do that, yes.
> 
> >
> > This is different that just logging into a bunch of different consoles
> > and running each process on a given console.  This is where the code is
> > assigning processes to consoles.
> >
> > Any help would be appreciated.
> 
> I hope the above helps.
> 
> Michael.
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal