What is the need for shell when executing tclsh

how to run tcl script in linux
how to run tcl script in tcsh
tcl script example
tcl shell online
tcl basics
tcl exec multiple commands
tcl tutorial pdf
tcl file
# A Tcl comment, whose contents don't matter \
exec tclsh "$0" "$@"

why should we invoke shell here (#!/bin/sh) .

We can directly invoke the tclsh (#!/usr/sbin/tclsh) . Let us Assume tclsh is in sbin directoey.

Why we are First calling the shell and again inside the shell we are calling tclsh interpreter .

why people prefer to use these (#!/bin/sh , exec tclsh "$0" "$@") . Can't we execute tclsh direclty ?

For one reason, on some systems, you can rigidly lock down what executables can be run in a shebang line. In other words, it may refuse to run anything not in /bin. Or maybe, if your administrators are particularly sadistic, they may try to force everyone to use zsh :-)

Secondly, this will run tclsh based on your current path settings. That's invaluable if you want different users to run it with different versions of TCL. Otherwise, you have to give an absolute path on the shebang line and this may be different on different systems (although /usr/bin/env can also take care of that).

It's also handy to test the scripts with more recent versions of tclsh before committing to them. For example, you can have tclsh 8.5 under the current latest Debian (7.1) while testing TCL 8.6 by building it in $HOME/staging/tcl86 and changing your path so that directory appears before usr/bin.

On my system (which is locked down to my specs but no further), the script:

#!/usr/bin/env tclsh
puts $tcl_version

works just fine, outputting:


So does the script:

puts $tcl_version

although, as mentioned, it's tied to the system version of tclsh rather than the first one on my path.

And, yes, you can get at the arguments just fine, as per the following transcript:

pax> cat qq.tcsh
puts $argc
puts $argv

pax> qq.tcsh my name is pax
my name is pax

What is the need for shell when executing tclsh, When you have a script like this, and you run it from the command line, the system thinks it is a shell script and will start to run each line as if it were a shell command. When tclsh starts, tcl variables like argv, argv will come into picture. The shell evaluates the script and sees the exec tclsh "$0" which causes it to execute the installed tclsh binary and pass it $0 (the script file name) as the first argument, which re-runs the script using the tcl interpreter. The second line in my example comments out the third line when the script is evaluated by the tcl interpreter.

When you have a script like this, and you run it from the command line, the system thinks it is a shell script and will start to run each line as if it were a shell command.

$0 and $@ are shell variables.. $0 for tcl script path and ${1+$@} means "all the arguments, if the first argument is set" hence,

 exec tclsh $0 ${1+$@} 

means after stopping shell, execute tclsh by passing script file (via $0) and rest arguments (via ${1+$@})

When tclsh starts, tcl variables like argv, argv will come into picture.

Running Tcl, When you have installed Tcl, the program you will then call to utilize it is tclsh . to a file "hello.tcl", and you want to execute it, you would do it like so: tclsh hello.​tcl . which may be installed on your system, is the wish , or WIndowing SHell. But it isn't appropriate for long-running programs, or programs with which you want your script to interact (send messages and read responses interactively). In these cases, you need Tcl's more sophisticated interprocess communication tools: interprocess pipes and sockets. If you're interested in these, we can continue this in another message.

The reason for the two line start is to work around a 32 character line limit on the special shebang line.

# A Tcl comment, whose contents don't matter \
exec /some/very/long/path/to/find/a/tcl/executable/path/tclsh "$0" "$@" 

Running other programs from Tcl - exec, open, So far the lessons have dealt with programming within the Tcl interpreter. from the prompt in an interactive shell or a DOS-box or in a UNIX/Linux shell script. The tclsh executable is just one way of starting a Tcl interpreter. Another common executable, which may be installed on your system, is the wish, or WIndowing SHell. This is a version of Tcl that automatically loads the Tk extension for building graphical user interfaces (GUIs).

The main historical reason is, as @Shawn mentioned, that some old Unices couldn't handle a long shebang.

The second reason is portability in terms of system layout. Your example #!/usr/sbin/tclsh is an excellent example, because it won't work on my machine. There is no tclsh in /usr/sbin, mine is in ~/.nix-profile/bin/tclsh. It also won't be appropriate for a user that has a tclsh in /usr/sbin but would prefer another version of tclsh that they put earlier in their PATH.

One might think we could just use #!tclsh, which would solve both problems, but there are many systems still today that require an absolute path. But there's an unofficial official portable solution:

#!/usr/bin/env tclsh

This works on your average GNU/Linux distro, on cygwin/msys2 in Windows, and on all kinds of Unices since over two decades back. And it is the shebang that e.g. tklib uses: https://github.com/tcltk/tklib/commit/4ea165c5d8b126185e4bbb341e53289a0efc931d

This trick is so widespread and expected to work, not just for tcl but for other things too, that even NixOS, which otherwise has an empty /usr/bin, has a /usr/bin/env.

For more on /usr/bin/env and interpreters in general, see https://askubuntu.com/questions/88314/what-type-of-path-in-shebang-is-more-preferable .

For more on shebangs and Tcl, see https://wiki.tcl-lang.org/page/exec+magic .

tclsh, even returning to the shell prompt was insufficient to reset the terminal settings. Running 'rlfe tclsh' for example will allow the arrow keys to work and also seem The first paragraph is highly unclear, so clarifications are needed, but not so  If you need to exit from the shell, for whatever reason (or you cannot run Tcl 8.6+), then Donal's suggestion is the way to go. Update. If applicable in your case, you may improve the implementation by using an anonymous (lambda) proc. This simplifies the lifecycle management (avoiding re-definition, managing coroutine and proc, no need for a

Shell script, A shell script is a computer program designed to be run by the Unix shell, a command-line The C and Tcl shells have syntax quite similar to that of said programming languages, and the Korn shells and Bash are developments of the Bourne  The exec call is similar to invoking a program (or a set of programs piped together) from the prompt in an interactive shell or a DOS-box or in a UNIX/Linux shell script. It supports several styles of output redirection, or it can return the output of the other program(s) as the return value of the exec call.

Running tcl Files in C shell, Can any body tell me, how to execute tcl files in a C shell. i am working in expect or tcl since shell script cannot be embedded into expect script ? i have 100+  I want to execute TCL command on the Access Server that would run TCL script on the router. I think the way to achieve this is a TCL script with a send command from the Access Server. The problem is to put that "send" command in the TCL script , because we need to press Ctrl+z at the end (when we want to execute that send command).

tclsh: Simple shell containing Tcl interpreter, Tclsh is a shell-like application that reads Tcl commands from its standard input or An application that requires this character in the file may safely encode it as cause both sh and tclsh to process the script, but the exec is only executed by  RE: executing shell script in tcl and passing parameters mikrom (Programmer) 4 Nov 11 07:59 Other option, especially if you need to process the output from called shell script in your tcl-caller script, would be to use something like this:

  • So we can use directly tclsh right ? then argv0 , argv , argc variables can be accessible directly to the script ?
  • @user2746819, it depends on how your system is set up. See the update although, if your system has higher levels of "security", it may not work.
  • @paxdiablo There is a typo in your comment: It must mean "stupidy".
  • I remember there being some systems that would always run executable scripts in csh. That's just so wrong on so many levels…