Tcl Source Code

SIGINFO seems to be a BSD-specific signal. It is 
typically sent to the foreground process by pressing 
Ctrl-T.

Some programs -- including cp, dd, fsck, dump -- 
respond to it by outputting their status information 
(progress update).

Tcl scripts should be able to do the same.

This patch is now part of the FreeBSD port...

allow_comments - 1

Ah. Misinterpreted what was going on entirely. Comes of reviewing things when tired.

Patch as submitted had a problem: Linux defines SIGINFO to be the same as SIGPWR for some odd reason. I've committed an updated version with better #ifdef-fery (and yes, I also checked that Tcl now handles every signal that OSX supports so should be OK for other BSD platforms too). Still don't know why this is needed - programs don't exit on SIGINFO - but it is at least supported (in as much as any signal is). Backported to 8.5 too.

data_type - 310894

Donal, you said the EXACT SAME THING TWO YEARS ago. It is perfectly obvious by now, that you've NEVER read the actual patch.

Your "joyful" response to my request to you do so, that you don't respond seriously on Fridays, implied, that sincere attention will be paid the following Monday.

Today, 18 months later, you repeat the same NONSENSE. I think, you owe me an apology...

Once thing that was not obvious from the title or comments, and that Stu was kind enough to mention on the chat, is that the proposal is indeed orthogonal to the (much more ambitious) advent of script-level signal support in the core. We _already_ have a signal-to-string mapping in the core, so that adding just that missing one sounds reasonable. Just why we do is another matter (maybe for wait/waitpid result ?). But refusing the present patch on the grounds that it is too ambitious is a plain error of interpretation.

data_type - 360894

Tcl doesn't expose support for *any* signals at all at the moment, on any platform. Changing this requires quite a lot of work (new code, new docs, new tests) and there are substantial complexities in threaded builds AIUI (not to mention the trickiness of handling the analogs of them on Windows). However, piggy-backing this request on the TclX extension is a reasonable way forward, as it knows about signals already and (intentionally) doesn't have quite such a bureaucratic process for adding features.

Changing this to a FRQ.

This is very simple, innocuous to non-BSD'ers and of potential use/importance to BSD'ers.
Recommend committing/closing.

Logged In: YES 
user_id=79902
Originator: NO

I don't comment responsibly (or read patches) this late on a Friday. :-P

Logged In: YES 
user_id=173641
Originator: YES

Donal, please, comment /responsibly/.

If you only looked into the attached patch, you would've seen the error of your statement.

Specifically, in generic/tclPosixStr.c there is a translation of signal numbers into names.

Logged In: YES 
user_id=79902
Originator: NO

Feels to me like a request for TclX, as Tcl itself currently doesn't expose any signal handling at all.

Logged In: YES 
user_id=173641
Originator: YES

Changing Category to the slightly less bogus value.
Elevating Priority because its been well over a year now.

File Added - 183204: patch-siginfo