----- Original Message -----
From: "Dnix"
Newsgroups: comp.unix.sco.misc
To:
Sent: Friday, June 08, 2007 3:08 PM
Subject: trap handler


> Hi all ,
> Can anyone point out to me what is the environment available too a
> trap handler , when it executes in a .profile
>
> e.g
>
> #.profile for test user
>
> exithandler() {
>
> blabla ;
> exit
>
> }
>
>
> trap exithandler 1 2 3 15
>
> In what context does the exithandler execute , what environment is
> avaibable to it , does it run as the orginal user who logged in and
> used the .profile ? does it have access to local variables set
> in .profile and exported ?
>
>
> Many thanks
> Dnix


Stealing a favorite phrase from an impeccably un-flappable lead developer on
another mail list:

"What happened when you tried it?"

Point being it takes longer to post this question and wait for answers that
it would have to just try a couple simple tests and see directly.

put this in a users .profile:
------------------------------------------
self="$0 $@"
aa=0 bb=0 l=/tmp/eh

eh () {
echo "$0: $@"
echo "$0: $@" >$l
pwd >>$l
set >>$l
alias >>$l
stty -a >>$l
tty >>$l
# anything else you want to know...
exit
}

aa=1

trap "eh Caught 1" 1
trap "eh Caught 2" 2
trap "eh Caught 3" 3
trap "eh Caught 15" 15
------------------------------------------

Then telnet localhost as that user, hit delete, and then go look at /tmp/eh

The rules are the same as any other time for the shell in question. Which
depends on the shell, which is whatever the users login shell is set to,
which is /bin/sh by default but that is merely a default.
In the case of /bin/sh, variables are global, meaning even without
exporting, a variable set in the script any time before (chronologically)
the function was called, is available inside the function. And vice versa,
set or change a variable in the function and the new value is there in the
script after the function call, though in this case you'd never see that
since you are exiting altogether while still in the function. However, $0 $1
$2, $@, $*, $# etc.. reflect the args to the function not the args to the
script.
Different shells have different fine points about this. ksh allows you force
a variable to be local to the function or it's children with typeset for
instance.

>From the example above, /tmp/eh will have:
Line 1 will be: "eh: Caught 2"
And amid the "set" output will be:
aa=1
bb=0
self='-ksh '

aa shows that aa reflects the value as it was at the time the function was
called, not as it was at the time the function definition was read by the
shell.
line 1, and self, shows that $* reflects the args to the function call not
the args to the parent script.
Also shows the login shell for the user I tested this on was ksh not sh, so
you should still try this in sh just to make sure it all works the same.
I only seperated the traps because I wanted to know which signal I received
and I don't know how else to get that.
(I know how to read "man ksh" and "stty -a" so of course I know what should
happen when I press Delete, but the point here is empirical testing.)

--
Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

On Jun 9, 2:48 am, "Brian K. White" wrote:
> ----- Original Message -----
> From: "Dnix"
>
> Newsgroups: comp.unix.sco.misc
> To:
> Sent: Friday, June 08, 2007 3:08 PM
> Subject: trap handler
>
> > Hi all ,
> > Can anyone point out to me what is the environment available too a
> > trap handler , when it executes in a .profile
>
> > e.g
>
> > #.profile for test user
>
> > exithandler() {
>
> > blabla ;
> > exit
>
> > }
>
> > trap exithandler 1 2 3 15
>
> > In what context does the exithandler execute , what environment is
> > avaibable to it , does it run as the orginal user who logged in and
> > used the .profile ? does it have access to local variables set
> > in .profile and exported ?
>
> > Many thanks
> > Dnix
>
> Stealing a favorite phrase from an impeccably un-flappable lead developer on
> another mail list:
>
> "What happened when you tried it?"
>
> Point being it takes longer to post this question and wait for answers that
> it would have to just try a couple simple tests and see directly.
>
> put this in a users .profile:
> ------------------------------------------
> self="$0 $@"
> aa=0 bb=0 l=/tmp/eh
>
> eh () {
> echo "$0: $@"
> echo "$0: $@" >$l
> pwd >>$l
> set >>$l
> alias >>$l
> stty -a >>$l
> tty >>$l
> # anything else you want to know...
> exit
> }
>
> aa=1
>
> trap "eh Caught 1" 1
> trap "eh Caught 2" 2
> trap "eh Caught 3" 3
> trap "eh Caught 15" 15
> ------------------------------------------
>
> Then telnet localhost as that user, hit delete, and then go look at /tmp/eh
>
> The rules are the same as any other time for the shell in question. Which
> depends on the shell, which is whatever the users login shell is set to,
> which is /bin/sh by default but that is merely a default.
> In the case of /bin/sh, variables are global, meaning even without
> exporting, a variable set in the script any time before (chronologically)
> the function was called, is available inside the function. And vice versa,
> set or change a variable in the function and the new value is there in the
> script after the function call, though in this case you'd never see that
> since you are exiting altogether while still in the function. However, $0 $1
> $2, $@, $*, $# etc.. reflect the args to the function not the args to the
> script.
> Different shells have different fine points about this. ksh allows you force
> a variable to be local to the function or it's children with typeset for
> instance.
>
> >From the example above, /tmp/eh will have:
> Line 1 will be: "eh: Caught 2"
> And amid the "set" output will be:
> aa=1
> bb=0
> self='-ksh '
>
> aa shows that aa reflects the value as it was at the time the function was
> called, not as it was at the time the function definition was read by the
> shell.
> line 1, and self, shows that $* reflects the args to the function call not
> the args to the parent script.
> Also shows the login shell for the user I tested this on was ksh not sh, so
> you should still try this in sh just to make sure it all works the same.
> I only seperated the traps because I wanted to know which signal I received
> and I don't know how else to get that.
> (I know how to read "man ksh" and "stty -a" so of course I know what should
> happen when I press Delete, but the point here is empirical testing.)
>
> --
> Brian K. White b...@aljex.com http://www.myspace.com/KEYofR
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

many thanks

I justs can't figure out why a little utility that runs perfectly well
at then end of the .profile or even on the command line after
execution of .profile , would then not run or do its job inside the
trap handler , basicallly its a utility that removes a record from a
file that says the user is logged in

Dnix

----- Original Message -----
From: "Dnix"
Newsgroups: comp.unix.sco.misc
To:
Sent: Saturday, June 09, 2007 4:57 AM
Subject: Re: trap handler


> On Jun 9, 2:48 am, "Brian K. White" wrote:
>> ----- Original Message -----
>> From: "Dnix"
>>
>> Newsgroups: comp.unix.sco.misc
>> To:
>> Sent: Friday, June 08, 2007 3:08 PM
>> Subject: trap handler
>>
>> > Hi all ,
>> > Can anyone point out to me what is the environment available too a
>> > trap handler , when it executes in a .profile
>>
>> > e.g
>>
>> > #.profile for test user
>>
>> > exithandler() {
>>
>> > blabla ;
>> > exit
>>
>> > }
>>
>> > trap exithandler 1 2 3 15
>>
>> > In what context does the exithandler execute , what environment is
>> > avaibable to it , does it run as the orginal user who logged in and
>> > used the .profile ? does it have access to local variables set
>> > in .profile and exported ?
>>
>> > Many thanks
>> > Dnix
>>
>> Stealing a favorite phrase from an impeccably un-flappable lead developer
>> on
>> another mail list:
>>
>> "What happened when you tried it?"
>>
>> Point being it takes longer to post this question and wait for answers
>> that
>> it would have to just try a couple simple tests and see directly.
>>
>> put this in a users .profile:
>> ------------------------------------------
>> self="$0 $@"
>> aa=0 bb=0 l=/tmp/eh
>>
>> eh () {
>> echo "$0: $@"
>> echo "$0: $@" >$l
>> pwd >>$l
>> set >>$l
>> alias >>$l
>> stty -a >>$l
>> tty >>$l
>> # anything else you want to know...
>> exit
>> }
>>
>> aa=1
>>
>> trap "eh Caught 1" 1
>> trap "eh Caught 2" 2
>> trap "eh Caught 3" 3
>> trap "eh Caught 15" 15
>> ------------------------------------------
>>
>> Then telnet localhost as that user, hit delete, and then go look at
>> /tmp/eh
>>
>> The rules are the same as any other time for the shell in question. Which
>> depends on the shell, which is whatever the users login shell is set to,
>> which is /bin/sh by default but that is merely a default.
>> In the case of /bin/sh, variables are global, meaning even without
>> exporting, a variable set in the script any time before (chronologically)
>> the function was called, is available inside the function. And vice
>> versa,
>> set or change a variable in the function and the new value is there in
>> the
>> script after the function call, though in this case you'd never see that
>> since you are exiting altogether while still in the function. However, $0
>> $1
>> $2, $@, $*, $# etc.. reflect the args to the function not the args to the
>> script.
>> Different shells have different fine points about this. ksh allows you
>> force
>> a variable to be local to the function or it's children with typeset for
>> instance.
>>
>> >From the example above, /tmp/eh will have:
>> Line 1 will be: "eh: Caught 2"
>> And amid the "set" output will be:
>> aa=1
>> bb=0
>> self='-ksh '
>>
>> aa shows that aa reflects the value as it was at the time the function
>> was
>> called, not as it was at the time the function definition was read by the
>> shell.
>> line 1, and self, shows that $* reflects the args to the function call
>> not
>> the args to the parent script.
>> Also shows the login shell for the user I tested this on was ksh not sh,
>> so
>> you should still try this in sh just to make sure it all works the same.
>> I only seperated the traps because I wanted to know which signal I
>> received
>> and I don't know how else to get that.
>> (I know how to read "man ksh" and "stty -a" so of course I know what
>> should
>> happen when I press Delete, but the point here is empirical testing.)
>>
>> --
>> Brian K. White b...@aljex.com http://www.myspace.com/KEYofR
>> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
>> filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
>
> many thanks
>
> I justs can't figure out why a little utility that runs perfectly well
> at then end of the .profile or even on the command line after
> execution of .profile , would then not run or do its job inside the
> trap handler , basicallly its a utility that removes a record from a
> file that says the user is logged in
>
> Dnix

Does it not try to run, or run and not work? If it runs at all how far does
it get?
To answer these questions, capture the utils stdout and stderr to a temp
file and see what it says.
also add lines to show the shell can find the util and can read it.

eh () {
l=/tmp/util.log
echo "We're in eh()!" >$l
u=`which util` # is util in path?
echo "$u" >>$l
ls -l $u >>$l # is it readable and executable by this user?
ldd $u >>$l # does is have missing library dependancies?
echo "cmdline: \"util $args ...\" >>$l # are our cmdline args what we
think they are?
util $args... >>$l 2>&1 # run it and capture any output it
generates
exit
}

above assumes that "$args..." is some variables or something that you have
in there that might or might not be what you expect at that time, like $tty
or $LOGNAME or "~/filename" or something. If you don't have anything like
that then just omit, and omit the echo cmdline: too.

What does /tmp/util.log say?

Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!