The given pathname may start with a ``~‘’, which expands to the
process owner’s home directory (the environment variable HOME must be
set correctly). “~ user” expands to the named user’s home directory"
This isn’t relevant on windows. Thus:
File.expand_path(“~foo”, “c:/somedir”) → “~foo”
where in fact it should return “c:/somedir/~foo”.
Also:
File.expand_path(“~”, “c:/somedir”)
throws up the error “expand_path': couldn't find HOME environment -- expanding ~’ (ArgumentError)”
It seems strange that the first example doesn’t throw up the same error
that the second one does.
Can this functionality be disbaled on windows platforms in a future
version? Or at least add a parameter to the function call to disable it?
Wouldn’t it make more sense to expand it to My Documents (C:\Documents and
Settings\Username\My Documents on WinXP)? I suppose it would be
worthwhile to be able to disable it, though.
···
On Thu, 18 Sep 2003 17:16:00 +0100, Alan Davies wrote:
The given pathname may start with a ``~‘’, which expands to the
process owner’s home directory (the environment variable HOME must be
set correctly). “~ user” expands to the named user’s home directory"
No. ~ has no meaning to Windows shells. There are times when I wish that it
didn’t to Unix shells. After all, that’s what ${HOME} is for.
-austin
···
On Fri, 19 Sep 2003 11:36:28 +0900, Tom Felker wrote:
Wouldn’t it make more sense to expand it to My Documents (C:\Documents
and Settings\Username\My Documents on WinXP)? I suppose it would be
worthwhile to be able to disable it, though.
The given pathname may start with a ``~‘’, which expands to the
process owner’s home directory (the environment variable HOME must be
set correctly). “~ user” expands to the named user’s home directory"
This isn’t relevant on windows. Thus:
Wouldn’t it make more sense to expand it to My Documents (C:\Documents and
Settings\Username\My Documents on WinXP)? I suppose it would be
worthwhile to be able to disable it, though.
Actually, I think it should just expand to C:\Documents and
Settings\UserName and you can append the rest from there. That’s the
*nix equivalent pretty much.
On Fri, 19 Sep 2003 11:36:28 +0900, Tom Felker wrote:
Wouldn’t it make more sense to expand it to My Documents (C:\Documents
and Settings\Username\My Documents on WinXP)? I suppose it would be
worthwhile to be able to disable it, though.
No. ~ has no meaning to Windows shells. There are times when I wish that it
didn’t to Unix shells. After all, that’s what ${HOME} is for.
This is true; but I think for portability reasons, since COMMAND.COM
isn’t exactly what I would call a culture of shell idioms, ~ and ${HOME}
(%HOME%) should be considered synonymous. If not ~, then at least
${HOME} ought to point to C:\Documents and Settings\UserName I think.
The given pathname may start with a ``~‘’, which expands to the
process owner’s home directory (the environment variable HOME must be
set correctly). “~ user” expands to the named user’s home directory"
This isn’t relevant on windows. Thus:
Wouldn’t it make more sense to expand it to My Documents (C:\Documents
and
Settings\Username\My Documents on WinXP)? I suppose it would be
worthwhile to be able to disable it, though.
Actually, I think it should just expand to C:\Documents and
Settings\UserName and you can append the rest from there. That’s the
*nix equivalent pretty much.
Sean O'Dell
Some interesting points being made on this thread, but the problem I had
was that I has a files beginning with ~ in my temp folder. Using
expand_path to get the full path of these files failed. If it expanded
it to user directories, then it woulod be returning incrrect path names,
simply because ~ has no meaning on windows.
If I have a file called ~foo in a dir called “c:/somedir”, then I would
expand_path to return “c:/somedir/~foo”, not “C:/Documents and Settings/foo”
Alan.
···
On Thu, 18 Sep 2003 17:16:00 +0100, Alan Davies wrote:
That’s a no fly zone, as far as I’m concerned. My %HOME% is not the same as
my %USERPROFILE%. Further, ~foo is a valid filename on Windows. (It’s valid
in Unix, too, but you have to do ~foo to get it to work from the shell.)
I’d like to see Ruby handle this right on each platform.
-austin
···
On Sat, 20 Sep 2003 01:18:35 +0900, Sean O’Dell wrote:
Austin Ziegler wrote:
On Fri, 19 Sep 2003 11:36:28 +0900, Tom Felker wrote:
Wouldn’t it make more sense to expand it to My Documents
(C:\Documents and Settings\Username\My Documents on WinXP)? I
suppose it would be worthwhile to be able to disable it, though.
No. ~ has no meaning to Windows shells. There are times when I wish
that it didn’t to Unix shells. After all, that’s what ${HOME} is for.
This is true; but I think for portability reasons, since COMMAND.COM
isn’t exactly what I would call a culture of shell idioms, ~ and ${HOME}
(%HOME%) should be considered synonymous. If not ~, then at least
${HOME} ought to point to C:\Documents and Settings\UserName I think.
I use Windows, and choose to set HOME to D:/home/gavin, so that
Windows and Cygwin can be in agreement. Certain Windows programs will
make use of any %HOME% setting.
Gavin
···
On Saturday, September 20, 2003, 2:18:35 AM, Sean wrote:
Austin Ziegler wrote:
On Fri, 19 Sep 2003 11:36:28 +0900, Tom Felker wrote:
Wouldn’t it make more sense to expand it to My Documents (C:\Documents
and Settings\Username\My Documents on WinXP)? I suppose it would be
worthwhile to be able to disable it, though.
No. ~ has no meaning to Windows shells. There are times when I wish that it
didn’t to Unix shells. After all, that’s what ${HOME} is for.
This is true; but I think for portability reasons, since COMMAND.COM
isn’t exactly what I would call a culture of shell idioms, ~ and ${HOME}
(%HOME%) should be considered synonymous. If not ~, then at least
${HOME} ought to point to C:\Documents and Settings\UserName I think.