[Ilja]

how do you set an environment-variable in you .login- or .cshrc-file which contains a path with spaces? I tried to espcape the spaces,

setenv ECLIPSE_HOME /Volumes/PowerBook\ G4\ \[+\]/Applications/eclipse/workspace

but when I then try to use the env it says:

echo $ECLIPSE_HOME
echo: No match.

or

cd $ECLIPSE_HOME
cd: Too many arguments.

surrounding the path with quotes doesn't help either

[Arkham_c]

Originally posted by Ilja:
how do you set an environment-variable in you .login- or .cshrc-file which contains a path with spaces? I tried to espcape the spaces,

setenv ECLIPSE_HOME /Volumes/PowerBook\ G4\ \[+\]/Applications/eclipse/workspace

but when I then try to use the env it says:

echo $ECLIPSE_HOME
echo: No match.

or

cd $ECLIPSE_HOME
cd: Too many arguments.

surrounding the path with quotes doesn't help either

Quotes should work fine. The problem is you have to use quotes around the variable name when you use it, eg:

Code:
setenv ECLIPSE_HOME "/Volumes/PowerBook G4/Applications/eclipse/workspace"

echo "$ECLIPSE_HOME"

cd "$ECLIPSE_HOME"

[Ilja]

there is no way to set it so you can use the variable name without quotes?

[CatOne]

Originally posted by Ilja:
there is no way to set it so you can use the variable name without quotes?

Well backslash should escape so that should work. I don't know what that funky business with the [+] was though.

But quotes work quite well. Why not just use that? To get the working path with backslashes you could also use tab completion to have the shell do it for you -- for example just cd to /

And do cd Desk[tab] and it will select Desktop\ D

and wait for you to finish completion.

[Ilja]

I know about the tabs, but still it's along path which is a pain in the ass to type every time, even if you can tab it for a part...

with quotes does work, but I was hoping to have an option to also use echo $ECLIPSE_HOME (so without quotes)

o well, probably isn't possible, I'll use quotes then

[Arkham_c]

Originally posted by Ilja:
I know about the tabs, but still it's along path which is a pain in the ass to type every time, even if you can tab it for a part...

with quotes does work, but I was hoping to have an option to also use echo $ECLIPSE_HOME (so without quotes)

o well, probably isn't possible, I'll use quotes then

Set up an alias, so you don't have to type the quotes in your .cshrc file:

Code:
alias eclipse 'cd "/Volumes/Eclipse IDE/workspace"'

Untested, but should work. Then just type the alias and it will go there.

[absmiths]

Originally posted by Arkham_c:
Set up an alias, so you don't have to type the quotes in your .cshrc file:

Code:
alias eclipse 'cd "/Volumes/Eclipse IDE/workspace"'

Untested, but should work. Then just type the alias and it will go there.

I am assuming that this path is used by shell scripts and the like and that might cause problems.

I would just create a symbolic link in your home directory to the eclipse workspace, say something like '/Users/me/eclipse_workspace' and point that to the big long path, then just use that thereby avoiding all the path issues.

[Rainy Day]

Certainly the symbolic link, as stated above, should work. Here are a few more (untested) ideas (untested because i normally use a different shell):

1) Use hard quotes instead of the soft quotes:

  setenv ECLIPSE_HOME '/Volumes/PowerBook G4/Applications/eclipse/workspace'

With the double quotes, i believe they are lost immediately after the setenv command is parsed, which is why quotes must be used around the variable later on, whereas the hard quotes should persist until the variable is actually used later on.

2) The backslash approach should work, although you may have to soft quote it in the setenv command like this:

  setenv ECLIPSE_HOME "/Volumes/PowerBook\ G4\ \[+\]/Applications/eclipse/workspace"

I too do not know what the \[+\] thing is all about. I would suggest using the tab-completion approach, mentioned above, to construct the actual path to be used in the setenv command. I suspect this is what the previous poster meant, although not explicitly stated.

The tab-completion method is very important, too, because some "single" special-Macintosh-characters are, in fact, multiple character sequences. The bullet character (option-8) is an example.

Hope this helps.

[Ilja]

I tried both approaches without any luck

The [+] thing is just the naming of my second hard-drive. Came like that when I bought it and never bothered to change it...

[utidjian]

Originally posted by Ilja:
I tried both approaches without any luck

The [+] thing is just the naming of my second hard-drive. Came like that when I bought it and never bothered to change it...

The simplest thing would be to rename that volume/disc to Powermac_G4 ... this would fix your problem once and for all.

In either case (old or new name) just make a soft link to the folder.

cd
ln -s /path/to/folder name

then whenever you need to get to that folder, simply

cd ~/name

and you're there.

While it is "legal" and possible to name a file or folder just about anything you want... even using non-printable or other special characters... it doesn't mean it makes sense to do so. Mainly because you have to jump through hoops to get there. It also plays havoc with assumptions made by script writers and other things that use the commandline.

Fix the name of that volume and be done with it... otherwise you will always be fighting with it.

[Rainy Day]

Originally posted by utidjian:
While it is "legal" and possible to name a file or folder just about anything you want... It also plays havoc with assumptions made by script writers and other things that use the commandline.

utidjian makes a good point here. I have run into perl scripts which break when there's a space anywhere in the path name. In my opinion, this represents poor scripting technique, but that doesn't change the fact that you may run into more grief in the future if you have spaces in pathnames.

With that said, however, i have to admit that most of the volume names of the partitions on my HD have spaces in them, yet i seldom run into space related problems, so YMMV. Of course it doesn't matter if your MacOS X boot volume has spaces in it or not because it is simply referred to as / (and i rarely reference volumes other than my boot volume from the command line environment, so this may be why i don't run into the problem very often).

If you don't want to rename your HD, then symbolic links, as have been suggested a couple of times already in this thread, are probably your best bet.