home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / linux / 16987 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.0 KB
  1. Xref: sparky comp.os.linux:16987 comp.lang.tcl:1856 comp.os.coherent:5688 comp.unix.misc:4223
  2. Newsgroups: comp.os.linux,comp.lang.tcl,comp.os.coherent,comp.unix.misc
  3. Path: sparky!uunet!ukma!darwin.sura.net!convex!convex!jjensen
  4. From: jjensen@convex.com (James Jensen)
  5. Subject: Re: Tcl to replacement most of /bin & /usr/bin (was: Tcl on Linux machines.)
  6. Sender: usenet@news.eng.convex.com (news access account)
  7. Message-ID: <1992Nov17.192736.4260@news.eng.convex.com>
  8. Date: Tue, 17 Nov 1992 19:27:36 GMT
  9. References: <1992Nov13.022712.16069@twg.com>
  10. Nntp-Posting-Host: dhostwo.convex.com
  11. Organization: USENET news support, CONVEX Computer Corp, Richardson, Tx. USA
  12. Followup-To: comp.os.linux
  13. X-Disclaimer: This message was written by a user at CONVEX Computer
  14.               Corp. The opinions expressed are those of the user and
  15.               not necessarily those of CONVEX.
  16. Lines: 31
  17.  
  18. "David Herron" <david@twg.com> writes:
  19. -
  20. - I dunno about the rest of you jokers, but what I'd like to see is:
  21. -
  22. - - ***SMALLER*** disk space requirements.  (and smaller memory
  23. requirement)
  24. -
  25. - - More easily customizable environment, with customizations
  26. (sometimes)
  27. -   just behind the front end of the tools.
  28. -
  29. - - Have the inner functionality of the tools made available in some
  30. sort of
  31. -   script/program environment for building new tools.  Particularly for
  32. -   writing little X based interfaces ...
  33. -
  34.  
  35. A more elegent and easier solution would be
  36. to modify gcc to produce code for an interpreter.
  37. The interpreter would be part of a shared library.  
  38. This would save the disk space.  If gcc produced the 
  39. same internal code as Tcl or perl then your second two 
  40. goals would be met, I think.
  41.  
  42. I suspect that someone familiar with the internals of both gcc and
  43. perl/Tcl could do something like that fairly quickly.  Anyone
  44. could do it more quickly than reimplementing all of the tools in
  45. another language.  Heck, writing a compiler/interpreter from scratch 
  46. would be faster than reimplementing all those tools.
  47.  
  48. Jim Jensen - jjensen@convex.com
  49.