There are many ways to get data into a Tcl interpreter for evaluation.One of the most common ways is to edit a file, then to invoke a Tcl-based interpreter with the name of the file. Tcl reads the file, interpreting the results and producing output when required.Developers used to a GUI development environment frequently ask if there are GUI-based integrated development environments (IDEs) for Tcl. There are a number of such products, with varying states of usefulness. I typically refer people to http://www.purl.org/net/tcl-faq/part4.html
to find the ones I have cataloged, but there are any number of Tcl Resource Catalogs available.Another way that some people enter Tcl commands, while experimenting, is by invoking a Tcl interpreter without any input file. This starts up a relatively simple interface where one can type in a command at a time and the interpreter will display the results.There are some minimal niceties available when doing this.... talk about command line history, abbreviated commands, unknown submitting unknown commands to the shell...... talk about tkconsole ....DKF - Many developers (myself included) use Emacs under X which puts a nice line-editing facility around Tcl for us. This is sufficiently good that we feel no need for more sophisticated command-line editing. I've also tried several GUI editing tools, and none of them improved my productivity to the point where it overcame the annoyance of not being able to just delve in there directly and just hack the code to do what I want. I type really quite quickly... :^)Tcler - But what about those who don't know, and don't want to know Emacs. Tcl is not alone on this minimal editing, a lot of languages have even less (like Perl), but the ones with even semi-featured editing (like Python which doesn't autocomplete but still) are much easier to experiment with, and tend to feel more friendlier somehow.RMSB: Actually, current Python shells are the best i've worked with. They come complete with GNU readline library and, best yet, support for tab semantic completion, that is, type obj. and have all the object attributes and methods listed...LV: I seem to recall that tclsh was originally intended as a sample of how to make use of Tcl in a C program. So, why not add things now? For quite some time, the primary libraries to add these types of features were GNU licensed, which didn't fit the Tcl license.So, why not add these functions now? I don't recall whether anyone has submitted a TIP proposing to do this. But if it were added, it would be a configure time argument, since not everyone would have a library.DGP - The caution here is that tclsh has two uses. It can be used as an interactive shell, but it can also be used as the engine that supports script applications. Any proposed improvements to interactivity support need to be weighed against possible damage to tclsh's other (more important, IMHO) function serving as a base for script applications.The safest route, it seems to me, is to not try to improve the base interactive features of tclsh itself, but to create and distribute with Tcl a script application with good interactive features.On this topic, tkcon is worth mentioning.Pierre Coueffin: As is tclreadline which I've been using heavily for about 2 years. The ability to search the history for commands that you entered several days ago, in a totally different session is very handy.LV: I used to use tclreadline, but quit after having various problems with the readline library. There is also the fact that the library is a GNU licensed package, and to date, Tcl has avoided shipping with GNU programs and libraries to avoid various concerns. There have been a variety of discussions over the years about this. I like DGP's suggestion - particularly if the tk console command would interact with tkcon ... However, it doesn't help people without Tk availability.RS: Also note, that tclsh on often-scolded Windows has implicit line editing, history, even over sessions, inherited from the "DOS" console.AM: Only with newer versions of Windows - not with Windows 98. At least not my version at home ;).Harm Olthof: Have you tried to enter "doskey" in the command prompt before starting tclsh? (or put it in autoexec.bat)Lars H: An alternative to the GNU library has been discussed on the tcl-core mailing list, see [1]. With some encouragement, David Welton may go ahead and TIP it.DKF: Just noting that I wouldn't (willingly) do software development on old windows systems, even with the tremendous benefit of having the Tcl interpreter (doing without... horrible thought!)Also, the suggestions re readline have come around regularly for years. The problem has consistently been the licensing model. We've gone as far as asking the readline authors about this and been told that the solution was for us to switch our license to GPL. At that point, we gave up (we're not changing our license for anyone.) The editline alternative is likely to be be supported at such time as someone actually puts together a concrete proposal; too many of us (i.e. the Tcl Maintainers and TCT Members) just don't have the personal bandwidth left to work on it ourselves. (A shame, but we're just human and we have bills to pay.)KD: There is an existing implementation based on editline, see eltclsh. I have been using eltclsh and elwish for a while, and I like them very much. I don't know if they are related to the work of David Welton.
