From: ghod@drycas.club.cc.cmu.edu
Newsgroups: comp.os.linux
Subject: Re: ANNOUNCE: BSD C Shell for Linux
Date: 8 Jan 93 20:30:12 -0500
Followup-To: comp.os.linux
Organization: Carnegie Mellon Computer Club

In article <1993Jan8.152644.21983@klaava.Helsinki.FI>, rchen@sfu.ca (Robert Chen) writes:
> Hi.  About a week ago I posted whining about there not being many
> working shells around for Linux.  Since then I see that ksh has been
> uploaded to Sunsite and a newer version of tcsh.  To add to the list,
> here is the "standard" C Shell.  I forgot to put into the readme that
> you will probably want to put stty erase ^'?' into your .cshrc if you
> like using backspace.  
> 
> The file is called csh526a.tar.Z and is currently on
> sunsite.unc.edu:/pub/Linux/Incoming.  I imagine it will get moved to 
> /pub/Linux/system/Shells soon.  It includes source and diffs.
> 
> Here is the README:
> 
> - Ken

[fine README file deleted to save bandwidth]

I remember your first post and I'm glad you managed to pull it off. At the
time, I had just downloaded the source to tcsh-6.03 and was getting ready to
compile it, fully expecting to have to make a load of patches. As it turns out,
it had a config file for Linux and it compiled without a hitch. It also
dumped core on execution. :)

After an intense debugging session, I found the problem, sort of. tcsh was
bombing during the initialization sequences in sh.c. Specifically, it crapped
out because of a sigaction() call which it was using to determine the action
status of SIGINT (it later did the same for SIGTERM, but it would always crash
before it ever got there). If you have the source to tcsh 6.03, check around
line 563 in sh.c and you'll see the block of code in question. What you'll
actually see is a call to mysigvec() which is really sigaction() in disguise
via a #define somewhere in the header files. This #definition caused problems
when I tried to run the thing through gdb, since the #define masked the actuall
call that was being executed in such a way that gdb couldn't tell me exactly
what source line was causing the trouble. 

(Also, for those keeping track, chalk up another case of gdb affecting the
operation of a program. When running the program (compiled with -g) in gdb
without any breakpoints, it would still dump core. Once I set a breakpoint
however, I could run the program, wait for it to stop at the breakpoint, then
continue and the SIGSEGV that caused the thing to die would magically
disappear.)

Anyway, I applied a temporary fix. I seems there's an alternate section of the
code which just uses signal() instead of sigaction(). The signal() version
is compiled in if BSDSIGS is *not* defined in config.h (the Linux version of
the config file defines BSDSIGS by default, which seems reasonable I suppose). 
My fix was to hack things a bit so that the signal() version of the code was
compiled instead. This does not mean #undefining BSDSIGS, since this would mess
up other things. But for the sake of this one section of code, it makes pretend
that BSDSIGS isn't there. (The whole procedure involved commenting out a few
lines.) For the moment, I have it installed and it seems to be working just
great. 

I'm going to download the csh source and give it a try (you can never have too
many shells :). However, you mentioned in the README section that your tcsh
didn't work. I'd be interested to know what its problems are, and if they're
related to the ones I had. I intend to do a little more debugging on tcsh to
see if I can find out exactly why this sigaction() call is being botched
(sigaction() is used elsewhere, but this is the only place where it causes
problems). Thankfully, I still have the objects from the last compiling
session -- it takes an hour to build tcsh on my puny 16 Mhz 386, which is about
as long as it takes to build the kernel. :) 

For the record, here's my setup:
16 Mhz 386SX/SL (no math co-processor)
4 megs RAM
42 meg Seagate ST351A/X IDE hard disk (28ms -- slow, but strudy :)
(4 meg swap partition)
2400 baud internal modem (generic/hayes)
Base SLS system (a1-a4 and most of b1-b6)
Linux 0.99.2
X11
groff stuff
tcp/ip stuff
smail
gcc 2.2.2d

As you can see, I have a pretty minimal system hardware-wise, but I still
managed to get a whole bunch of stuff installed. Yes, X works pretty well, even
with just 4 megs of RAM. 

All my libs are from the current SLS distribution. No, I don't have
libc.so.4.2 yet: my stuff has been working just fine all along, so if it ain't
broke, I ain't gonna fix it. I will upgrade once the next SLS release comes out
though. I have considered that my troubles may stem from a busted
library, but that seems unlikely. Maybe it's just me. :)

-Bill

ghod@drycas.club.cc.cmu.edu
Newsgroups: comp.os.linux