JTcl Differences from Tcl 8.4

While JTcl is mostly compatible with Tcl 8.4, there are some differences compared to the C/Tcl version. This page supercedes the Tcl 8.4 documentation.

  • Regular expressions: Tcl ARE (Advanced Regular Expression) syntax is supported with some caveats.
    • JTcl uses the Java regular expression engine java.util.regex, rather than a port of the Tcl ARE library. However, java.util.regex regular expression syntax is not supported.
    • Several Tcl ARE patterns are substituted at runtime to the corresponding valid java.util.regex patterns. For example, Tcl ARE pattern [:alnum:] is replaced by \pAlnum.
    • Basic REs are not supported (embedded option 'b' causes PatternSyntaxException)
    • Extended REs are not supported, unless they are ARE-compatible and are not explicitly requested with the 'e' embedded option ('e' causes PatternSyntaxException)
    • Tcl ARE always attempts to match the longest string starting from the outermost levels to the inner levels of parens. With alternation (|), TCL chooses the longest match of all the branches. Java's java.util.regex on the other hand, evaluates the RE from left to right, and returns the first successful match, even if it is not the longest.
    • Some syntax errors that would occur in Tcl ARE do not occur because java.util.regex is more forgiving of bad RE syntax.
  • Some file options are limited due to Java 1.5 API restrictions:
    • file atime is not supported.
    • file attributes is not supported.
    • file stat does not return information for dev, gid, ino, mode, and nlink attributes; ctime and atime attributes report the same value as mtime.
    • file link and file readlink return an absolute, canonical path to the target of the link, even if the target is a relative path.
    • file link cannot create links.
    • With Java 1.5, file executable on Windows returns 1 if the extension is exe, com, or bat or the file is a directory. On other platforms, it always returns 1. With Java 1.6+, executable returns 1 if java.io.File.canExecute() is true.
    • file owned always returns 1 if the file exists.
  • Integer expressions are always computed with 64-bit integers, so any overflow/underflow with 32-bit integers will not occur. JTcl acts similar to Tcl 8.4 compiled on a 64-bit architecture.
  • JTcl uses Java sorting utilities rather than a custom implementation, and may return results differently. For examle, lsort -index 0 {{a b} {a c}} can sort into either order. Likewise, unsorted results from array names, etc. may be returned in a different order due to using Java hashing algorithms.
  • encoding, fconfigure -encoding and source -encoding map characters using Java's Unicode facilities. JTcl replaces illegal UTF-8 byte sequences with the Unicode replacement character U+FFFD, rather than their Cp1252 equivalent.
  • exec and open pipes are somewhat limited due to the Java 1.5 process model which does not allow proper stdio file descriptor inheritance and true OS-level pipes.
    • Background processes will not survive the JVM process if they read from stdin or write to stdout or stderr
    • JTcl may send more stdin to a subprocess than it actually reads, causing the unread input to be lost
    • To limit stdin stealing from the shell, processes started in the background with & do not automatically inherit stdin
  • errorInfo sometimes reports deep errors as invoked from within rather than while executing.
  • pid returns the filename referenced by /proc/self on those operating systems that support it, and returns -1 on other operating systems. pid fileid may return -1 if the PIDs of the pipeline cannot be determined using a non-portable reflection on java.lang.Process.
  • The standard shell, tcl.lang.Shell, always sets the tcl_interactive variable to 1 unless a JTcl script is specified as an argument. It cannot differentiate true terminal interaction and a stdin input redirection. Therefore, if a script is sent to tcl.lang.Shell via stdin redirection, the shell will print the % prompt as if it were interacting with a terminal. As a workaround, either explicitly set tcl_interactive to 0 to suppress the prompt, or use tcl.lang.NonInteractiveShell which sets tcl_interactive to 0 prior to any command processing.
  • load is not supported.
  • info nameofexecutable creates a temporary script file to invoke the Java executable with the current classpath and the name of the JTcl main class. The temporary script file is deleted on exit.
  • JTcl allows file path names to be prefixed with resource:/ for open and source commands. which allow opening or sourcing files that are included on the Java CLASSPATH, or within any jar file on the CLASSPATH. Resource files may only be opened in read only mode. Note that use of resource:/ is not supported by the file command.

JTcl also includes the following backported 8.5 commands:

  • apply
  • dict
  • lassign
  • lrepeat
  • lreverse
  • source -encoding name and the -encoding shell command line option (e.g., jtcl -encoding enc-name source.tcl, where enc-name is a valid JTcl character encoding.)