Re: Why doesn't signal handlers export?

Re: Why doesn't signal handlers export?

[d7stfax]

Chris Siebenmann writes: "... what, don't other people write scripts
in rc? :))" I blush in pure shame. What an extremely stupid mistake to
make, especially since I seem to have done nothing *but* writing rc
shell scripts for the last few weeks. Of course I don't want signal
handlers to export to a shell script. I freely admit that I didn't
think about that when I said that "I saw no problems with letting that
happen." or words to that effect. Since I was indeed starting the rc:s
in question from a shell script (.xsession) I really must have been
out of contact with the uppermost part of my anatomy, on that
occasion.

Well that said, (better stop now before everybody thinks I'm a
complete wimp ;-)), I of course poked around the sources, and in no
time (almost) had a running rc that recognized signal handler
functions exported from the parent, really simple to add, just a few
lines of code.  Then I read the CHANGES file in the distribution and
realised that that was probably in order since Byron had *removed* the
export of signal handlers in the transition from version 1.0 or some
such... Well, I hadn't planned to export all signal handlers blindly,
but rather some keyword: 'export sig!whatever!', or some such. Hacking
the sources wasn't a complete waste of time however, I have been
planning to read the sources to rc for some time now, and what I saw
in no ways detered me from continuing. I just needed an excuse to
start doing it. And I also *suspect* but I haven't thought it over,
that one would be introducing a security hole in letting the value of
a signal handler be read from the environment into a shell script.
There is of course the possibility of restricting the import to
interactive shells, but now it's getting complicated enough not to be
worth the effort, switching on interactive vs noninteractive, and
introducing 'export', and of course not letting all signal handlers
export, such as sigterm, sigquit and a few others.

So, after having read (or rather searched) through the archive, I must
confess that I haven't read it thoroughly, I came to the conclusion
that: indeed 'prompt' it is. Thanks for pointing me in the right
direction, and avoiding what could easily have been me advocating a
case of 'creeping featurism,' sometimes one needs the right
perspective.  I still think that there is a bug in the man page, it
should be stated clearly that signal handlers doesn't export like
ordinary functions. As it is now one (I at least) was lulled into
drawing parallels between functions and signal handlers that I
shouldn't have done, them being similar in other areas.

Regards,
-- 
Stefan Axelsson,			Chalmers University of Technology,
d7stfax@dtek.chalmers.se		Sweden

Re: Why doesn't signal handlers export?

[Chris Siebenmann]

 My thought: it's very rarely appropriate to actually share (rc) signal
handler functions from parent to child; far more often (especially in
scripts -- what, don't other people write scripts in rc? :)) you want
to not share things. Most cases I can think of where sharing would be
nice are interactive, and there you can have a prompt function that
sets everything up as necessary (see the mailing list archives for how).

	- cks

Why doesn't signal handlers export?

[d7stfax]

I thought I had found a bug in rc when I discovered that a signal
handler I had defined didn't show up in a subshell. On careful
examination of the man page I (think) I found that this is indeed the
called for action:

"Another note: whatis -s > file cannot be used
          to  store  the state of rc's signal handlers in a file,
          because builtins with redirections are run  in  a  sub-
          shell,  and rc always restores signal handlers to their
          default value after a fork()."

I interpret this as: When I exec a new shell from my current one, I
loose all signal handlers. Correct? (On a tangent, if this is indeed
so, I think it should be stated more clearly, and not as a side note
to "whatis.") I scanned the old rc-list, distributed with the source,
and there Byron states that he mainly uses signal handlers for clean
up and exit type work. In this case however, i try to trap SIGWINCH so
that I can get my TERMCAP variable updated when I resize an xterm.

So would some kind soul (Hi Byron ;-)) tell me why I cannot have the
same signal handlers in the child as in the parent? I could really use
it, and I see no great semantical problem with letting me have it
either.  (Implementationwise I don't know, I haven't read the sources
that well yet.)

Thanks,
-- 
Stefan Axelsson,			Chalmers University of Technology,
d7stfax@dtek.chalmers.se		Sweden