rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* "rc" shell maintainer?
@ 1998-02-04 21:23 Vincent Broman
  1998-02-05  1:17 ` Tom Culliton
  1998-02-05 11:46 ` Tim Goodwin
  0 siblings, 2 replies; 17+ messages in thread
From: Vincent Broman @ 1998-02-04 21:23 UTC (permalink / raw)
  To: debian-devel, rc

-----BEGIN PGP SIGNED MESSAGE-----

Who is maintaining the rc package for Debian GNU/Linux?

The WNPP doc has said for months that rc is orphaned, but
shimon@i-connect.net created an rc1.4 release in november,
seemingly taking over from Ian Murdock.  There is also an
unstable rc-1.5b2 owned by debian-qa, I think,
but Murdock is listed as maintainer,
and Mark Baker has his name on some stuff in it.

The upstream package maintener seems to be Tim Goodwin,
since last summer, but the mailing list for rc is quiescent.

Vincent Broman,   code D712 Bayside
Space and Naval Warfare Systems Center, San Diego              (was NOSC, NRaD)
San Diego, CA  92152-6145,  USA                          Phone: +1 619 553 1641
Email: broman at spawar.navy.mil or nosc.mil      PGP protected mail preferred.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNNjcJGCU4mTNq7IdAQG5PwP/cymq12qlIJSpMEi5WiEu80PH0Pvcd2Ym
em/YSsGL/EeKz8o51hS7kkjhEiSAiAqNvr0EDDAqp7+LMv169/8zgR/D2CirHvqr
TU5MuW2V+IK+UvDnk48J+1MM0aMBWEQueKi/pw3zHGdEQe8z9+SB8kGX6Cj/nZ27
vZQOTqsn9vs=
=SHFk
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: "rc" shell maintainer?
@ 1998-02-05  5:01 smarry
  1998-02-05 15:25 ` Tom Culliton
  1998-02-06 17:45 ` Tim Goodwin
  0 siblings, 2 replies; 17+ messages in thread
From: smarry @ 1998-02-05  5:01 UTC (permalink / raw)
  To: broman, culliton; +Cc: debian-devel, rc

Hello, this is Marc Moorcroft.  I joined the list shortly after
running into two problems with rc-1.5b2 under Linux.

One definite bug (reported to Tim Goodwin) will cause rc to spin calling
wait(2) if you do:

{ls & wait} | cat

There is another problem with signal handling that is a little more
complicated.  When I upgraded to the 2.0.33 kernel, rc began hanging
occasionally when I interrupted programs, and when I finally got irritated
enough to check it thoroughly, I found that it failed trip.rc at:

kill -2 $pid

The relevant code is rc_wait() in wait.c:

static pid_t rc_wait(int *stat) {
	int r;
	interrupt_happened = FALSE;
	if (!setjmp(slowbuf.j)) {
		slow = TRUE;
		if (!interrupt_happened)
			r = wait(stat);
		else
			r = -1;
	} else
		r = -1;
	slow = FALSE;
	return r;
}

It appears that some of the time, Linux will return from the wait(2)
for the 'kill' process before the signal gets delivered.  On Linux
installations where signal(2) has the System V behaviour (system calls
are interrupted for signals that are caught via signal(2)) rc longjmps
out of the signal handler (a rather alarming practice in itself) to the
top of the enclosing code in rc_wait().  The sequence of events appears
to be:

	The signal is sent,

	the process exits,

	wait(2) returns successfully, and

	before the longjmp gadgetry can be turned off (slow = FALSE),
	the signal handler IMMEDIATELY runs,

	longjmps back to the top of the setjmp block,

and the PID that wait(2) returned is lost.  rc loops forever calling
wait(2) with no children, waiting for the lost PID to turn up.

I've talked to others who have had different problems on other Linux
installations, where caught signals do not interrupt system calls, as
in BSD.  This appears to be due to a difference of opinion between the
libc and glibc people about how signals should behave, but I haven't
investigated it myself.


^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: "rc" shell maintainer?
@ 1998-02-05 19:59 smarry
  0 siblings, 0 replies; 17+ messages in thread
From: smarry @ 1998-02-05 19:59 UTC (permalink / raw)
  To: culliton, smarry; +Cc: broman, debian-devel, rc

Tom Culliton <culliton@clark.net> writes:
>On 05 Feb 1998 05:01:30 GMT, smarry@pantransit.smar.reptiles.org wrote:
>[...]
>> and the PID that wait(2) returned is lost.  rc loops forever calling
>> wait(2) with no children, waiting for the lost PID to turn up.
>
>Shouldn't the "interrupt_happened" flag prevent this?

Unfortunately, no.  Whether it's set to TRUE or FALSE, the setjmp
block gets rerun, and the PID returned from wait(2) (or really wait4(2),
I guess) is discarded.

I should clarify that I'm not the one having the problems with glibc.
They are indeed using RedHat, not sure what version. I'm using
libc.so.5.3.12, which turns out to be out of date, but it's the same
version as on the RedHat distribution of the other system in question.


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~1998-02-12 10:31 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-02-04 21:23 "rc" shell maintainer? Vincent Broman
1998-02-05  1:17 ` Tom Culliton
1998-02-05 11:46 ` Tim Goodwin
1998-02-05 21:48   ` Vincent Broman
1998-02-06 18:00     ` Tim Goodwin
1998-02-06 22:54       ` Vincent Broman
1998-02-09 20:31       ` Vincent Broman
1998-02-09 23:45       ` Vincent Broman
1998-02-10 23:26         ` Tom Culliton
1998-02-11 10:45           ` Tim Goodwin
1998-02-11 22:23             ` Tom Culliton
1998-02-12 10:23               ` Tim Goodwin
1998-02-11 21:55           ` Vincent Broman
1998-02-05  5:01 smarry
1998-02-05 15:25 ` Tom Culliton
1998-02-06 17:45 ` Tim Goodwin
1998-02-05 19:59 smarry

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).