NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/os/linux/16532

Internet Message Format | 1992-11-11 | 3.7 KB

Xref: sparky comp.os.linux:16532 comp.lang.tcl:1818 comp.os.coherent:5588 comp.unix.misc:4130
Newsgroups: comp.os.linux,comp.lang.tcl,comp.os.coherent,comp.unix.misc
Path: sparky!uunet!eco.twg.com!twg.com!news
From: "David Herron" <[e-mail]>
Subject: Tcl to replacement most of /bin & /usr/bin (was: Tcl on Linux machines.)
Message-ID: <[e-mail]>
Sensitivity: Personal
Encoding:  64 TEXT , 4 TEXT
Sender: [e-mail] (USENET News System)
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Fri, 13 Nov 1992 02:30:42 GMT
Lines: 69

The following question triggered one of my "this is a kool idea" buttons ..

> Just curious, has someone tried to compile/port Tcl to Linux already ?
> If so how much work involved ? Inquiring mind wants to know.

Suppose one had the freedom to re-implement the Unix environment.
What would you do?

I dunno about the rest of you jokers, but what I'd like to see is:

- ***SMALLER*** disk space requirements.  (and smaller memory requirement)

- More easily customizable environment, with customizations (sometimes)
  just behind the front end of the tools.

- Have the inner functionality of the tools made available in some sort of
  script/program environment for building new tools.  Particularly for
  writing little X based interfaces ...

For those OS historians among us.. something like the stated goal of
RSTS & Basic-Plus is what I have in mind.  In that system most (all?)
of the user commands were written in this dialect of Basic.  The goal
being to have a customizable environment, and may have included some
of the other goals above.

By properly partitioning functionality into dynamically loadable libraries
most of the necessary functionality ought to be doable in C functions.
In which case the scripting language would only be there to glue C functions
together into an application usable by a user.  This should, then, make
the `overhead' from interpreted scripts insignificant.  And, besides,
1) systems are a *lot* faster now than in the RSTS days, and 2) TCL is
a much smaller and more easily interpreted language than Basic-Plus.

The environment would then have

- in /lib, dynamically loaded libtcl.a, libtk.a and bunches of other
  libraries.  For instance, libcat.a, libmore.a, etc ..

- in /bin, a tcl program which has commands for dynamically linking and
  pulling in any TCL commands from the library.  There will, of course,
  be some programs which you don't want to `trust' as a TCL+libraries
  program, these will be as they are now.  Just like some programs
  are hardcoded to read host info from /etc/hosts because at boot time
  they need to get host info without the nameserver (or NIS) being available.

However I don't have the time to do this myself, nor do I work for a Unix
vendor.  So it's not likely I can directly cause this to happen.  (Heck,
I don't even have time to construct an example of how this might look!)

Maybe this will inspire someone who can do something about it to do so.


Why TCL?  Why not Perl?  Two reasons:

- TCL is much smaller and was designed from the beginning to be embedded
  into programs.

  Perl is more like what I said about Basic-Plus above.  It's large
  and while it can be embedded, it looks hard to do so.

- TCL is not subject to the GNU Public Liscense (GPV) while Perl is.
  IMHO the GPV is not terribly conducive to writing & *selling*
  commercial applications.  RMS sure paints a rosy picture of what Might Be
  but I don't buy into its entirety.

<- David Herron <[e-mail]> (work) <[e-mail]> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".