Very Computer

--
Thanks
Chris Yang
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                                                                  +
+ Chris Yang                    ("`-''-/").___..--''"`-._          +

+ http://gnu.in-china.com        (_Y_.)'  ._   )  `._ `. ``-..-'   +
+ (tel)0532 8702000 x5221      _..`--'_..-_/  /--'_.' ,'           +
+ (pager)95812-8073661        (il),-''  (li),'  ((!.-'             +
+                                                                  +
+ http://gdcsr60.gdc.lucent.com/~chrisy                            +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

POSIX:

   myfun() { list; }

Korn:

   function myfun { list; }

In ksh88,  they behave identically.  But in making ksh93 POSIX
compliant,  Korn had to dumb down the POSIX style behavior.  This
affects a wide variety of issues:

   $0 in POSIX is set to the name of the $0 of the shell
   $0 in Korn is set to the name of the function
   variables typeset in the function are local in Korn, global in POSIX
   In Korn,  traps caught by the caller (script) are reset to their default
   action inside the function.   A trap condition that is not caught or
   ignored by the function causes the function to terminate and the
   condition to be passed on to the caller. In POSIX share all traps
   with the caller.  
   Errors within a Korn function exit the function
   and return control to the calling script.  Errors within a POSIX function
   cause the calling script to exit.

--
Dan Mercer

Opinions expressed herein are my own and may not represent those of my employer.

Hi all,
I have two comments:
1) the function syntax with keyword function does follow ksh88 behaviour

   POSIX based its shell on the common features of different
implementations
   (partly Korn,partly csh, partly intersection of features found in
different OS).
this limits the functionality; at the same time, lots of issues were
left
   unspecified. The most limiting POSIX features sometimes were not
implemented
   see HP-UX posix shell o Solaris ksh.
   Always check your manpages.
   Also built-in alternative test syntax is not POSIX e.g [[ -f myfile
]] ...

2) Beware of signal handling.
   Normally when you set up a signal-handler, you should do your cleanup

   and little else, and then exit.
   Inside an interpreter that does a lot of dynamic allocation, you run
into
   the problem of re-entrancy of malloc. If you have perl somewhere,
this is
   a known problem: the interpreter may crash at arbitrary times if you
do too
   much signal handling -- look at perldoc and camel book .

let me give one example with USR1

I want to set up temporization so that every N=60 seconds I do
something.
One way would be to have a child sending SIGUSR to its parent.

tempor(){
...whatever

Quote:}

timer(){
while true
do
  kill -USR1 $$
sleep 60
done

Quote:}

...some infinite loop or whatever

some variant of such a script dumped core at arbitrary times in HP-UX
and Solaris
got some strange behaviour with bash: No core but sometimes the script
would stop
saying it received a SIGINT ????
could be working fine a few days.

I don't know what you want to do with USR1
my workaround was to use poor man's semaphores i.e a 0-sized file

cheers

Hi all,
I have two comments:
1) the function syntax with keyword function does follow ksh88 behaviour

   POSIX based its shell on the common features of different
implementations
   (partly Korn,partly csh, partly intersection of features found in
different OS).
this limits the functionality; at the same time, lots of issues were
left
   unspecified. The most limiting POSIX features sometimes were not
implemented
   see HP-UX posix shell o Solaris ksh.
   Always check your manpages.
   Also built-in alternative test syntax is not POSIX e.g [[ -f myfile
]] ...

2) Beware of signal handling.
   Normally when you set up a signal-handler, you should do your cleanup

   and little else, and then exit.
   Inside an interpreter that does a lot of dynamic allocation, you run
into
   the problem of re-entrancy of malloc. If you have perl somewhere,
this is
   a known problem: the interpreter may crash at arbitrary times if you
do too
   much signal handling -- look at perldoc and camel book .

let me give one example with USR1

I want to set up temporization so that every N=60 seconds I do
something.
One way would be to have a child sending SIGUSR to its parent.

tempor(){
...whatever

Quote:}

timer(){
while true
do
  kill -USR1 $$
sleep 60
done

Quote:}

...some infinite loop or whatever

some variant of such a script dumped core at arbitrary times in HP-UX
and Solaris
got some strange behaviour with bash: No core but sometimes the script
would stop
saying it received a SIGINT ????
could be working fine a few days.

I don't know what you want to do with USR1
my workaround was to use poor man's semaphores i.e a 0-sized file

cheers

...
trap 'INIT=1;echo Catched' USR1
(executable &)
....

but the same code runs into two different result:
under ksh88i, works fine, USR1 captured. but under
ksh93 nothing happen. when i added following lines
ahead of my script (force to invoke ksh88)

if [[ `~` == ~ ]]; then
        exec /opt/bin/ksh88 $0
fi
it works either, i determined that there's some tricky
differences between ksh88 and ksh93 on handling SIGUSR1
but i don't know what it be

Chris.

   $ trap
   $ trap 'echo usr1' usr1
   $ trap
   16:echo usr1
   $ (trap)
   $ ksh93
   $ trap
   $ trap 'echo usr1' usr1
   $ trap
   trap -- 'echo usr1' USR1
   $ (trap)
   trap -- 'echo usr1' USR1

How is your executable sending usr1 back to the shell?  If you are
sending it to the parent process id,  you are getting the pid of
the subshell,  not the shell.  You could pass the process id

   (executable $$ &)

Why are you starting executable in a subshell?

--
Dan Mercer

Opinions expressed herein are my own and may not represent those of my employer.