4 ms·

The error handling is one reason I prefer Tcl to Bash or POSIX sh if I need a nontrivial script that shells out to other programs. Tcl handles errors, substitut

The error handling is one reason I prefer Tcl to Bash or POSIX sh if I need a nontrivial script that shells out to other programs. Tcl handles errors, substitution, etc. properly (unsurprisingly) by default: > set foo [exec /bin/true][exec /bin/false][exec /bin/true] child process exited abnormally while executing "exec /bin/false" > exec true | false | true child process exited abnormally while executing "exec true | false | true" > set sp "hello world"; exec echo $sp; # No need to quote $sp there. hello world Not all shell-like things are as convenient to do in Tcl as they are in sh (the most significant difference to me is that you cannot pipe to or from functions), and it is more verbose, but because everything is a string in Tcl I find that it integrates with *nix (or Windows!) command line programs better than other scripting languages. E.g., > lmap x [split [exec ps | tail -n +2] \n] {lindex $x 0} 4540 5767 5768 31161 What happens here is that you take the output of `ps | tail -n +2`, split it on newlines, then map over it treating each line (that is something like "5814 pts/0 00:00:00 ps") as a list and taking the first element in it. The result is a list of PIDs (a string containing the PIDs separated by whitespace). I can recommend trying Tcl to anyone fighting Bash who doesn't want to replace it with Python/Ruby/etc. If you try it, though, use version 8.6 or at the very least 8.5. The previous versions are EOL but are still common in the wild. If a recent Tcl is not available on your system, you can build a self-contained static binary interpreter with http://kitcreator.rkeene.org/kitcreator http://kitcreator.rkeene.org/kitcreator.

woah 9y ago
What's the benefit over a more mainstream scripting language?
- networked 9y ago
  The main benefit for shell scripting is the ability to pass data seamlessly between your script and any programs that take and output text. No serialization/parsing is required. What I consider to be the biggest benefit of Tcl in general compared to the more mainstream scripting languages is the pervasive immutability. In Tcl values are strings and strings are immutable. It encourages you to write programs that consists of a reusable, easy-to-test collection of pure functions and a task-specific procedural or (more rarely) OO core.
blacksqr 9y ago
>you cannot pipe to or from functions You, like many others, underestimate Tcl. I present to you, command pipes for Tcl: http://wiki.tcl.tk/17419 http://wiki.tcl.tk/17419 Tcl can be any language you want, because it's already the language you need.
- networked 9y ago
  >You, like many others, underestimate Tcl. Not in this case, at least :-), since on that wiki page there is one implementation of command pipes that I wrote and a link to another (in fptools). What I mean when I say that "you cannot pipe to or from functions" is that while you can pipe data from one external process to another in an [exec] command, you can't pipe it from an external process to a proc or vice versa, which would be analogous to what the POSIX shell can do. Functions and external processes are less similar in Tcl than they are in sh. The best you can do with a simple command pipe implementation like those on the wiki page is pipe data from [exec foo] to [bar $arg] to [exec baz << $arg], which, unlike [exec foo | baz], will read foo's entire output before passing it along. The only real solution that I know to allow you to treat snippets of Tcl code and external processes as basically interchangeable in a gradually read pipeline is rkeene's pipethread library. I am a big fan of it, but using an external dependency that isn't in your operating system's package repositories adds considerable friction to writing and distributing a simple script. (I do hope pipethread ends up in Tcllib.)

woah 9y ago

What's the benefit over a more mainstream scripting language?

networked 9y ago
The main benefit for shell scripting is the ability to pass data seamlessly between your script and any programs that take and output text. No serialization/parsing is required. What I consider to be the biggest benefit of Tcl in general compared to the more mainstream scripting languages is the pervasive immutability. In Tcl values are strings and strings are immutable. It encourages you to write programs that consists of a reusable, easy-to-test collection of pure functions and a task-specific procedural or (more rarely) OO core.

blacksqr 9y ago

>you cannot pipe to or from functions You, like many others, underestimate Tcl. I present to you, command pipes for Tcl: http://wiki.tcl.tk/17419 http://wiki.tcl.tk/17419 Tcl can be any language you want, because it's already the language you need.

networked 9y ago
>You, like many others, underestimate Tcl. Not in this case, at least :-), since on that wiki page there is one implementation of command pipes that I wrote and a link to another (in fptools). What I mean when I say that "you cannot pipe to or from functions" is that while you can pipe data from one external process to another in an [exec] command, you can't pipe it from an external process to a proc or vice versa, which would be analogous to what the POSIX shell can do. Functions and external processes are less similar in Tcl than they are in sh. The best you can do with a simple command pipe implementation like those on the wiki page is pipe data from [exec foo] to [bar $arg] to [exec baz << $arg], which, unlike [exec foo | baz], will read foo's entire output before passing it along. The only real solution that I know to allow you to treat snippets of Tcl code and external processes as basically interchangeable in a gradually read pipeline is rkeene's pipethread library. I am a big fan of it, but using an external dependency that isn't in your operating system's package repositories adds considerable friction to writing and distributing a simple script. (I do hope pipethread ends up in Tcllib.)