Purpose: discuss the pros and cons of using tclsh, wish, or some
derivation as one's primary shell command processor for an
operating system.

Note that tclsh/wish were never designed to '''be''' an interactive login shell.  So the short-comings below are '''not''' intended as a criticism of tcl as a language, per se.  Instead, what is hoped to evolve here are a series of user interface issues one might consider addressing in a sibling interpreter intended to be an interactive login shell with Tcl as the programming language, rather than with the various existing shell languages.


A common complaint from users is that tclsh has no input history, and they typically request that someone add a readline or other interface to the shell.

The typical comp.lang.tcl response is to suggest the user use tkcon .

However, use of tclsh/wish or even tkcon as a login shell is likely to have more issues than command history.

[LV] for instance finds that his daily use of ksh/sh involves a lot of piping output chains of 2, 3, sometimes a dozen commands, with shell constructs as well.  Trying to convert these into an ''easy to use'' notation in tcl has been a daunting task to date.

In the [exec] page, another issue that recently arose was that of tcl's treatment of normal shell globing characters as literals by default.
Thus, in Tcl when a new user says

  set a [exec /bin/ls *.txt]

they typically are surprised to find they didn't get what they expected as a result - tcl didn't expand the argument "*.txt" before invoking /bin/ls, and exec didn't pass the arguments through a shell to do the expansion.


What other issues exist?  For instance, does tclsh and family support suspending commands and placing them into the background?

[Arjen Markus] Well, some experimentation:

In tclsh/wish on UNIX:

   * "ls |more" causes execution of "ls" with a file "|more"
   * "ls | more" causes execution of "ls" and produces one page only
   * "ls -l | more" ditto, but it failed with a pipe error (no readers)
   * "vi aa" did work without a fuss

In tkcon on UNIX (typing into the command window!):

   * "ls" is a Tcl command, so I did not inspect this
   * "vi aa" caused the script to hang

(I did not try Windows, but I suspect that there will be very similar problems, augmented with the fact that some commands are internal to the DOS interpreter and do not exist outside it. I do not know Mac, but this does not allow [exec] at all, at least before OS X)

In general, these are my conjectures:

   * Programs that require no interaction work spendidly, as long as wild cards are taken care of, either via the UNIX shell, or by the programs themselves (under Windows).
   * Programs that simply read a line of input, your basic C or Fortran program reading from stdin, will work when you use the [open] command to set up the communication properly.
   * Programs that require access to the keyboard, like "more", will require more sophisticated tricks, I would suggest using [expect]'s capabilities.
   * Programs like vi will require a terminal of their own and will never work from a command window.

Now, a sturdy and determined programmer can of course find ways to bypass many of these difficulties via [unknown] or the alias mechanism:

   ls *.txt --> exec /usr/bin/sh -c {ls *.txt}

   set myfile "todo_today.txt"
   vi $myfile --> exec xterm -e vi todo_today.txt

and so on.

This will require a lot of work though and is it worth it? You could distinguish categories of commands (and programs), so not every command would need its own Tcl interfacing.

Perhaps a general proc, called | for syntactical sugar, can take care of the pipe mechanism ([exec] and [open] are the basic commands that will play a role in it). Another one is [incrfilter], as [LV] suggested on the Tcl chat.

[LV] Actually, incrfilter is just a prototype for a replacement of more.  It provides the ability to display subsets of data based on constant strings.  I didn't mean for incrfilter to cross over into this discussion - just was mentioning to arjen a toy to play with instead of using more. 

I think the above shows me that there is a LOT of work that is needed before someone could comfortably replace use of ksh/sh/bash/etc. with a tcl based shell.

Note however that [dtksh] has the ability to invoke Tcl functions.  A hybrid solution is easiest.

----
[Arjen Markus] Some of the limitations of [exec] with respect to handling pipelines may have been solved by [RS] - see his page on [Streams] - [RS] disclaims: That page offers nice sugar which looks like OS pipes, but in fact are only nesting relations between procedures (''cat'', ''grep'' and ''more'' were just few-liner Tcl substitutes..)

-----
[[into what categories should this page go?]]