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-04 21:23 "rc" shell maintainer? Vincent Broman
@ 1998-02-05  1:17 ` Tom Culliton
  1998-02-05 11:46 ` Tim Goodwin
  1 sibling, 0 replies; 17+ messages in thread
From: Tom Culliton @ 1998-02-05  1:17 UTC (permalink / raw)
  To: broman; +Cc: debian-devel, rc, culliton

On Wed, 04 Feb 1998 16:23:32 EST, Vincent Broman wrote:
> 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.

Yes, the mailing list is pretty quiet these days... ;-)

The vanilla distribution works fine with Linux as far as I'm aware and
Tim Goodwin is the maintainer.  Most of the work I've done is to make
it work properly with GNU readline, and my current version works well
enough that I haven't done any development on it in a long while.
(I'll gladly share my current version with anyone who is interested.)
I would volunteer to help, but aside from my work commitments, I'm
currently involved in a couple of Python related side projects and my
plate is very full indeed.

Tom


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

* Re: "rc" shell maintainer?
  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
  1 sibling, 1 reply; 17+ messages in thread
From: Tim Goodwin @ 1998-02-05 11:46 UTC (permalink / raw)
  To: broman; +Cc: debian-devel, rc

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

Can't help here.

>                                          There is also an
> unstable rc-1.5b2 owned by debian-qa, I think,

By "unstable", do you mean that you are aware of specific problems?  If
so, *please* let me know about them.

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

Yes, it's been fairly quiet around here.  The current status of rc-1.5b2
is this.

o There is a significant problem around the wait() code, which can cause
rc to hang on (at least) Linux systems if you '^C' an application.
There is a fix for this in the development version, but I'm not entirely
happy with it yet.

o There is a different bug near wait() which I haven't had a chance to
track down yet.

o There is a major thinko in the autoconf handling of signals, which
causes problems on RedHat 5.0 (but hasn't been reported anywhere else).
I believe this will be straightforward to fix.

o Some minor tweaks and enhancements to configure have been requested.

I haven't had much time recently to spend on rc, but as you can see from
the above list, there's not much to be done before I release rc-1.5b3,
and I *hope* that will be the last beta before a full rc-1.5 release
(but maybe not :-).

Again, if you've had any problems with rc-1.5b2, whether with the
autoconfiscated build process or with the shell itself, please let me
know.

Thanks,

Tim.


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

* Re: "rc" shell maintainer?
  1998-02-05 11:46 ` Tim Goodwin
@ 1998-02-05 21:48   ` Vincent Broman
  1998-02-06 18:00     ` Tim Goodwin
  0 siblings, 1 reply; 17+ messages in thread
From: Vincent Broman @ 1998-02-05 21:48 UTC (permalink / raw)
  To: rc

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

I tried out rc-1.5b2 on my SunOS 4.1.3 (with most Sun patches) machine
and gcc-2.7.2, and I got a core dump during trip.  Any suggestions?

Program received signal SIGSEGV, Segmentation fault.
0xf773470c in malloc ()
(gdb) bt
#0  0xf773470c in malloc ()
#1  0xa55c in ealloc (n=12) at nalloc.c:115
#2  0x7398 in get_var_place (s=0xc8f8 "*", stack=TRUE) at hash.c:151
#3  0xc80c in varassign (name=0xc8f8 "*", def=0x1b814, stack=TRUE) at var.c:18
#4  0xcc18 in starassign (dollarzero=0x1b838 "", a=0x1b810, stack=TRUE)
    at var.c:143
#5  0x239c in funcall (av=0x1b800) at builtins.c:77
#6  0x3d0c in exec (s=0x2374, parent=TRUE) at exec.c:90
#7  0xd494 in walk (n=0x1b788, parent=TRUE) at walk.c:37
#8  0x8694 in doit (execit=TRUE) at input.c:296
#9  0x9fa4 in main (argc=2, argv=0xf7ffef4c, envp=0xf7ffef50) at main.c:98

This appears to bomb in malloc while the argument list is being set up
to execute "submatch 'umask bad' 'bad umask' 'bad umask'".
I have essentially no trouble on another SunOS 4.1.4 machine
with the same source code.
This problem occurs with readline, editline, or nothing added.
The following are the only local changes I've made.

- --- config.h.in.orig	Mon Jul  7 08:43:53 1997
+++ config.h.in	Wed Feb  4 15:40:59 1998
@@ -2,4 +2,5 @@
 #undef STDC_HEADERS
 
+#undef HAVE_SYS_TYPES_H
 #undef HAVE_SYS_RESOURCE_H
 #undef RLIMIT_NEEDS_KERNEL
- --- configure.in.orig	Mon Jul  7 08:43:53 1997
+++ configure.in	Wed Feb  4 16:48:10 1998
@@ -277,10 +277,14 @@
 AC_ARG_WITH(editline, [  --with-editline         Simmule Turner's line editing],
 	AC_CHECK_LIB(edit, readline,
- -		AC_DEFINE(READLINE) LIBS="$LIBS -ledit",
+		AC_DEFINE(READLINE)
+		LIBS="-ledit $LIBS",
 		AC_MSG_WARN(editline library not found)))
 
 AC_ARG_WITH(readline, [  --with-readline         Bloated GNU line editing],
+	AC_CHECK_LIB(termcap,tputs,LIBS="-ltermcap $LIBS",
+		AC_CHECK_LIB(ncurses,tputs,LIBS="-lncurses $LIBS"))
 	AC_CHECK_LIB(readline, readline,
- -		AC_DEFINE(READLINE) LIBS="$LIBS -lreadline -ltermcap",
+		AC_DEFINE(READLINE)
+		LIBS="-lreadline $LIBS",
 		AC_MSG_WARN(readline library not found)))
 
- --- which.c.orig	Mon Jul  7 08:43:53 1997
+++ which.c	Wed Feb  4 17:02:32 1998
@@ -20,5 +20,5 @@
 #define X_ALL (X_USR|X_GRP|X_OTH)
 
- -extern int stat(const char *, struct stat *);
+extern int stat(char *, struct stat *);
 
 static bool initialized = FALSE;
@@ -88,5 +88,5 @@
 		gid = getegid();
 #if HAVE_GETGROUPS
- -		ngroups = getgroups(0, (gid_t *)0);
+		ngroups = getgroups(0, (GETGROUPS_T *)0);
 		gidset = malloc(ngroups * sizeof(gid_t));
 		if (!gidset)


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

iQCVAwUBNNozTGCU4mTNq7IdAQGtUwP/W/hnkSZKulAZhodR7+b3fX+M1WnISqLp
XHB614mZVY0prcuoPpf0sXwb4nxLu3R03PhXCsymGnxzmyPR9nzqY+zOjniZd8SA
ow6h59DBPA3Or5ULOWJfeSC/+K53s7dXwbS1FH9QkclF/hhICd1u6Uzf5A6pa+ND
8l3Anxd9/X8=
=28Zb
-----END PGP SIGNATURE-----


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

* Re: "rc" shell maintainer?
  1998-02-05 21:48   ` Vincent Broman
@ 1998-02-06 18:00     ` Tim Goodwin
  1998-02-06 22:54       ` Vincent Broman
                         ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Tim Goodwin @ 1998-02-06 18:00 UTC (permalink / raw)
  To: broman; +Cc: rc

Thanks for the bug report.

> I tried out rc-1.5b2 on my SunOS 4.1.3 (with most Sun patches) machine
> and gcc-2.7.2, and I got a core dump during trip.  Any suggestions?

This change looks wrong to me.

> - -		ngroups = getgroups(0, (gid_t *)0);
> +		ngroups = getgroups(0, (GETGROUPS_T *)0);

There was a bug in rc-1.5b2, but the fix for 1.5b3 will be as appended.

(Incidentally, I finally tracked this one down using ElectricFence.
Thanks to Bruce Perens for a marvellous piece of software.)

Tim.

--- release/rc-1.5b2/which.c	Mon Jul  7 16:43:32 1997
+++ rc-1.5b3/which.c	Thu Feb  5 15:23:59 1998
@@ -88,7 +88,7 @@
 		gid = getegid();
 #if HAVE_GETGROUPS
 		ngroups = getgroups(0, (gid_t *)0);
-		gidset = malloc(ngroups * sizeof(gid_t));
+		gidset = malloc(ngroups * sizeof(GETGROUPS_T));
 		if (!gidset)
 			uerror("malloc");
 		else


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

* Re: "rc" shell maintainer?
  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
  2 siblings, 0 replies; 17+ messages in thread
From: Vincent Broman @ 1998-02-06 22:54 UTC (permalink / raw)
  To: rc

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

tgoodwin@cygnus.co.uk replied to me:
>> I tried out rc-1.5b2 on my SunOS 4.1.3 (with most Sun patches) machine
>> and gcc-2.7.2, and I got a core dump during trip.  Any suggestions?
>
>This change looks wrong to me.
>
>> -		ngroups = getgroups(0, (gid_t *)0);
>> +		ngroups = getgroups(0, (GETGROUPS_T *)0);

The reason for GETGROUPS_T (which POSIX requires to be gid_t)
is that some systems, like sunos413, fail to conform to posix
by using int's instead of gid_t's for the arrays of groups.
This change is for pedantic consistency, NULL being all zeroes
for all the hardware I ever deal with.

About the core dump...
It looks like the binary built on 413 runs fine on 414 but dumps core
on a 413 machine.  The same thing occurs with a statically linked binary.
Also the same with a binary built on 414.  So the problem is in
my malloc library, I think.  It isn't the realloc(NULL,n) bug.
Suggestions?

Vincent Broman                 broman@nosc.mil                 +1 619 553 1641

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

iQCVAwUBNNuUfWCU4mTNq7IdAQHIagQAhgk52/AdER9BClyhMxKLdwtF5HmZv7wn
zsgzVs9Wrca+iu9pxSI8x2i7fVZ1I0uGhGQ2tEtUyLvRIIOWxmTg2C2NtcJySwLs
nPB0JxpzPOGwc21WBevjvoY36hwiRSYI2gc0Jk6HE51BZlyqJ4pYlPRtQ296/X7L
qQVEOBr0cfE=
=2CWB
-----END PGP SIGNATURE-----


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

* Re: "rc" shell maintainer?
  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
  2 siblings, 0 replies; 17+ messages in thread
From: Vincent Broman @ 1998-02-09 20:31 UTC (permalink / raw)
  To: rc

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

> Did you try the patch I sent, which changes gid_t to GETGROUPS_T on the
> subsequent line, too?

Woops, it didn't sink in that that was an additional patch.
- From your tip, I ended up with the following which seems to work.

- --- which.c.orig	Mon Jul  7 08:43:53 1997
+++ which.c	Mon Feb  9 12:27:55 1998
@@ -33,5 +33,5 @@
 
 static int ingidset(gid_t g) {
- -	gid_t i;
+	int i;
 	for (i = 0; i < ngroups; ++i)
 		if (g == gidset[i])
@@ -88,6 +88,6 @@
 		gid = getegid();
 #if HAVE_GETGROUPS
- -		ngroups = getgroups(0, (gid_t *)0);
- -		gidset = malloc(ngroups * sizeof(gid_t));
+		ngroups = getgroups(0, (GETGROUPS_T *)0);
+		gidset = malloc(ngroups * sizeof(GETGROUPS_T));
 		if (!gidset)
 			uerror("malloc");

Thanks.

V Broman

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

iQCVAwUBNN9nk2CU4mTNq7IdAQFrBQP9GcJ5EBvhJHtt72H8D1tZ1fU69JjsPWEn
3KwTZYUFxKRIbMnqxiNaokdjK2iDlzxagYqZalEhC9oNs/LVBOn1kLL1i0I06mth
sj/aC0wF6/AkdUVP4rWIbv0IF4umlbFW4Ayqyy5AJJo7jH3Z6nw1rgL3ccw+PLPK
33rmO1n8G6c=
=F+kV
-----END PGP SIGNATURE-----


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

* Re: "rc" shell maintainer?
  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
  2 siblings, 1 reply; 17+ messages in thread
From: Vincent Broman @ 1998-02-09 23:45 UTC (permalink / raw)
  To: rc

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

My rc-1.5b2 fails to trip because of the line testing

    prompt=';' if (!~ `` '' {. -i /tmp/dot.$pid>[2=1]} ';hi'^$nl';')

It seems that '. -i' used to output prompts, but in 1.5b2 it does not.
Was this change unintentional?  I'd be uneasy about changing
trip.rc to match spec "improvements".


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

iQCVAwUBNN+U8mCU4mTNq7IdAQGncAQAlXGd9qklVzMZMdMVx3PuKc1cuURUKsQ3
IlDuoAQAYiSihBOAAP8QLCZ6DZHu+n0CbcLGRK82BfY62pgBbnkEis9Wsqez/R+k
7RP30hA0QCdJYBGesapfabPcAvacFoC4ym5dZoTVTsz04gLMDGjzE8gkRJm4kScZ
fto3Io37gy8=
=rstH
-----END PGP SIGNATURE-----


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

* Re: "rc" shell maintainer?
  1998-02-09 23:45       ` Vincent Broman
@ 1998-02-10 23:26         ` Tom Culliton
  1998-02-11 10:45           ` Tim Goodwin
  1998-02-11 21:55           ` Vincent Broman
  0 siblings, 2 replies; 17+ messages in thread
From: Tom Culliton @ 1998-02-10 23:26 UTC (permalink / raw)
  To: broman; +Cc: rc

On Mon, 09 Feb 1998 18:45:04 EST, Vincent Broman wrote:
> My rc-1.5b2 fails to trip because of the line testing
> 
>     prompt=';' if (!~ `` '' {. -i /tmp/dot.$pid>[2=1]} ';hi'^$nl';')
> 
> It seems that '. -i' used to output prompts, but in 1.5b2 it does not.
> Was this change unintentional?  I'd be uneasy about changing
> trip.rc to match spec "improvements".

Hmmm... This sounds familiar, are you building with GNU Readline?  Now
all I have to do is remember what I did to fix it... 8-/

I probably posted a patch...  Aha...  Yes I did, but Tim never picked
it up.  Look back through the archives for a message from me which
moves print_prompt2 from lex.c to input.c amoung other things.  I sent
it before my big signal handling fix.



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

* Re: "rc" shell maintainer?
  1998-02-10 23:26         ` Tom Culliton
@ 1998-02-11 10:45           ` Tim Goodwin
  1998-02-11 22:23             ` Tom Culliton
  1998-02-11 21:55           ` Vincent Broman
  1 sibling, 1 reply; 17+ messages in thread
From: Tim Goodwin @ 1998-02-11 10:45 UTC (permalink / raw)
  To: rc

> > My rc-1.5b2 fails to trip because of the line testing
> > 
> >     prompt=';' if (!~ `` '' {. -i /tmp/dot.$pid>[2=1]} ';hi'^$nl';')
> > 
> > It seems that '. -i' used to output prompts, but in 1.5b2 it does not.
> > Was this change unintentional?  I'd be uneasy about changing
> > trip.rc to match spec "improvements".

This hasn't changed since 1.4: `-i' only works as documented if you
don't use readline or editline.  I guess this is a bug, although I
haven't thought about it much.

(The trip failure is documented in the README file, for what it's
worth.)

> I probably posted a patch...  Aha...  Yes I did, but Tim never picked
> it up.

rc-1.5b2 was purely an autoconfiscation of rc-1.5betadev-1; I didn't
include any patches that had gone to the list.  This was the quickest
way for me to get on top of the project.

>         Look back through the archives for a message from me which
> moves print_prompt2 from lex.c to input.c amoung other things.

OK, I've got that, and will have a look at it.

Thanks,

Tim.


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

* Re: "rc" shell maintainer?
  1998-02-10 23:26         ` Tom Culliton
  1998-02-11 10:45           ` Tim Goodwin
@ 1998-02-11 21:55           ` Vincent Broman
  1 sibling, 0 replies; 17+ messages in thread
From: Vincent Broman @ 1998-02-11 21:55 UTC (permalink / raw)
  To: rc

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

> This sounds familiar, are you building with GNU Readline?

I checked out the prompt issue again.
With readline from GNU or vrl, the prompt is missing,
with no readline, the prompt is there and trip passes.

Another small point....
I notice that with 1.5b2, the trip output includes an additional
spurious "trip complete" line.  This seems to be caused
by the "if (! @{cd /; ~ */a*.$pid tmp/a*})" line.
The forked shell handling the @{} inherits the fn sigexit
defined in trip.rc and executes it when the @{} finishes.
This did not happen in 1.4, probably never before that either.


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

iQCVAwUBNOIeVGCU4mTNq7IdAQEiaQQAwJoe2Jh/UjKswKfNXwtmQxj2p8YePmvH
gzj3q5vNqOz0/LFJU/fiAZbSB0Oe11m97+DVMFYLwdjE9URhUc/nkI/m8Sdug9/d
lB5hHVE9/1vaLh542HDeteRK9FpiVrIAVFYqtoRZVjzYKKBUVtFr1YyrdRvM23KX
Q3hAbM3xfXY=
=7rEK
-----END PGP SIGNATURE-----


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

* Re: "rc" shell maintainer?
  1998-02-11 10:45           ` Tim Goodwin
@ 1998-02-11 22:23             ` Tom Culliton
  1998-02-12 10:23               ` Tim Goodwin
  0 siblings, 1 reply; 17+ messages in thread
From: Tom Culliton @ 1998-02-11 22:23 UTC (permalink / raw)
  To: Tim Goodwin; +Cc: rc

On Wed, 11 Feb 1998 05:45:36 EST, Tim Goodwin wrote:
> > > My rc-1.5b2 fails to trip because of the line testing
> > > 
> > >     prompt=';' if (!~ `` '' {. -i /tmp/dot.$pid>[2=1]} ';hi'^$nl';')
> > > 
> > > It seems that '. -i' used to output prompts, but in 1.5b2 it does not.
> > > Was this change unintentional?  I'd be uneasy about changing
> > > trip.rc to match spec "improvements".
> 
> This hasn't changed since 1.4: `-i' only works as documented if you
> don't use readline or editline.  I guess this is a bug, although I
> haven't thought about it much.

Up until the wait bug cropped up in Linux, rc was tripping cleanly for
me under Linux, Solaris, SunOs, AIX, ... with readline.  The patch for
the prompt problem was pretty obvious when I looked at it.


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

* Re: "rc" shell maintainer?
  1998-02-11 22:23             ` Tom Culliton
@ 1998-02-12 10:23               ` Tim Goodwin
  0 siblings, 0 replies; 17+ messages in thread
From: Tim Goodwin @ 1998-02-12 10:23 UTC (permalink / raw)
  To: rc

> Up until the wait bug cropped up in Linux, rc was tripping cleanly for
> me under Linux, Solaris, SunOs, AIX, ... with readline.

Really?  Hmm...

>                                                          The patch for
> the prompt problem was pretty obvious when I looked at it.

Yup.  Now incorporated into the development version.

> I notice that with 1.5b2, the trip output includes an additional
> spurious "trip complete" line.

Fixed.  A number of calls to setsigdefaults() were removed between 1.4
and 1.5betadev1, but the one after the nSubshell fork() is needed.  I've
reinstated it.

This is the current state of play. I'm not aware of any bugs in my
development version.  I need to review my fix for the wait() race that
Linux exercises.  There are a couple of packaging issues to tidy up.  I
hope to get rc-1.5b3 out in the next week.

Thanks again for all your input.

Tim.


^ 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
  1 sibling, 0 replies; 17+ messages in thread
From: Tim Goodwin @ 1998-02-06 17:45 UTC (permalink / raw)
  To: smarry; +Cc: rc, broman, culliton

> One definite bug (reported to Tim Goodwin) will cause rc to spin calling
> wait(2) if you do:
> 
> {ls & wait} | cat

Fixed in the development version.

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

I have a fix for this, but I'm not completely happy with it yet.  When
I am, and I've fixed a couple of other minor problems, I'll cut a 1.5b3
release for y'all to check out.

Thanks for the bug report.

Tim.


^ 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

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

On 05 Feb 1998 05:01:30 GMT, smarry@pantransit.smar.reptiles.org wrote:
> 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.

Shouldn't the "interrupt_happened" flag prevent this?

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

It sounds like you're running RedHat 5.0 or some other distribution
which uses glibc.  I haven't taken that step, partly on the "beware of
version X.0 of anything" and partly because I'm waiting until I get a
new machine.  Sounds like this is another good reason, having heard
lots of complaints of problems with glibc.

The ultimate solution maybe to move to the world of sigaction/sigblock
where those calls are available.  The signal handling in rc is one of
the hairyest aspects of the code due to portability issues and race
conditions.  Byron spent a lot of time (the change logs are full of
it) fixing race conditions and signal handling before he passed on the
torch.  (BTW - Anyone heard from him recently?)

Tom


^ 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

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