OSX-10.9.3 Cd ~’/ Problem With Spaces’

Home » CentOS » OSX-10.9.3 Cd ~’/ Problem With Spaces’
CentOS 11 Comments

Apologies for this OT post. I need some help debugging a bash script. It just happens to be provided by Apple Inc.

In a terminal session under OSX-10.9.3 I want do do this:

cd ~/’Library/Application Support’

Which is a simple enough request. However, OSX returns: cd
/users/byrnejb/Library/Application: No such file or directory. The space evidently acts as a delimiter to cd even though the path is quoted.

However this:

ls -l ~/’Library/Application Support’

returns the directory contents without error. Apparently ls is not affected.

I googled this off and on for the past two days and found nothing that works for me. All advice was to simply quote the path, which I was already doing and which also did not work. I eventually fixed my problem by doing this:

builtin cd ~/’Library/Application Support’

It seems that OSX-10.9.3 implements ‘cd’ as an external script that contains the following (Note the back-ticks surrounding the echo pipe tr commands):

#!/bin/sh builtin `echo ${0##*/} | tr \[:upper:] \[:lower:]` ${1+”$@”}

My guess is that this is where the problem is but I cannot tell what it is. Can a bash virtuoso point out the syntax error that is causing this script to mis-parse the path argument? I just want to fix this so I do not need to remember to use the builtin command when switching directories. Sheer laziness on my part.

Thanks

11 thoughts on - OSX-10.9.3 Cd ~’/ Problem With Spaces’

  • I don’t use, nor do I have a copy of OSX to test against, but my suggestion may still apply.

    Escape the space with a backslash. cd ~/Library/Application\ Support

  • Works for me on my OS X 10.8.5 Macbook Pro, xterm under xQuartz and under the Terminal.app.

    Perhaps you have ‘cd’ as an alias or a function which loses the quotes when passing to the real cd?

    Bill

  • The OP likely has a function called “cd” which does other stuff (sets the prompt?) and then calls the builtin cd, but its not quoting the variables properly and so breaking.

  • hll-m22:~ byrnejb$ cd “${HOME}/Library/Application Support/”
    -bash: cd: /Users/byrnejb/Library/Application: No such file or directory

    I had already tried many different ways of specifying the target directory before giving up and asking for help.

    The suggestions concerning a cd alias seem promising because at one time I had RVM installed, which does override cd. There is no alias present but there are artefacts of rvm scattered about so I will check these.

    Thanks for the help.

  • No OSX here either, but just to be sure, could you publish the results of:

    which cd; echo $?
    locate cd | grep ‘/cd’$; echo $?
    ls -ldb ~/Library/Application*

  • James B. Byrne wrote:

    Really dumb question: what happens when you
    cd /Users/byrnejb/Library
    ?
    Once there, what’s ls -laF show?

    Btw, I would only have quoted the directory with the space in it:
    ~/Library/”Application Support”

    mark

  • In other words, what’s the output of

    declare -f | sed -n -e ‘/^cd /,/^}/ p’

  • I get the digest version fo this list so I apologise for any discontinuity to my reply posts introduced thereby.

    $(which cd) returns /usr/bin/cd and that file contains the script I displayed yesterday. I do not have my MBP here at work today so I cannot obtain the other informations you desire.

    In any case, once the reference to aliases twigged my memory I tested for the problem with other accounts and discovered that the issue existed only for my development user id. That brought to mind that I once had RVM installed on that account. Further, I recalled I once had run into a bug with an early development version of RVM due to it overriding cd in a shell function, which is not an alias but is similar enough for most purposes. I cannot recall what that issue was but at least the memory of it put me on the right track.

    So I grepped for CD in ~/\.* and found an RVM related cd function in
    .bash_profile which did not escape $1. I changed that reference to “$1” and the problem was thereby fixed.

    Thanks for all the help and suggestions.

    I do have a few residual questions however:

    1. What does the 1+ in the shell expansion ${1+”$@”} mean and do?

    2. I know that $0 returns the shell name or shell script file name. How does
    ${0##*/} differ in effect from $0.

    3. Why is ${0##*/} used instead of $0 or ${0} in this case?