home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23305 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  4.8 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!news.sei.cmu.edu!drycas.club.cc.cmu.edu!ghod
  2. From: ghod@drycas.club.cc.cmu.edu
  3. Newsgroups: comp.os.linux
  4. Subject: Re: ANNOUNCE: BSD C Shell for Linux
  5. Message-ID: <1993Jan8.203013.2857@drycas.club.cc.cmu.edu>
  6. Date: 8 Jan 93 20:30:12 -0500
  7. References: <1993Jan8.152644.21983@klaava.Helsinki.FI>
  8. Followup-To: comp.os.linux
  9. Organization: Carnegie Mellon Computer Club
  10. Lines: 91
  11.  
  12. In article <1993Jan8.152644.21983@klaava.Helsinki.FI>, rchen@sfu.ca (Robert Chen) writes:
  13. > Hi.  About a week ago I posted whining about there not being many
  14. > working shells around for Linux.  Since then I see that ksh has been
  15. > uploaded to Sunsite and a newer version of tcsh.  To add to the list,
  16. > here is the "standard" C Shell.  I forgot to put into the readme that
  17. > you will probably want to put stty erase ^'?' into your .cshrc if you
  18. > like using backspace.  
  19. > 
  20. > The file is called csh526a.tar.Z and is currently on
  21. > sunsite.unc.edu:/pub/Linux/Incoming.  I imagine it will get moved to 
  22. > /pub/Linux/system/Shells soon.  It includes source and diffs.
  23. > 
  24. > Here is the README:
  25. > 
  26. > - Ken
  27.  
  28. [fine README file deleted to save bandwidth]
  29.  
  30. I remember your first post and I'm glad you managed to pull it off. At the
  31. time, I had just downloaded the source to tcsh-6.03 and was getting ready to
  32. compile it, fully expecting to have to make a load of patches. As it turns out,
  33. it had a config file for Linux and it compiled without a hitch. It also
  34. dumped core on execution. :)
  35.  
  36. After an intense debugging session, I found the problem, sort of. tcsh was
  37. bombing during the initialization sequences in sh.c. Specifically, it crapped
  38. out because of a sigaction() call which it was using to determine the action
  39. status of SIGINT (it later did the same for SIGTERM, but it would always crash
  40. before it ever got there). If you have the source to tcsh 6.03, check around
  41. line 563 in sh.c and you'll see the block of code in question. What you'll
  42. actually see is a call to mysigvec() which is really sigaction() in disguise
  43. via a #define somewhere in the header files. This #definition caused problems
  44. when I tried to run the thing through gdb, since the #define masked the actuall
  45. call that was being executed in such a way that gdb couldn't tell me exactly
  46. what source line was causing the trouble. 
  47.  
  48. (Also, for those keeping track, chalk up another case of gdb affecting the
  49. operation of a program. When running the program (compiled with -g) in gdb
  50. without any breakpoints, it would still dump core. Once I set a breakpoint
  51. however, I could run the program, wait for it to stop at the breakpoint, then
  52. continue and the SIGSEGV that caused the thing to die would magically
  53. disappear.)
  54.  
  55. Anyway, I applied a temporary fix. I seems there's an alternate section of the
  56. code which just uses signal() instead of sigaction(). The signal() version
  57. is compiled in if BSDSIGS is *not* defined in config.h (the Linux version of
  58. the config file defines BSDSIGS by default, which seems reasonable I suppose). 
  59. My fix was to hack things a bit so that the signal() version of the code was
  60. compiled instead. This does not mean #undefining BSDSIGS, since this would mess
  61. up other things. But for the sake of this one section of code, it makes pretend
  62. that BSDSIGS isn't there. (The whole procedure involved commenting out a few
  63. lines.) For the moment, I have it installed and it seems to be working just
  64. great. 
  65.  
  66. I'm going to download the csh source and give it a try (you can never have too
  67. many shells :). However, you mentioned in the README section that your tcsh
  68. didn't work. I'd be interested to know what its problems are, and if they're
  69. related to the ones I had. I intend to do a little more debugging on tcsh to
  70. see if I can find out exactly why this sigaction() call is being botched
  71. (sigaction() is used elsewhere, but this is the only place where it causes
  72. problems). Thankfully, I still have the objects from the last compiling
  73. session -- it takes an hour to build tcsh on my puny 16 Mhz 386, which is about
  74. as long as it takes to build the kernel. :) 
  75.  
  76. For the record, here's my setup:
  77. 16 Mhz 386SX/SL (no math co-processor)
  78. 4 megs RAM
  79. 42 meg Seagate ST351A/X IDE hard disk (28ms -- slow, but strudy :)
  80. (4 meg swap partition)
  81. 2400 baud internal modem (generic/hayes)
  82. Base SLS system (a1-a4 and most of b1-b6)
  83. Linux 0.99.2
  84. X11
  85. groff stuff
  86. tcp/ip stuff
  87. smail
  88. gcc 2.2.2d
  89.  
  90. As you can see, I have a pretty minimal system hardware-wise, but I still
  91. managed to get a whole bunch of stuff installed. Yes, X works pretty well, even
  92. with just 4 megs of RAM. 
  93.  
  94. All my libs are from the current SLS distribution. No, I don't have
  95. libc.so.4.2 yet: my stuff has been working just fine all along, so if it ain't
  96. broke, I ain't gonna fix it. I will upgrade once the next SLS release comes out
  97. though. I have considered that my troubles may stem from a busted
  98. library, but that seems unlikely. Maybe it's just me. :)
  99.  
  100. -Bill
  101.  
  102. ghod@drycas.club.cc.cmu.edu
  103.