I'm having trouble using any predefined environmental variable in my module files. For example a line like this setenv TEST ${HOSTNAME} throws an error, where ${HOSTNAME} is defined by the system as a global environmental variable. The error looks like: ERROR:102: Tcl command execution failed: set TEST ${HOSTNAME}. I have set environmental variables in the module file itself and tried using those and get the same kind of error. For example,
This does not work:
setenv DUMMY /location/to/some/file
setenv TEST ${DUMMY}
I get a similar error as above: ERROR:102: Tcl command execution failed: set TEST ${DUMMY}. However,
This works:
set DUMMY /location/to/some/file
setenv TEST ${DUMMY}
There are certain lines that I needed to use predefined global environmental variables, so the above command cannot be used.
How can one use a predefined environmental variable in module files?
The set command sets a Tcl variable. These are local to the module processing: they are not exported anywhere else. There are very few restrictions on what characters you can use in a Tcl variable name; about the only ones to really beware of are : and (, though there are a few others that can make things really awkward so it's still best to stick to alphanumerics (and _).
The setenv command (which is not a standard Tcl command, but rather something the module system adds) sets environment variables, and these are exported to subprocesses. They are also mapped as Tcl variables as elements of the global associative array, env, so you can do this
setenv DUMMY /location/to/some/file
setenv TEST $env(DUMMY)
(The restriction on ( that I mentioned up above is because this gets tangled up with the syntax for associative arrays. Element names can use any character at all. Environment variables probably ought to avoid ASCII NUL and = in their names…)
The implementation of setenv is probably something like this:
proc setenv {variable value} {
global env
set env($variable) $value
}
The mapping to env is bi-directional.
Related
I am trying to run a tcl script through .bat file. I want to read some cmd arguments in the tcl script. Below is my code:
Command to run:
D:\Cadence\Sigrity2021.1\tools\bin\PowerSI.exe -tcl abcd.tcl %new_var%.spd %new_file_name%
Below is how I am trying to read the variable in the tcl file:
sigrity::open document [lindex $argv 0] {!}
It open up the Cadence Sigrity, but I see the below error:
How do I read cmd argument in tcl?
If you have no other way to do it that you can find (and it sounds like that might be the case) then you can fake it by writing a helper file with content like this, filling in the real arguments in the appropriate places:
# Name of script to call
set ::argv0 "abcd.tcl"
# Arguments to pass
set ::argv {}
lappend ::argv "%new_var%.spd"
lappend ::argv "%new_file_name%"
# Number of arguments (rarely used)
set ::argc [llength $::argv]
# Do the call
source $::argv0
Then you can pass that file to PowerSI and it will set things up and chain to the real file. It's messy, but practical.
If you're writing this from Tcl, use the list command to do the quoting of the strings (instead of putting them in double quotes) as it will do exactly the right thing for you. If you're writing the file from another language, you'll want to make sure you put backslashes in before \, ", $ and [ characters. The fiddlyness of doing that depends on your language.
I have the following function in makefile:
define INSTALL_SCRIPT
SRC_DIR = $(ROOT)\src
cd $(SRC_DIR)
$(SRC_DIR)\stage.bat
endef
I also echo the steps, so here's the output of the above snippet:
$SRC_DIR = C:\project_root\src
'SRC_DIR' is not recognized as an internal or external command,
operable program or batch file.
$cd
C:\project_root
\stage.bat
'\stage.bat' is not recognized as an internal or external command,
operable program or batch file.
It seems that in assignment statement the value is expanded correctly but then $(SRC_DIR) gives an error. Then cd goes to one directory up (and not src), then when I need to execute the batch file, $(SRC_DIR)'s value seems to be empty.
Assuming you're trying to do this from a recipe context, you would need to do it as follows:
define INSTALL_SCRIPT
set SRC_DIR=$(ROOT)\\src & \
cd %SRC_DIR% & \
%SRC_DIR%\\stage.bat
endef
sometarget:
#$(INSTALL_SCRIPT)
You need the \ at the end of each line to concatinate them into a single recipe line (other wise the variable you set will fall out of context when the first recipe line's shell terminates). You seem to be using windows so I believe you need to use the %varname% syntax to refer to the variables. Notice that $(ROOT) is a makefile variable in this case, so it still uses the $ syntax. (Note that if you were in bash you would need to use $$ to refer to shell variables). You also need to double the \\ in directory names, as make will interpret the first slash as an escape, and then pass a single slash to cmd.
Note that my windows machine doesn't have make installed on it, so I couldn't test the above, so it's quite possible I missed something.
I am trying to move a large number of files using Tcl and came across the expression :
file rename {*}[glob *tcl] dir/ which works perfectly.
Can anyone explain how this command works or what this feature is called?
It's a compound of two commands and some useful syntax.
glob returns a list of filenames that match the pattern, *tcl in your case, or an error if nothing matches. There's a bunch of options you could use to modify what it returns, but you're not using any of them; that's great for your use case.
file rename will rename files or move files around. In particular, when the final argument is an existing directory name, the other arguments are files (or directories) that will be moved into that directory. (That it moves things around is sensible if you're familiar with how POSIX system calls work.)
The final piece of the puzzle is {*}[…], i.e., command expansion, which runs a command (which is glob *tcl in your case) and uses the elements of the list it returns as a sequence of arguments to the command call within which it is used. Which is useful; we want a list of filenames at that point of the call to file rename. There's no real limit on the number of arguments that can be moved around that way, other than basic things like memory and so on.
The {*} prefix (it's only special at the start of a word) can be used with other well-formed ways of producing a Tcl word (e.g., a read from a variable with $ or a literal with {…}) or even with a compound word, though use with compound words is usually a sign that what you're doing is probably unwise.
If you have old Tcl code, written for Tcl 8.4 or before, you won't see {*}. Instead, you'd see something like this:
eval file rename [glob *tcl] dir/
# Or, more properly, one of these horrors:
eval {file rename} [glob *tcl] {dir/}
eval [list file rename] [glob *tcl] [list dir/]
eval [linsert [linsert [glob *tcl] 0 file rename] end dir/]
These were notoriously awkward to get right in tricky cases (causing many subtle bugs). The expansion syntax was added in Tcl 8.5 exactly to get rid of this whole class of trouble. eval still exists in modern Tcl, but it is now thankfully rarely used.
I am confused as to why Sublime Text 2 build systems tend to put the exec command as an array. Though this is suggested in the docs (and works), just putting the command as a string works just as well, and is (in my opinion) more straightforward.
The Sublime Text build system uses subprocess.Popen, which recommends the usage of an array. Otherwise the interpretation is platform-dependent.
Cited from the python 2 subprocess documentation:
args should be a sequence of program arguments or else a single string. By default, the program to execute is the first item in args if args is a sequence. If args is a string, the interpretation is platform-dependent (...). Unless otherwise stated, it is recommended to pass args as a sequence.
Additional important cite (thanks #Dimpl for pointing that out):
The shell argument (which defaults to False) specifies whether to use the shell as the program to execute. If shell is True, it is recommended to pass args as a string rather than as a sequence.
The shell argument is set True if you use the shell_cmd and False for cmd. Hence based on the cites I would suggest to use an array for cmd and a string for shell_cmd.
I am trying to convert some tcl script into a C++ program. I don't have much experience with tcl and am hoping someone could explain what some of the following things are actually doing in the tcl script:
1) set rtn [true_test_sfm $run_dir]
2) cd [glob $run_dir]
3) set pwd [pwd]
Is the first one just checking if true_test_sfm directory exists in run_dir?
Also, I am programming on a windows machine. Would the system function be the equivalent to exec statements in tcl? And if so how would I print the result of the system function call to stdout?
In Tcl, square brackets indicate "evaluate the code between the square brackets". The result of that evaluation is substituted for the entire square-bracketed expression. So, the first line invokes the function true_test_sfm with a single argument $run_dir; the result of that function call is then assigned to the variable rtn. Unfortunately, true_test_sfm is not a built-in Tcl function, which means it's user-defined, which means there's no way we can tell you what the effect of that function call will be based on the information you've provided here.
glob is a built-in Tcl function which takes a file pattern as an argument and then lists files that match that pattern. For example, if a directory contains files "foo", "bar" and "baz", glob b* would return a list of two files, "bar" and "baz". Therefore the second line is looking for any files that match the pattern given by $run_dir, then using the cd command (another Tcl built-in) to change to the directory found by glob. Probably $run_dir is not actually a file pattern, but an explicit file name (ie, no globbing characters like * or ? in the string), otherwise this code may break unexpectedly. On Windows, some combination of FindFirstFile/FindNextFile in C++ could be used as a substitute for glob in Tcl, and SetCurrentDirectory could substitute for cd.
pwd is another built-in Tcl function which returns the process current working directory as an absolute path. So the last line is querying the current working directory and saving the result in a variable named pwd. Here you could use GetCurrentDirectory as a substitute for pwd.