When you build Tcl/Tk by default it creates the files
tclsh85
wish85
However many programs call tclsh and wish. This is one fix for that
cp tclsh85 tclsh
cp wish85 wish
However, can you simply build tclsh and wish directly, perhaps using a configure argument?
This behavior is The Right Thing as it allows several versions of the interpreter and its libraries to coexist in the system. The system, in turn, does provide a way to "bless" one of the version as "default" — for instance, Debian provides "alternatives". In essence, usually a symlink with the "canonical" name is created pointing to the real executable, like /usr/bin/tclsh → /usr/bin/tclsh85. And with the "blessed" version available via such a symlink for the applications that do not care about the precise version of the runtime, certain other applications still can pick some specific runtime version by referring to the interpreter's real executable name.
This also provides an easy way to test an existing program against an experimental runtime version: you just run /usr/bin/tclsh86 /path/to/the/script.tcl instead of just running /path/to/the/script.tcl as usually which relies on the shebang to pick the interpreter.
A long time ago, the builds of Tcl and Tk used to work in the way you describe. It was changed to the current system (putting the version number in the name) to allow multiple versions to coexist more smoothly; this was a very strong demand from the user community at the time.
Symlink the version-less filenames to the real ones (or use the mechanism of your distribution) if you want to give up control over which version to use. Alternatively, use this (fairly horrible) piece of mixed shell/Tcl code at the top of your files:
#!/bin/sh
# Try with a versionless name \
exec tclsh "$0" ${1+"$#"}
# Otherwise, try with tclsh8.6 \
exec tclsh8.6 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.5 \
exec tclsh8.5 "$0" ${1+"$#"}
# Otherwise, try with tclsh8.4 \
exec tclsh8.4 "$0" ${1+"$#"}
# Otherwise... well... give up! \
echo "no suitable Tcl interpreter" >&1; exit 1
This relies on the fact that Tcl, unlike the Unix shell, treats a \ at the end of a comment line as meaning that the comment extends onto the next line.
(Myself? I don't usually put in #! lines these days; I don't consider it an imposition to write tclsh8.5 myscript.tcl.)
Related
Within tclsh I can run the following and get the expected output:
% exec bash -c "ulimit -v"
50331648
However within a Tcl script nothing is returned. No error, no output, nothing. There's clearly some gotcha with exec'ing 'bash -c' that I can't work out.
Alternatively, is there a native way in Tcl that I can get the system's memory limit to avoid having to do it this way in the first place?
In an interactive tclsh session, the REPL helpfully prints the output of commands/expressions. That's not the case in a non-interactive program.
exec returns the output of the command: you just need to capture it with the usual command substitution:
set output [exec bash -c "ulimit -v"]
puts $output
The code that you wrote should work; I can't identify why bash would silently fail to run ulimit -v. Even if the script was running in an environment where that was privileged information (why!?) one would still expect to get an error message of some form. That's a very weird problem!
Tcl's base command set doesn't expose any access to memory limits, whether for reading or writing. The simplest workaround that doesn't call an external program is the tclbsd package (apparently it mostly works on most other Unixes as well), which exposes a command that should help:
package require BSD
set limit [bsd::rlimit get soft virtual]
I don't program in TCL but I do use them such as tkcvs and tkdiff. I notice that they declare themselves as shell script
#!/bin/sh
#-*-tcl-*-
What's more, running them through tclsh doesn't work either and I get error like this:
Initialization failed
The second line in the header baffles me too because AFAIK, shell only looks at the #! line. How's this working?
Tcl scripts are normally setup to run using slightly more than you have shown. It is typically and most robustly done like the following:
#!/bin/sh
# \
exec tclsh "$0" ${1+"$#"}
They use the shell initially because there was no standard installation location for tcl so the location could not be relied on. Instead, by starting the system shell and using that to start the tclsh executable you could be certain to run the installed tclsh as long as it was present on the PATH. 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. The backslash causes the second and third lines to be treated as a single comment when read by tclsh so that tcl doesn't try and run the exec again.
In your snipped the # -*-tcl-*- is marker to indicate the mode to be used by emacs when editing the file. See the documentation.
There is not really enough to go on for the error message. It doesn't seem to be from the Tcl interpreter itself. (That is 'git grep' in the tcl sources does not match that string).
I created a binary executable from bash script on linux server through SHC. The binary created works fine on linux machines, but through mistake on Mac. How could I convert my bash file to binary executable that is able to run everywhere(ubuntu, CentOS, Mac, Cygwin)?
shc -v -r -T -f ir16fetcher.sh
mv ir16fetcher.sh.x ir16fetcher
Shebang of my bash script
#!/bin/bash
On Linux machines
./ir16installer
USAGE : ir16fetcher <servername/ip address> [the n th latest build - optional. Default 1]
EXAMPLE: ir16fetcher jagger 2
EXAMPLE: ir16fetcher 167.116.6.155
REQUIRE: Please make sure conf file in installation folder ~/IRinstall/ir16 & ~/IRinstall/irmanager
On my Mac
./ir16installer
-bash: ./ir16installer: cannot execute binary file
I think it's not gonna work
"The compiled binary will still be dependent on the shell
specified in the first line of the shell code (i.e.
#!/bin/sh), thus shc does not create completely independent
binaries."
From http://www.datsi.fi.upm.es/~frosal/sources/shc.html
You will have to do this for every architecture and operating system you need to support. In any case, there doesn't really seem to be any benefits of using this method for distribution. It adds dependencies and complicates delivery, and I'm pretty sure whatever obfuscation the "shc" compiler implements is easily reversed.
if the goal here is to "hide" your source code, and then have the "hidden" copy of the code be executable on the Unix OSes you listed, then, encryption is really your only option.
I say this because encryption tools are available on every base Unix install. For your purposes, this is a very good thing as you wont have to download or configure anything additional. They're just there, as part of the natural installation of the OS. One of such tools is called openssl.
To Encrypt your file/script with openssl:
echo precious-content | openssl aes-128-cbc -a -salt -k mypassword
U2FsdGVkX1+K6tvItr9eEI4yC4nZPK8b6o4fc0DR/Vzh7HqpE96se8Fu/BhM314z
To Decrypt your file/script with openssl:
echo U2FsdGVkX1+K6tvItr9eEI4yC4nZPK8b6o4fc0DR/Vzh7HqpE96se8Fu/BhM314z | openssl aes-128-cbc -a -d -salt -k mypassword
precious-content
Now, to get openssl to do what you want it to do automatically without having to spend hours of your own time figuring out a way, you can paste your script to a site like www.EnScryption.com. This site will generate an "executable" version of your code for you, which you can then run on any Mac, Ubuntu, RedHat, CentOS box.
I am trying to run a very simple tcl script
package require Expect
spawn sftp user#host
the error I get is
The system cannot find the file specified.
while executing
"spawn sftp user#host"
The only reason I see it's that sftp path should be specified somehow. I call this from a batch script and I've also tried changing the directory to sftp location before calling the script but the error is still the same.
By far the most likely cause of the issue here is that the sftp program is not in a directory that is on your PATH. The concept is almost the same across platforms, but with some minor niggles.
Working with the Unix PATH
Check to see if sftp is available in a PATH-known directory by typing:
which sftp
At your shell prompt. It should respond with the location of the sftp program, but if it isn't found then you get no response at all. If it isn't found, you'll need to find it yourself and add its location (strictly, the directory that contains the program) to the PATH. Find the program with something like:
locate sftp
Or (very slow!):
find / -name sftp -print
To append a directory to the PATH, do this in your shell:
PATH=$PATH:/the/dir/to/append
You can add a directory within the Expect script too (as long as it is before the spawn, of course!):
append env(PATH) : /the/dir/to/append
Working with the Windows PATH
On Windows, use Windows Search (Windows+F IIRC) and look for a file called sftp.exe (there's also a command line search tool, but I forget how to use it).
With the Windows PATH, a little more care is required:
append env(PATH) ";" {C:\the\dir\to\append}
# Or this...
append env(PATH) ";" [file nativename C:/the/dir/to/append]
Which is to say, the Windows PATH uses a different separator character (because : is used for separating drive names from directory parts) and the native name of the directory must be used, rather than the somewhat-more-convenient forward-slash variation (the backslashes interact with Tcl's syntax, hence the {braces}). Forward-slashes can be used provided you use file nativename to convert before appending, as in my second version.
Some Tcl Techniques that can Help
You can use the Tcl command auto_execok to find out whether a program is on your PATH or not. For example:
puts [auto_execok sftp]
However, for some commands (notably start on Windows) you get a more complex response; the command really exists as part of the code that supports interactive Tcl usage, describing how to run some external program which can sometimes be a lot more complex than it appears to be at first glance. Still, it approximates to a cross-platform version of which as listed in the beginning of this answer...
Tcl 8.6 provides $tcl_platform(pathSeparator) variable as a way to get the PATH element separator character (a : or ;, depending on platform). Probably doesn't help you though, as 8.6 hasn't yet been distributed as widely as previous versions.
I noticed that I can't combine --traditional options with the other one letter other options such as -i for example.
For example, when I have this as the first line in my octave .m file
#!/usr/bin/octave --traditional
Then it work. Octave starts ok and runs the script.
But when I try
#!/usr/bin/octave --traditional --silent --norc --interactive
It does not work. Error from octave. does not understand the options.
When I try
#!/usr/bin/octave --traditional -qfi
Also error. But this
#!/usr/bin/octave -qfi
works.
The problem is that --traditional does not have a one letter short cut like all the other options. This is the options I see
Options:
--debug, -d Enter parser debugging mode.
--doc-cache-file FILE Use doc cache file FILE.
--echo-commands, -x Echo commands as they are executed.
--eval CODE Evaluate CODE. Exit when done unless --persist.
--exec-path PATH Set path for executing subprograms.
--help, -h, -? Print short help message and exit.
--image-path PATH Add PATH to head of image search path.
--info-file FILE Use top-level info file FILE.
--info-program PROGRAM Use PROGRAM for reading info files.
--interactive, -i Force interactive behavior.
--line-editing Force readline use for command-line editing.
--no-history, -H Don't save commands to the history list
--no-init-file Don't read the ~/.octaverc or .octaverc files.
--no-init-path Don't initialize function search path.
--no-line-editing Don't use readline for command-line editing.
--no-site-file Don't read the site-wide octaverc file.
--no-window-system Disable window system, including graphics.
--norc, -f Don't read any initialization files.
--path PATH, -p PATH Add PATH to head of function search path.
--persist Go interactive after --eval or reading from FILE.
--silent, -q Don't print message at startup.
--traditional Set variables for closer MATLAB compatibility.
--verbose, -V Enable verbose output in some cases.
--version, -v Print version number and exit.
I am mainly interested in running octave code that is compatible with Matlab, so I'd like to use this --traditional option to make sure I keep the code compatible with Matlab in case I need to run the same code inside Matlab as well.
Or may be I can "turn on" this compatiblity mode once octave starts using a different command?
I am using GNU Octave, version 3.2.4 on Linux.
thanks
I don't think this is really an octave problem, per se. The Unix shebang notation in general is somewhat limited. I don't know the exact limits off the top of my head, but I'm pretty sure many implementations aren't happy if you add more than one option to the shebang line, which seems to be your problem.
Using a wrapper script is probably the canonical way to get around such problems.
To address your question of combining short and long options, Unix conventions don't allow for this. You could consider patching octave to add a short option for --traditional, if this is feasible for you. Alternatively, I'd imagine there's a way to specify the traditional behavior in the user or system-wide Octave configuration file, but this might not be that helpful if you need the script to work on systems you don't control.