trap handler - SCO

This is a discussion on trap handler - SCO ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: trap handler

  1. 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


  2. Re: trap handler


    ----- 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!


  3. 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


  4. Re: trap handler


    ----- 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!


+ Reply to Thread