rc,linux,signal,readline

rc,linux,signal,readline

[Russell Davies]

 Hi,
 	I have been trying for a while now to get the following 
 	working under linux..without success..
 
 	a _dynamically linked_ rc shell with;
 
	* readline (vi-key) command line editing.

 	*  sigints/sigquits working properly (atm they simply do nothing
 	until the next keypress, I want a newline with ';' after a
 	sigint (yes I tried setting fn signint { echo }) as you would
 	expect from most shells)
 
 	I like some of the features of rc and would like swap shells
 	completely but if I have to complile statically just for these
 	simple features, then the difference in size isnt enough to
 	motivate me to quit using bash.
 	
 	If anyone has compiled an rc shell with the properties mentioned
 	above, I would love to hear from you..
 
 	thanks,
 		r.

Re: rc,linux,signal,readline

[Tim Goodwin]

>  	I have been trying for a while now to get the following 
>  	working under linux..without success..

Are you using rc1.5b2 and readline 2.1?  Older versions of readline
definitely don't get on with rc...  You can get the latest rc from here.

    ftp://ftp.pipex.net/people/tim/rc-1.5b2.tar.gz

I believe this combination mostly works (although personally I use
editline).  There's a known race condition under Linux which I hope to
fix very soon.

Please let me know if you can't get it working to your satisfaction.

>  	I like some of the features of rc and would like swap shells
>  	completely but if I have to complile statically just for these
>  	simple features, then the difference in size isnt enough to
>  	motivate me to quit using bash.

Which "size" are you trying to economize on?  Shells should
usually be linked statically anyway (see the recent thread on
comp.unix.internals)... for the next release, I'm considering adding
`-static' to the link if we're using gcc.

Tim.

Re: rc,linux,signal,readline

[Tom Culliton]

On Tue, 12 Aug 1997 04:19:37 EDT, Russell Davies wrote:
>  Hi,
>  	I have been trying for a while now to get the following 
>  	working under linux..without success..
>  
>  	a _dynamically linked_ rc shell with;

I have sent patches to the list which take care of all the rest of
your requests, but for some reason the shared/dynamic version of GNU
readline doesn't work like the static version.  At least thats my
first guess as to the problem.  Without readline it works "properly"
and trips clean when linked dynamically.  With readline it doesn't.

The size of the statically linked image is with readline unde RedHat
Linux 4.2 is 308264 bytes, actually slighty bigger than dynamically
linked bash at 300668.  On the other hand I think it was Chris (cks)
(or maybe Paul) who once gave some good reasons why a shell should be
statically linked.

> 	* readline (vi-key) command line editing.

I haven't tested this but it's in there.

>  	*  sigints/sigquits working properly (atm they simply do nothing
>  	until the next keypress, I want a newline with ';' after a
>  	sigint (yes I tried setting fn signint { echo }) as you would
>  	expect from most shells)

The problem is that without my patches readline catches and ignores
these signals.  If you want to use readline and have reasonable signal
behaviour you NEED those patches.  The other option is to use a
different command line editting package, but I don't know of one that
works as well as GNU readline.

>  	I like some of the features of rc and would like swap shells
>  	completely but if I have to complile statically just for these
>  	simple features, then the difference in size isnt enough to
>  	motivate me to quit using bash.

If size is your primary concern stick to bash, it tracks the Posix
shell standard and will let you work in the generally more portable
sh/ksh/bash world.  If on the other hand you find ksh and it's ilk to
be full of ugly hacky kitchen sink Rube Goldbergisms with a syntax
that only a mother could love, and more obscure "features" than the
biggest Swiss Army knife ever made, switch to rc.  Tom Duff started
from scratch and produced a clean, predictable, elegant design that
includes most of the good ideas from traditional Unix shells and got
rid of most of the cruft.

>  	If anyone has compiled an rc shell with the properties mentioned
>  	above, I would love to hear from you..
>  
>  	thanks,
>  		r.

Re: rc,linux,signal,readline

[Paul Haahr]

> >  	I have been trying for a while now to get the following 
> >  	working under linux..without success..
> >  
> >  	a _dynamically linked_ rc shell with;
> 
> I have sent patches to the list which take care of all the rest of
> your requests, but for some reason the shared/dynamic version of GNU
> readline doesn't work like the static version.  At least thats my
> first guess as to the problem.  Without readline it works "properly"
> and trips clean when linked dynamically.  With readline it doesn't.

Could it be that you're getting the wrong readline.so?  There were real
changes between the 1.x and 2.x versions, as I remember.

> The size of the statically linked image is with readline unde RedHat
> Linux 4.2 is 308264 bytes, actually slighty bigger than dynamically
> linked bash at 300668.  On the other hand I think it was Chris (cks)
> (or maybe Paul) who once gave some good reasons why a shell should be
> statically linked.

I probably said something along those lines, back in the days when we
worried about the startup time.  10x performance improvement moots the
issue for me.

You should have *some* shell, typically lying around in /sbin these
days, which is not dynamically linked, for those times when everything
else is broken.  If rc is your root shell, then making it statically
linked is probably a good idea.

--p

Re: rc,linux,signal,readline

[Tom Culliton]

On Tue, 12 Aug 1997 14:24:34 PDT, Paul Haahr wrote:
> > >  	I have been trying for a while now to get the following 
> > >  	working under linux..without success..
> > >  
> > >  	a _dynamically linked_ rc shell with;
> > 
> > I have sent patches to the list which take care of all the rest of
> > your requests, but for some reason the shared/dynamic version of GNU
> > readline doesn't work like the static version.  At least thats my
> > first guess as to the problem.  Without readline it works "properly"
> > and trips clean when linked dynamically.  With readline it doesn't.
> 
> Could it be that you're getting the wrong readline.so?  There were real
> changes between the 1.x and 2.x versions, as I remember.

Not as far as I could tell.  There are no rcs ident strings in the
libraries (Hey, Chet!) but the libs are:

-rw-r--r--   1 root     root       154214 Aug 19  1996 /usr/lib/libreadline.a
-rw-r--r--   1 root     root       132113 Aug 19  1996 /usr/lib/libreadline.so.2.0

and look pretty much the same via nm.  I spent quite a bit of time on
this but not being an expert on dynamic linking didn't dig too deep.

BTW - does anyone know why on DEC Alpha OSF1, using the libreadline
from the freeware CD, it dumps core when I hit ^R?  The trace back
looks like this:

(gdb) core core
Core was generated by `rc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/shlib/libc.so...done.
#0  0x3ff800d1870 in strlen ()
(gdb) where
#0  0x3ff800d1870 in strlen ()
#1  0x3ff800d94f0 in _doprnt ()
#2  0x3ff800d5538 in sprintf ()
#3  0x120034da4 in rl_message (format=0x14000a830 "%s", arg1=1073818992,
    arg2=0) at display.c:669
#4  0x120035a20 in rl_display_search (search_string=0x140015d00 "",
    reverse_p=1, where=-1) at isearch.c:106
#5  0x120035c8c in rl_search_history (direction=-1, invoking_key=18)
    at isearch.c:193
#6  0x1200358a0 in rl_reverse_search_history (sign=1, key=18) at isearch.c:61
#7  0x120020970 in rl_dispatch (key=18, map=0x140000fb0) at readline.c:636
#8  0x12002007c in readline_internal () at readline.c:345
#9  0x12001fe80 in readline (prompt=0x140012c80 "[culliton@cns5]rc-1.5tjc/ : ")
    at readline.c:268
#10 0x120016f18 in ugchar ()
#11 0x120016fe4 in ugchar ()
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0xa79d9180f43ffffd
This warning occurs if you are debugging a function without any symbols
(for example, in a stripped executable).  In that case, you may wish to
increase the size of the search with the `set heuristic-fence-post' command.

Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.


Pretty cool, huh? ;-)

Re: rc,linux,signal,readline

[Tim Goodwin]

> > >                                 Without readline it works "properly"
> > > and trips clean when linked dynamically.  With readline it doesn't.

> Not as far as I could tell.  There are no rcs ident strings in the
> libraries (Hey, Chet!) but the libs are:
> 
> -rw-r--r--   1 root     root       154214 Aug 19  1996 /usr/lib/libreadline.a
> -rw-r--r--   1 root     root       132113 Aug 19  1996 /usr/lib/libreadline.so.2.0

Identical to the RedHat 4.2 (Linux 2.0.30) box on my desk :-).

Sorry, I got lost here.  What exactly is the problem?  I just built
rc-1.5b2 (now available from the usual FTP site, thanks Chris!)
dynamically linked with readline...

    ; ldd rc
            libtermcap.so.2 => /lib/libtermcap.so.2.0.8
            libreadline.so.2 => /usr/lib/libreadline.so.2.0
            libc.so.5 => /lib/libc.so.5.3.12

...and it all seems to work ok.  Specifically, INTs and QUITs work as I
expect.  Can you let me know what to look for so I can fix it?

> BTW - does anyone know why on DEC Alpha OSF1, using the libreadline
> from the freeware CD, it dumps core when I hit ^R?

Erp.  Sorry, I don't have any Alphas handy.  I suspect a readline bug,
but if anyone can pin this down to rc I'll try to fix it...

Tim.

Re: rc,linux,signal,readline

[Tom Culliton]

On Wed, 13 Aug 1997 14:33:53 BST, Tim Goodwin wrote:
> Sorry, I got lost here.  What exactly is the problem?  I just built
> rc-1.5b2 (now available from the usual FTP site, thanks Chris!)
> dynamically linked with readline...

Hmmm... I couldn't get the rc-1.5b2 distribution to do that under the
same version of Linux you say you're using.  It claims it can't find
-lreadline.  (It's there in /usr/lib/readline.* dammit!)  Hacking it
into config.h and Makefile by hand seems to work.

>     ; ldd rc
>             libtermcap.so.2 => /lib/libtermcap.so.2.0.8
>             libreadline.so.2 => /usr/lib/libreadline.so.2.0
>             libc.so.5 => /lib/libc.so.5.3.12
> 
> ...and it all seems to work ok.  Specifically, INTs and QUITs work as I
> expect.  Can you let me know what to look for so I can fix it?

Well lets see, for starters it hangs doing a "make trip" which is the
basic symptom I remember for the shared libraries.  My recollection
was that this was usually associated with waiting for a prompt from a
subshell, or something like that.  Hmmm, this actually looks a bit
different, maybe something else is interfering...  I'll get back to
you on this...

Tom

Re: rc,linux,signal,readline

[Tom Culliton]

On Wed, 13 Aug 1997 14:33:53 BST, Tim Goodwin wrote:

> ...and it all seems to work ok.  Specifically, INTs and QUITs work as I
> expect.  Can you let me know what to look for so I can fix it?

OK, testing with 1.5b2 out of the box configured --with-readline,
"make trip" hangs in trip.rc somewhere after line 411.  This is RedHat
4.2, and according to ldd, with the same dynamic libraries as you were
using.  The following sequence shows a problem with catching signals
using readline.

[root@cnslab3 rc-1.5b2]# ./rc
; kill -1 $pid
Hangup

Looks, OK....

[root@cnslab3 rc-1.5b2]#
[root@cnslab3 rc-1.5b2]#
[root@cnslab3 rc-1.5b2]# ./rc
; fn sighup {echo "Got sighup"}
; kill -1 $pid
[root@cnslab3 rc-1.5b2]# ./rc
; fn sighup {echo "Got sighup"}
; kill -1 $pid

Hangs and has to be "kill -9"ed

I went through this at great length a few months back and came up with
a set of patches that do the required clean up after readline.  The
archives should contain the very detailed messages that I sent to the
mailing list describing my discoveries and diagnoses.  In summary,
readline catches certain signals and resets the terminal state,
however there are many more that it doesn't catch, and one (SIGWINCH)
that it handles in a rather odd way.  When you handle one of these
signals within rc instead of exiting, things are left in a bad state.
It's probably to be expected that the place where trip.rc hangs is
while waiting for a subshell to return, i.e. - catching SIGCHLD.  I
will try to adapt the patches to 1.5b2 and forward them to you.