** See Also **

   * [tclvars]

** Misc **

On a [Microsoft Windows] system, the path:
D:\
is known as the HOMEPATH.

----

On my windows box my HOMEPATH is:
 
 \Documents and Settings\jrankin

I'm not sure why it would ever be the root of d, unless it has been explicitly set that way.
Given the location of this path, perhaps it refers to the Windows equivalent of the user's home directory? - [WJR]

----
[ZLM]:

======none
C:\>set HOME
HOMEDRIVE=P:
HOMEPATH=\
HOMESHARE=\\acefpscpd001\PSI0005JLM$
C:\>p:
P:\>
P:\>cd %HOMEPATH%
P:\>
P:\>c:
C:\>
C:\>cd %HOMEPATH%  
C:\>
======

----

[BR] 2003-10-28: On my system (W2K) I see this:

======none
c:\> set HOME
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\benny
======

I always interpreted this as that MS wanted something like $[HOME] on [Unix], but
in two pieces so that you can use it in batch files like

======none
%HOMEDRIVE%
cd %HOMEPATH%
======

Note for those not familiar with [Microsoft Windows] command/batch language: On Windows,
plain '''CD''' ('''C'''hange '''D'''irectory) doesn't change the drive.
You do that by just giving the drive name, as the first line in the code example does.

Tcl seems to think the same; it synthesizes a [HOME] variable for me from those
bits, if I don't have one:

======none
c:\> set HOME
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\benny

c:\> tclsh
% set env(HOME)
C:\Documents and Settings\benny
======

----

[TV] XP SP1 gives:

======none
HOMEDRIVE=D:
HOMEPATH=\Documents and Settings\someinstallinheritedname
SystemDrive=D:
SystemRoot=D:\WINDOWS
======

[cygwin] on that sys (the most recent on complete install) gives:

======none
HOMEDRIVE=D:
HOMEPATH='\Documents and Settings\someinstallinheritedname'
KDEHOME=/home/someinstallinheritedname/.kde2
PWD=/home/theo
SYSTEMDRIVE=D:
SYSTEMROOT='D:\WINDOWS'
USER=theo
USERNAME=theo
USERPROFILE='D:\Documents and Settings\someinstallinheritedname'
WINDIR='D:\WINDOWS'
======

Under cygwin, like on Unix, you have a 'mount' command, where you can choose to mount to:

   * a relative dir (probably not handy unless you want independent partion file trees with overlapping dirs)
   * something like /bin, which refers usually to the c:/cygwin/bin or /cygdrive/<currentpartition>/cygwin/bin
   * drive-defined path /cygdrive/c/cygwin/bin

Within cygwin, apart from using 'mount /cygdrive/c/ c:' you can hard define the partition not by D:/ but by /cygdrive/d/ .

Cygwin can also have stored variables in the registry, which seem to be tagged by cygwin or cygnus, but I'm not sure all could be found that way.

Setting variables under the [cygwin] Unix emulation is done by the export instead of set command, and can be automatically set at startup by /etc/profile and just before bash shows the prompt by ~/.bashrc (unfortunately with the tilde interpreted by some variable I don't know, and which is by default linked with the windows login name).

----
[RA] Thanks to some help from Kaitzachu, I managed to make the following function that uses the Windows [registry] entries to get the right "My Documents" directory:


======
proc GetHomeDir { } {
    global env

    # Check if we're using windows
    if { [expr [string compare "$::tcl_platform(platform)" "windows" ] == 0] } {
        package require registry 1.0

        set env_home [registry get {HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders} {Personal}]
    } else {
        set env_home $env(HOME)
    }
    return $env_home
}
======

It returns the "My Documents" directory on windows or the user's homedir on Unix/Linux. Not tested on Mac OS (X).

[jnc] Dec 2, 2009 - This works pretty good for me, however on Windows 7 (unsure about Vista), it returns %USERPROFILE%\Documents, which is not directly usable. Thus, I made a modification to the above proc adding the following after where env_home is set to the registry key.

======
if {[string match %USERPROFILE%* $env_home]} {
    set env_home [string replace $env_home 0 12 $env(USERPROFILE)]
}
======

It would be nice for it to autoexpand any ENV variable found in the result but I didn't go through that much trouble as it now works on XP and Windows 7 (presumably on Vista as well) which are all I am concerned about (or can test) at the moment.

----

[MG] For me on Win XP Home SP2, I have HOME, HOMEDRIVE and %homepath% elements in my $env array in Tcl. That is, from the wish prompt:

======none
% parray env HOME*
env(HOME)      = C:\Documents and Settings\User
env(HOMEDRIVE) = C:
env(HOMEPATH)  = \Documents and Settings\User
======

I noticed that you can't use HOMEDRIVE and HOMEPATH to build up HOME manually, though, or at least not without some editing - the only way to get

======none
C:/Documents and Settings/User
======

back from a [[file join]] is if you start with "C:/" and "Documents and Settings/User" - with no trailing slash on the drive, or with a leading slash on the path, the return value doesn't show the drive letter (and so refers to the path on the current volume, not necessary on $env(HOMEDRIVE)).

''[escargo] 6 Mar 2006'' - I did the following on my work Windows XP SP2 system.
I got something intriguingly different:

======none
% parray env HOME*
env(HOME)      = W:\
env(HOMEDRIVE) = W:
env(HOMEPATH)  = \
env(HOMESHARE) = \\xioshare\users$\100607
======

The W drive is a network drive; I've had some software (like [stickies]) misbehave because it assumes
that HOME is located somewhere near the executing code.  When I boot attached to my work network,
that is false; if I boot detached or attached to my home network, it is true.
It makes for interestingly variable behavior.

<<categories>> Windows