Hamilton Richards wrote:
In OS X, pathnames have two distinct syntaxes. The GUI uses the pre-X syntax, in which a pathname begins with a volume name and the separator is `:', as in
Macintosh HD:Users:ham:Documents:whatever.hs
In the Darwin (i.e., unix) command-line "underworld", a pathname begins with /Volumes, spaces are escaped with `\', and the separator is `/', as in
/Volumes/Macintosh\ HD/Users/ham/Documents/whatever.hs
When you drag a file icon onto the command line, Terminal does the right thing-- it converts the pathname from the GUI syntax to the Darwin syntax, and utilities such as more work just as they should.
Hugs, however, doesn't do so well. For example,
Prelude> :l /Volumes/Macintosh\ HD/Users/ham/Documents/whatever.hs Reading file "/Volumes/Macintosh\": ERROR "/Volumes/Macintosh\" - Unable to open file "/Volumes/Macintosh\"
Quoting the pathname changes the problem, but doesn't cure it:
Prelude> :l "/Volumes/Macintosh\ HD/Users/ham/Documents/whatever.hs" ERROR - Missing `\' terminating string literal gap
Apparently what's confusing Hugs is the `\', because removing it cures the problem:
Prelude> :l "/Volumes/Macintosh HD/Users/ham/Documents/whatever.hs" Reading file "/Volumes/Macintosh HD/Users/ham/Documents/whatever.hs":
Is this problem unavoidable, or is it just an oversight?
The backslash isn't actually part of the pathname; it's added to
prevent the shell from splitting the pathname into multiple arguments.
The shell converts the backslash-space sequence into a space.
The same issue arises in other languages; e.g. in C,
const char *name = "/Volumes/Macintosh HD/Users/ham/Documents/whatever.hs";
FILE *fp = fopen(name, "r");
would work, but including the backslash would break it.
--
Glynn Clements