Version 27 of shell

The word shell has various meanings. On Unix systems, a shell is an interactive interpreter for some language, providing a command-line as a user user interface to the the system. Such shells usually can also operate in batch mode, reading a file an interpreting the contents as a script to be executed.

Another more general definition is "The application that enables the user to navigate the file system and start applications." This definition also includes graphical shells like the CDE and KDE environments, the Windows Explorer or the MacOS Finder.

While technically, tclsh and wish applications are shells, in the first use of the word, Bourne, ksh, csh/tcsh, bash, zsh etc. are more commonly thought of as shells than are tclsh or wish. See Unix shells for more discussion of this use of the word.

http://en.wikipedia.org/wiki/Comparison_of_computer_shells discusses a comparison of various command line shells. Perhaps there is some tcl comperable add-on which would compare seriously to the others listed?

itcl has a base widget called a shell:

Docs can be found at http://incrtcl.sourceforge.net/iwidgets/iwidgets/shell.html and http://purl.org/tcl/home/man/iwidgets3.0/shell.n.html

Here's a proc to transform the contents of environment variables containing words in shell syntax into Tcl lists:

proc shtotcl {value {sh bash}} {
    set script "printf 'puts \[lrange \$argv 1 end]' | \$1 - $value"
    return [exec $sh -c $script - [info nameofexecutable]]
}

Example:

shtotcl $env(LDFLAGS)

A more updated version of this code might be found at ycl::format::sh::shtotcl.

Advantages of Tcl for Shell Scripting

Shells in the csh family are known to be unsuitable for any serious scripting, but shells in the sh family are often used extensively for the purpose. Tcl is a better choice. Here are some reasons:

scalability: Often, a smallish task will be scripted in an sh language, but will then increase in size at it matures. sh scripts don't scale well. It's safer to just get in the habit of using Tcl from the get-go.

nested data structures: The arcane syntax of traditional shells simply doesn't allow for nested data structures. Tcl syntax scored a great coup on this account by retaining the shell characteristic that everything is a string while providing a sufficiently regular syntax to support nested data structures.

variable references: Shells like bash and ksh have tried a couple of times to provide some way of passing data to a function by reference. There is the older ${!nameref} syntax and also the new typeset -n nameref syntax, but there is one serious flaw in both those approaches which makes their use brittle. A variable named nameref itself must be reserved in the global scope, since any attempt to use variable expansion to create the nameref variable might conflict with the name of the referenced variable:

rmval () {
    typeset -g -n nameref=$1
    local i=0
    local val
    for val in "${nameref[@]}" {
        if test $val = "$2"; then
            unset nameref\[$i]
        fi
        ((i++))
    }
    #compact the array
    nameref=( "${nameref[@]}" )
}

: The global name nameref is reserved by this function, requiring a consensus among all bash scripts that might use this function to respect that variable. Contrast with the upvar capability of Tcl:

proc rmval {listname val} {
    upvar $listname list
    set idx 0
    foreach item $list {
        if {$item eq $val} {
            lreplace list $idx $idx
        }
        incr idx
    }
    return $list
}

Version 27 of shell

Advantages of Tcl for Shell Scripting

See Also