I've recently stumbled on the different treatment of variables
in namespace eval body between Jim Tcl (as of 0.81 nb 1,
0.79 +dfsg0-2 and 0.77 +dfsg0-3 [1-3]) and Tcl 8.6.
[1]
http://pkgsrc.se/lang/jimtcl
[2]
http://packages.debian.org/bullseye/jimsh
[3]
http://packages.debian.org/buster/jimsh
Namely, while namespace eval foo { set bar 42 } assigns to
the foo::bar variable in the latter, it appears like in Jim,
the same code rather modifies a variable local to the
namespace eval body itself; for instance, the following code
prints 42 in 8.6, but 1 in Jim:
namespace eval foo { } ; set foo::bar 1
namespace eval foo { set bar 42 }
puts [ set foo::bar ]
(It sure looks like that Jim likes its anonymous procedures
to a fault, or does it?)
Of course it's possible to namespace upvar in Jim (but not
in Tcl 8.6); and a workaround that appears to run the same
in either implementation is to introduce a separate "nset"
command:
proc nset { varn args } {
set p [ uplevel 1 { ::namespace current } ]
if { "::" ne $p } { append p :: }
## .
set ${p}$varn {*}$args
}
namespace eval foo { } ; set foo::bar 1
namespace eval foo { nset bar 42 } ; ## sets foo::bar in both Jim and 8.6
puts [ set foo::bar ] ; ## prints 42
Thoughts?
Another issue with Jim is that the 'source' command somehow
silently ignores non-regular files, such as pipes and character
specials. Same goes for such files passed as an argument to
the interpreter; for example:
bash$ jimsh <(printf %s\\n "puts 42")
bash$ tclsh8.6 <(printf %s\\n "puts 42")
42
bash$
Note that doing stat(2) on the /dev/fd/XX file (that is used
to implement Bash <() pipe) in the example above, identifies
the file as a pipe in Linux-based systems, but as a character
special in NetBSD (unless mount_fdesc(8) is in use, in which
case it is also identified as a pipe in this case.)
Is there any particular reason for such a behavior?
TIA.
--
FSF associate member #7257
http://am-1.org/~ivan/
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)