OS X (Apple)

I seem to have issues compiling software and I think I've narrowed it down to something having to do with having a space in the path name to my Home folder (which contains "Macintosh HD"). The reason I think this is shown here:

Code:

[/]$ echo $HOME
/Volumes/Macintosh HD/Users/Tom
[/]$ cd $HOME
-sh: cd: /Volumes/Macintosh: No such file or directory
[/]$ cd /Volumes/Macintosh\ HD/Users/Tom
[/Volumes/Macintosh HD/Users/Tom]$

In other words simply changing directory to my Home folder using the environment variable $HOME fails, but when escaping the space in "Macintosh HD" it seems to work. One weird thing, however, is that the "~" shortcut seems to work fine, i.e.

Code:

[/]$ echo ~
/Volumes/Macintosh HD/Users/Tom
[/]$ cd ~
[/Volumes/Macintosh HD/Users/Tom]$

so I'm not entirely sure if the space is a problem. Are $HOME and "~" handled the same way?

Most importantly, does anyone have a workaround for this? I'd rather not change my home directory to something without a space because doing this causes several things to break apparently, including stopping me from being able to log in to my computer.

Any thoughts or solutions would be helpful.

Thanks,
Tom

Variables split on spaces unless you tell them not to. You do so with double-quotes. cd "$HOME" for instance ought to work.

As for ~, yes, that won't split. It's because of the way expansion happens in the shell -- it'd have to do two substitutions to split ~ into two strings, but $HOME while unquoted splits by design.

I thought it might have something to do with that so I tried quoting it with the same results, however I used single quotes instead of double so maybe that caused it to fail.

Is there any way to get around this without quoting the variable? The problem is when compiling software, which must be using unquoted environment variables. Is there anyway to use a symlink or something along those lines?

Nothing expands inside single quotes. No. Why must they be unquoted? The quotes go away -- they don't bother the program they're being fed into.

Why not show exactly what you're doing, and exactly what the problem is?

A symlink might work, if you have sufficient permissions to make it.

Code:

ln -s "/path/to/long name" "/path/to/shortname"

I don't mean to say they must be unquoted in the sense that it's a rule, I mean that the programs that I'm trying to compile (not written by me) seem to be using unquoted variables, causing $HOME to be split.
This seems to be a common problem with many different programs from different authors, but, for example, I was attempting to install the program FFTW (a fourier transform library). Here's what I did (following the install instructions):

Code:

[fftw-3.3]$ ./configure
...lots of code with no errors...
[fftw-3.3]$ make
...lots of compile code...
./libtool: line 3168: cd: /Volumes/Macintosh: No such file or directory
...a few more lines of code...
make[2]: *** [libfftw3.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
[fftw-3.3]$

Again, this is just an example and similar output is seen for multiple programs.

I'm not quite sure how I would use the symlink though. Would it be something as simple as

Code:

ln -s "/Volumes/Macintosh" "/Volumes/Macintosh HD/"

I don't know what would happen if the program is simply using $HOME as the start of the path to another directory. In other words, assuming the above symlink is in place, if I type

Code:

cd $HOME

the computer sees

Code:

cd /Volumes/Macintosh

which with the above symlink should be read as

Code:

cd /Volumes/Macintosh HD/

correct?

However if I type

Code:

cd $HOME/path/to/directory/

would the computer see

Code:

cd /Volumes/Macintosh/path/to/directory/

(not what I want)
or

Code:

cd /Volumes/Macintosh HD/path/to/directory/

(what I want)

Thanks for all your help!

I see.

You've got it exactly backwards. I showed you an example... Imagine how the cp command works -- the first parameter is the original, the second is the thing being created. This took me a while to get my head around too.

I doubt it uses $HOME -- why would it assume the source code is in $HOME? -- but the current directory, whatever that may be. If your current directory is the symlink, not the long path, I think that should work -- cd-ing into /home/shortname/whatever will get you the contents of /home/long name/whatever without the spaces in the name.

Just creating a symlink doesn't mean it'll use it. cd $HOME will still go to the long path. Don't bother messing with the value of $HOME, either -- that could have bad side-effects.

The symlink acts like a folder. cd /home/shortname will change directory into /home/shortname, not /home/long name, even though you're looking at the folder contents of /home/long name. Only the kernel really cares, so if the symlink's valid it works.

Just cd /home/shortname/whatever/, re-configure, and re-compile from there.

---------- Post updated at 10:15 AM ---------- Previous update was at 10:12 AM ----------

Another thing you could do is ignore your home folder, just build it in /tmp.

Code:

mkdir /tmp/build
cd /tmp/build
tar -zxf /path/to/source-code.tar.gz
./configure
make

I think this may be the issue here. I was assuming that it was using $HOME but you're indeed right that it's just using the current directory, which happens to also be in $HOME, so the problem still arises. Luckily I have recently replaced my optical drive with a shiny new solid state drive which I run my system off of (home folder remains in the old HD) and so I just moved my installation to my SSD. Doing this removes the issue with the space and sure enough, everything is installing correctly.

Thanks for your help with this!