macOS Environment var to point to folder with blank spaces ( Yosemite )

Barna Biro · Mar 22, 2015

This one is really driving me crazy... they managed to **** a bunch of things up with Yosemite, but this is just too much. How on Earth can one set an environment variable to point to a folder that has blank spaces in the name?! ( e.g. ~/sample folder ) I tried double quotes, escaping with \\ but still nothing... whenever I try to "cd" to the bloody folder via "cd $MY_ENV_NAME" it constantly breaks at the blank space ( "No such file or directory" - using a symbolic link is not possible because it would break other stuff ).

Unfortunately, this folder I'm trying to point to is some 3rd party garbage that I can't modify without breaking some functionality. Env vars with blank spaces worked fine on older OSX versions but Yosemite is utter garbage...

Anyone had any luck with this?

drsoong · Mar 22, 2015

whenever I try to "cd" to the bloody folder via "cd $MY_ENV_NAME" it constantly breaks at the blank space ( "No such file or directory" - using a symbolic link is not possible because it would break other stuff ).

I created a folder in /tmp/foo bar, with mkdir "/tmp/foo bar", and get the same error.

cd "$MY_ENV_NAME" does work, though. If that solves your problem.

Using

Code:

 MY_ENV_NAME=/tmp/foo\ bar

i.e. escaping, but no quotes, then allows to use directly:

Code:

Mac-mini:tmp duscha$ cd "$MY_ENV_NAME"
Mac-mini:foo bar duscha$ pwd
/tmp/foo bar

EDIT: My bad, I kept the quotes in the cd command. Escaping does not work without them, either. So, only the first options seems to be a possible work-around.
-drsoong

Barna Biro · Mar 22, 2015

Been doing the same thing all this time and doesn't work.
What version for Yosemite are you using?

EDIT: Oh wait, didn't see you have the env access wrapped in quotes...
That looks really weird... let me give it a shot and see if that changes anything.

Barna Biro · Mar 22, 2015

Yep, wrapping the entire call "$MY_VAR" in quotes instead of wrapping the value of the var does indeed work... Thanks for the help. I can't believe they managed to **** up previous functionality so badly... not to mention the complete lack of docs on these changes. Thanks again, I owe you a beer!

drsoong · Mar 22, 2015

Barna Biro said:
Yep, wrapping the entire call "$MY_VAR" in quotes instead of wrapping the value of the var does indeed work... Thanks for the help.

You are welcome.

I can't believe they managed to **** up previous functionality so badly... not to mention the complete lack of docs on these changes.

I am using a Mac at home, and Linux at work, which means I don't do much bash scripting on the Mac at home. I didn't notice it getting broken.

A quick web search suggested that this is a general bash thing, so I am rather surprised that it used to work on previous versions of OS X.

At least the Linux box at work shows the same behaviour that you describe.

Thanks again, I owe you a beer!

Well, Switzerland isn't that far from Munich. ;-)

Barna Biro · Mar 22, 2015

Perhaps I was just used to bad practices from previous OSX versions ( I'm not a huge Linux user myself )... in the past at least, MY_VAR="/some/messed up/path with blanks" used to work or you could escape the blank spaces with backward slash ( if I recall correctly, it's the same in Windows )... I don't remember ever having to wrap the calls themselves in quote blocks ( execute some command "$MY_VAR" )... anyway, at least it's working now ( it would be even better if certain providers would simply stop using spaces when putting together a freaking library / sdk / vm ). Thanks again! Will hit you up when I'm in Munich ( or drop a line if you happen to visit Switzerland )

Cheers!

chown33 · Mar 22, 2015

Barna Biro said:
Yep, wrapping the entire call "$MY_VAR" in quotes instead of wrapping the value of the var does indeed work... Thanks for the help. I can't believe they managed to **** up previous functionality so badly... not to mention the complete lack of docs on these changes. ...

This isn't a change. It's always been this way. I can see the exact same behavior on OS X 10.4.11. If necessary, I can boot my old G4 and test it all the way back to at least 10.2.

You can look this up in any bash shell reference. It will clearly explain the rules for quoting shell variables, and where whitespace causes breaks between words.

I think you were just lucky before that the variable's value didn't contain a space, or you were escaping it with backslashes. If you have the exact string that worked before, please post it. If you don't, and are only going by what you recall, then your recollection may be mistaken.

In your original post, you wrote:

( e.g. ~/sample folder ) I tried double quotes,

Please post the exact command line, showing exactly where the quotes are located.

This will work:

Code:

cd ~/"sample folder"

This won't work:

Code:

cd "~/sample folder"

because quoting removes the special meaning of ~.

drsoong · Mar 22, 2015

Escape characters in environment variable

chown33 said:
In your original post, you wrote:

( e.g. ~/sample folder ) I tried double quotes,
Please post the exact command line, showing exactly where the quotes are located.

This will work:

Code:

cd ~/"sample folder"

This won't work:

Code:

cd "~/sample folder"

because quoting removes the special meaning of ~.

This is clear, I think.

The problem is that an environmental variable is used in the cd command

Code:

cd $MY_ENV_VAR

where the variable is then not using the escaped space it was defined with:

Code:

$MY_ENV_VAR="/tmp/foo\ bar"

It neither worked with double quotes (which makes sense), nor with single quotes or without any quotes.

The environmental variable, when used in the cd command should preserve the escaped space.

-drsoong

chown33 · Mar 22, 2015

drsoong said:
This is clear, I think.

The problem is that an environmental variable is used in the cd command

Code:

cd $MY_ENV_VAR

where the variable is then not using the escaped space it was defined with:

Code:

$MY_ENV_VAR="/tmp/foo\ bar"

It neither worked with double quotes (which makes sense), nor with single quotes or without any quotes.

The environmental variable, when used in the cd command should preserve the escaped space.

-drsoong

It appears that you misunderstand how quoting (which includes escaping) and variable expansion actually works. I urge you to read the 'bash' man page:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/bash.1.html

There is a heading titled QUOTING, and it covers "Parameters", which includes variables, env vars, etc. There is also a heading titled EXPANSION that details the order in which things happen. The subject may seem simple, but it's more subtle than it seems. Your cd $MY_ENV_VAR example has inadequate quoting, which should be apparent after studying the man page

Quoting, escaping, and expansion are often misunderstood, even among people with considerable shell experience. Not accounting correctly for whitespace in pathnames is a common manifestation.

Even Apple sometimes gets it wrong. There was an installer somewhere around the 10.3 or 10.4 era that removed some things it should have, because it contained an improperly quoted variable expansion.

This example:

Code:

$MY_ENV_VAR="/tmp/foo\ bar"

is simply wrong. There shouldn't be a leading $. Accuracy is important.

The quoting (including the use of backslash inside double-quotes) is explained in the QUOTING section of the man page.

Barna Biro · Mar 22, 2015

Quoting, escaping, and expansion are often misunderstood, even among people with considerable shell experience. Not accounting correctly for whitespace in pathnames is a common manifestation.

Perhaps the reason it's misunderstood is exactly because it's counter-intuitive. As drsoong has nicely summed it up: I was already defining the variable with escaping in mind... it's simply counter-intuitive ( in my opinion ) for shell to ignore this definition. This was the source of my confusion and annoyance.

Although I understand now that this is how it works, I refuse to accept that "it is normal"... because it's simply counter-intuitive. Agree to disagree... I didn't post with the intention of starting an endless debate on the topic and I don't care enough to fire up some old Mavericks version and test things out ( just to prove you right or wrong ) but I'm quite confident in my memory that in the past, it was enough to define a variable with an already escaped value and it was treated as such from that point on ( there was no need to escape it again and again and again every time you had to use it... that was the entire point of defining it with an already escaped value )...

Thanks for the replies though, I appreciate them.

drsoong · Mar 23, 2015

full agreement

Barna Biro said:
Perhaps the reason it's misunderstood is exactly because it's contra-intuitive. As drsoong has nicely summed it up: I was already defining the variable with escaping in mind... it's simply contra-intuitive ( in my opinion ) for shell to simply ignore this definition. This was the source of my confusion and annoyance.

Although I understand now that this is how it works, I refuse to accept that "it is normal"... because it's simply contra-intuitive. Agree to disagree... I didn't post with the intention of starting an endless debate on the topic and I don't care enough to fire up some old Mavericks version and test things out ( just to prove you right or wrong ) but I'm quite confident in my memory that in the past, it was enough to define a variable with an already escaped value and it was treated as such from that point on ( there was no need to escape it again and again and again every time you had to use it... that was the entire point of defining it with an already escaped value )...

Thanks for the replies though, I appreciate them.

I fully agree with Barna Biro. I accept and understand the handling, but it is counter-intuitive.

-drsoong

Search

Search

macOS Environment var to point to folder with blank spaces ( Yosemite )

Barna Biro

macrumors 6502a

drsoong

macrumors member

Barna Biro

macrumors 6502a

Barna Biro

macrumors 6502a

drsoong

macrumors member

Barna Biro

macrumors 6502a

chown33

Moderator

drsoong

macrumors member

chown33

Moderator

Barna Biro

macrumors 6502a

drsoong

macrumors member

Our Staff