On a Microsoft Windows system, the %HOMEPATH% is the name for what Unix/Linux users call $HOME. When combined with the %HOMEDRIVE% environment variable you get a complete path to the user's home directory.
For example, if your username is “JRandom” then your home drive and path is probably one of the following:
C:\Users\JRandom (Windows 7 and newer)
C:\Documents and Settings\JRandom (XP and older)That is, %HOMEDRIVE% is “C:” and %HOMEPATH% is “\Users\JRandom” (or whatever).
These path names may be localized into the PC’s language. When in doubt, use $env(HOME) or use the proper Microsoft Shell Functions (via the Ffidl or TWAPI packages).
They may also be in non-default locations, like on drive D: or in some random other directory the user (unwisely) chose.
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:
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:
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
%HOMEDRIVE% cd %HOMEPATH%
Note for those not familiar with Microsoft Windows command/batch language: On Windows, plain CD (Change Directory) 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:
c:\> set HOME HOMEDRIVE=C: HOMEPATH=\Documents and Settings\benny c:\> tclsh % set env(HOME) C:\Documents and Settings\benny
TV XP SP1 gives:
HOMEDRIVE=D: HOMEPATH=\Documents and Settings\someinstallinheritedname SystemDrive=D: SystemRoot=D:\WINDOWS
cygwin on that sys (the most recent on complete install) gives:
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:
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:
% 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
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:
% 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.