Exploring the Virtual File System in a Starkit

Example 22-2 introduces the standard, recommended VFS structure for a Starkit that makes everything into a package, even the main application. However, in this section we are going to show a Starkit without packages in order to get a feel for how the VFS works. For example, instead of doing the package require hello, the main.tcl script of Example 22-3 could source the hello.tcl file directly:

source hello.kit/lib/app-hello/hello.tcl

However, this only works if you are in the directory containing the hello.kit file.

The starkit::topdir variable is set by starkit::startup to be the file name of the Starkit, which is also the root of the Virtual File System inside the Starkit. The value of starkit::topdir is an absolute pathname, so it is always valid. Example 22-5 shows a Starkit that manipulates its virtual file system.

Example 22-5 A Starkit that examines its Virtual File System

package require starkit
starkit::startup

puts "Contents of VFS before"
foreach f [glob [file join $starkit::topdir *]] {
   puts "[file size $f] $f"
}
puts "Reading data file"
set in [open [file join starkit::topdir data]]
set X [read $in]
puts $X
close $in
set out [open [file join $starkit::topdir data.new w]]
puts $out $X
close $out
puts "Contents of VFS after"
foreach f [glob [file join $starkit::topdir *]] {
   puts "[file size $f] $f"
}

Create the Starkit by putting the code in Example 22-5 into a file named main.tcl in the write.vfs directory. Then use sdx as shown in Example 22-6:

Example 22-6 Creating a simple Starkit

# These are UNIX shell commands
mkdir write.vfs
cp 22_5.tcl write.vfs/main.tcl
sdx wrap write.kit
tclkit write.kit

If you run the write.kit file more than once you will notice that the write.kit/data.new file does not persist between runs. This is because, by default, the Metakit database is modified in main memory and it is not written out to the Starkit file. If you want to store files long term, use the -writable flag to sdx:

sdx wrap write.kit -writable