Improve details about attached zipfs archives in tclsh and wish (backport from 9.0)

2 files changed, 30 insertions, 10 deletions

diff --git a/doc/tclsh.1 b/doc/tclsh.1
index 3a78737..965e76d 100644
--- a/doc/tclsh.1
+++ b/doc/tclsh.1
@@ -141,14 +141,22 @@ incomplete commands.
 See \fBTcl_StandardChannels\fR for more explanations.
 .SH ZIPVFS
 .PP
-When a zipfile is concatenated to the end of a \fBtclsh\fR, on
-startup the contents of the zip archive will be mounted as the
-virtual file system /zvfs. If a top level directory tcl8.6 is
-present in the zip archive, it will become the directory loaded
-as env(TCL_LIBRARY). If a file named \fBmain.tcl\fR is present
-in the top level directory of the zip archive, it will be sourced
-instead of the shell's normal command line handing.
+When a zipfile is concatenated to the end of a \fBtclsh\fR, on startup
+the contents of the zip archive will be mounted under the virtual file
+system \fB//zipfs:/\fR. If a top level directory \fBtcl_library\fR is
+present in the zip archive, it will become the directory loaded as
+env(TCL_LIBRARY). If a file named \fBmain.tcl\fR is present in the top
+level directory of the zip archive, it will be sourced instead of the
+shell's normal command line handing.
+.PP
+Only one zipfile can be concatenated to the end of executable image
+(tclsh, or wish). However, if multiple zipfiles are
+concatenated, only the last one is used.
+
+This filesystem is read-only. Files cannot be added or modified within
+this mounted file system.  See zipfs(n) for complete details.
+
 .SH "SEE ALSO"
-auto_path(n), encoding(n), env(n), fconfigure(n)
+auto_path(n), encoding(n), env(n), fconfigure(n), zipfs(n)
 .SH KEYWORDS
-application, argument, interpreter, prompt, script file, shell
+application, argument, interpreter, prompt, script file, shell, zipfs
diff --git a/doc/zipfs.n b/doc/zipfs.n
index 0a05078..9776590 100644
--- a/doc/zipfs.n
+++ b/doc/zipfs.n
@@ -56,7 +56,7 @@ This takes the name of a file, \fIfilename\fR, and produces where it would be
 mapped into a zipfs mount as its result. If specified, \fImountpoint\fR says
 within which mount the mapping will be done; if omitted, the main root of the
 zipfs system is used. The \fIinZipfs\fR argument is a an optional boolean
-which controls whether to fully canonicalise the name; it defaults to true.
+which controls whether to fully canonicalize the name; it defaults to true.
 .TP
 \fBzipfs exists\fR \fIfilename\fR
 .
@@ -193,6 +193,18 @@ then the resulting image is an executable that will \fBsource\fR the script in
 that \fBmain.tcl\fR after mounting the ZIP archive, and will \fBexit\fR once
 that script has been executed.
 .PP
+\fBNote:\fR \fBtclsh\fR and \fBwish\fR can be built using either
+dynamic binding or static binding of the core implementation
+libraries. With a dynamic binding, the base application Tcl_Library
+contents are attached to the \fBlibtcl\fR and \fBlibtk\fR shared
+library, respectively. With a static binding, the Tcl_Library
+contents, etc., are attached to the application, \fBtclsh\fR or
+\fBwish\fR. When using \fBmkimg\fR with a statically built tclsh, it is
+the user's responsibility to preserve the attached archive by first
+extracting it to a temporary location, and then add whatever
+additional files desired, before creating and attaching the new
+archive to the new application.
+.PP
 \fBCaution:\fR highly experimental, not usable on Android, only partially
 tested on Linux and Windows.
 .RE