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?