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:
In tkcon on UNIX (typing into the command window!):
(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:
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.txtand 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..)