home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / linux / 16965 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.7 KB
  1. Xref: sparky comp.os.linux:16965 comp.lang.tcl:1848 comp.os.coherent:5680 comp.unix.misc:4212
  2. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Newsgroups: comp.os.linux,comp.lang.tcl,comp.os.coherent,comp.unix.misc
  5. Subject: Re: Tcl to replacement most of /bin & /usr/bin (was: Tcl on Linux machines.)
  6. Date: 17 Nov 92 13:45:03
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 23
  10. Message-ID: <TMB.92Nov17134503@arolla.idiap.ch>
  11. References: <1992Nov13.022712.16069@twg.com> <1992Nov13.190824.7843@cpu.com>
  12. Reply-To: tmb@idiap.ch
  13. NNTP-Posting-Host: arolla.idiap.ch
  14. In-reply-to: gwlester@cpu.com's message of Fri, 13 Nov 1992 19:08:24 GMT
  15.  
  16. Someone writes:
  17.  
  18.    >[replacing items in /bin and /usr/bin with interpreted scripts]
  19.    >
  20.    >By properly partitioning functionality into dynamically loadable
  21.    >libraries most of the necessary functionality ought to be doable
  22.    >in C functions.  In which case the scripting language would only
  23.    >be there to glue C functions together into an application usable
  24.    >by a user.  This should, then, make the `overhead' from
  25.    >interpreted scripts insignificant.
  26.  
  27. Maybe it would make it insignificant for copying a TeX file or listing
  28. your home directory. However, there are many users (including myself)
  29. of UNIX that routinely work with files that are more than 100M big,
  30. that need to work on lines that have around 1000 blank-separated
  31. fields, and that use directories with hundreds or thousands of
  32. entries.
  33.  
  34. Currently, tools like "cut", "paste", "join", "sort", and "ls" are not
  35. significantly slower than what I could write myself in C, and I hope
  36. that it will stay this way...
  37.  
  38.                     Thomas.
  39.