Updated 2017-07-12 23:39:10 by ak

pwd - Return the current working directory


pwd is always a fully normalized path (at least in Tcl 8.4a4 or newer). This differs from Tcl 8.3 or older, where (on some platforms at least) pwd was whatever non-unique file representation was last passed to cd. In Tcl8.4 pwd is guaranteed to be the unique normalized string representation of the path.

pwd may actually lie inside a virtual filesystem (and therefore be different to the OS'es perception of the pwd), if any are mounted.

pwd can actually change under some circumstances without the use of cd, for example if pwd is inside a directory which is deleted with file delete -force, Tcl moves the pwd out of the directory before deleting.

Note that the current directory is unfortunately a process-resource - so if you're using multiple interps in an event-driven situation, relying on a particular working directory between calls may cause you grief. In fact even without multiple interps you shouldn't write procs that rely on a particular working directory as again, you could get unexpected results if calls are interleaved with other parts of your application.

Under what circumstances might [pwd] fail to return a result? I would have assumed it would be guaranteed to return a path without error - but the result below shows otherwise. (on FreeBSD 4.9-STABLE tcl8.4.4 tclkit)
 error getting working directory name: no such file or directory
     while executing
     (in namespace eval "::math" script line 20)
     invoked from within
 "namespace eval ::math {

     variable version 1.2.2

     # misc.tcl

     namespace export    cov             fibonacci       integrate
     namespace export    max             mean            min..."
     (file "/root/shelltests/nefualert.vfs/lib/tcllib1.5/math/math.tcl" line 15)
     invoked from within
 "source /root/shelltests/nefualert.vfs/lib/tcllib1.5/math/math.tcl"
     ("package ifneeded" script)
     invoked from within
 "package require math"

update: The circumstance giving rise to the above was a situation where the directory was deleted and recreated by another process. A little suprising... but perhaps not unreasonable. A bit more suprising is that if from within the tcl process you use [file delete] & [file mkdir] then [pwd] is still unable to return a result. ...Not that I can think of a really good reason why one would need to delete & recreate dirs underneath oneself - but perhaps whilst manually experimenting & shuffling around directory trees of alternate datafiles under a running process, it may catch you unawares as it did me.

DKF: That's just classic UNIX filesystem semantics. Think of it like this: every process has a reference to its current directory, and (like other kinds of files) directories are only really deleted when their reference count drops to zero. However, discovering the name of the directory is more complex, because that requires reference to the containing directory tree, and if that doesn't have a reference to the dir, you can't find out what its name is. Networked filesystems such as NFS and AFS do not work this way because making reference counting work across a network is really hard, and neither do non-UNIX platforms (especially Windows). SMB is covered by both of these rules. :^)

AMG: On Windows, how do I get the current working directory for each volume? I want to know how to normalize a "volumerelative" path using Tcl 8.3.5. If [pwd] returns C:/foo, how do I deal with A:bar? Newer versions of Tcl have [file normalize], but I have no such luxuries.

ak - 2017-07-12 23:39:10

I don't think that Tcl does have built in. Maybe via some TWAPI call ?