Has anything been done or is being planned to do about not being able to turn off tilde substitution in the file commands (and some other commands too)? The latest I’ve read about this is http://wiki.tcl.tk/28190, but surely such a dangerous feature in a programming language can’t just be ignored? Wouldn’t it be as easy as letting the C function Tcl_TildeSubst() check for the existence of a global Tcl variable, and based on that do tilde expansion or not?
I often write Tcl scripts when a shell script isn’t enough, and a lot of time it includes comparing, copying, opening, removing and/or renaming files. Before I run a script I always use find to check for filenames that start with a tilde (~). I’m interested in hearing about how other Tcl programmers do it.
Background
Tilde substitution only happens at the point where Tcl is about to interpret a string as a filename, and it only happens when the first character of the string is a
~(if the character is anywhere else, it is purely normal). There are exactly two substitutions that are done:~is on its own or is followed by a directory separator, it refers to your home directory (well, strictly to the directory named in theHOMEenvironment variable, which defaults to your home directory).~is followed by anything else, the remainder of the filename up to the end of the string or the first directory separator (whichever comes first) is interpreted as a user name, and the~usersequence is replaced by that user’s home directory (looked up using system utilities, so as listed in/etc/passwdon Unix, etc.)These features are disabled in safe interpreters, i.e., interpreters created with
interp create -safeor withsafe::interpCreate.Workaround
The simplest way to stop a leading
~from being a problem is to put./in front of it, and to always use the-directoryoption toglob(which is otherwise the only place in Tcl which can produce those sorts of filenames ambiguously; everywhere else it is presumably intended). Working with full filenames throughout usually leads to less problems overall (and I recommend never changing the working directory if possible; that just causes tremendous confusion).I wouldn’t consider safe interpreters to be a workaround, as they have many other restricted features as well (e.g., no access at all to the filesystem by default).
The Policy Question
As for the suggestion that it should be possible to disable it… That’s an interesting one, but it’s never been raised seriously with Tcl’s steering committee. The problem is that there’s a lot of code which assumes the current behavior; I think it wouldn’t be a particular problem to add a hack (e.g., a magic unsupported variable) to turn it off — there’s an interpreter context at the point where the expansion is done, so checking a Tcl variable to see whether to do it is trivial — but I’d personally worry a lot about what would be broken unexpectedly by such a change.
Stack Overflow isn’t a very good environment for discussing such changes. You’d be better off asking on the tcl-core mailing list. Be aware that that’s a fairly robust debating chamber at times (though virtually always polite). An alternative (if you like IRC) is asking on #tcl on freenode.