Issues

Issue #164 resolved

cdproject breaks whenever a project directory's path contains spaces

croach
created an issue

I get the following error when running cdproject for a virtualenv project I have where the directory path contains a space (e.g., ~/Developer/Django Fundamentals/code):

typeset: not valid in this context: Fundamentals/code

Comments (10)

  1. Doug Hellmann repo owner

    I can't reproduce this problem, and have a test that seems to say that spaces work fine in paths. Please reopen with more details if you still have the problem.

  2. croach reporter

    Hi Doug,

    Sorry it took me so long to get back to you, but it was a little tough getting the bug to show up in the test you're referring to.

    There are two reasons you're probably not seeing the issue in the tests. The First is that the bug itself only shows up in the Z shell. Since the tests are being run with /bin/sh, the tests run without issue, but when you switch that to /bin/zsh, you get an error with the typeset line in the cdproject function.

    The second problem with the test is that the failed call to cdproject does not trigger the assertSame call since the error in cdproject causes the test function to exit prematurely. So, if you're watching the output of the tests, you'll see the typeset error, but all tests will show that they passed. I made a fix for the test_space_in_path function that runs the test in a separate subshell, so that it can capture any error and register it as a test failure. See my earlier pull request that fixes both the bug in the cdproject function and the test_space_in_path function.

    To see the bug in the tests, checkout the tests/test_project_cd.sh file from my pull request and make the following change:

    diff -r 7b36dd4f911d tests/test_project_cd.sh --- a/tests/test_project_cd.sh Mon Nov 26 02:18:25 2012 -0800 +++ b/tests/test_project_cd.sh Sun Apr 07 15:25:45 2013 -0700 @@ -1,4 +1,7 @@ -#!/bin/sh +#!/bin/zsh + +setopt shwordsplit +SHUNIT_PARENT=$0

    test_dir=$(dirname $0) source "$test_dir/setup.sh"

    The change above just makes sure that the Z shell is used to execute the tests.

    Let me know if there's anything I can do to help you reproduce the bug or if something is unclear.

  3. croach reporter
    • changed status to open

    Reopened this issue since it is still occurs in the current version. See the latest comment for details on recreating the bug.

  4. croach reporter

    Hi Doug,

    So, I've now tested it on the following systems and I still get the same error:

    • OS X 10.7.5 with zsh 4.3.11
    • OS X 10.8.3 with zsh 4.3.11
    • Ubuntu 12.04 with zsh 4.3.17

    I've also created a short video demonstrating the error on Ubuntu and showing the failing test if that helps. You can find the video here: https://www.youtube.com/watch?v=lqBR8yaM6s8.

    One thing I would like to point out though, is that the actual change to the cdproject function is very simple and should make the code safer for any shell since it basically just wraps the directory path in a set of double quotes. So, it shouldn't break anything, and if anything, it should make the code a bit more robust.

    Anyway, hope that helps out, let me know if you're still running into any problems reproducing the error.

  5. Doug Hellmann repo owner

    The change is, indeed small. I don't mind taking the patch. But I do want to understand why you are the only person who has this problem. I cannot reproduce the test failure, even using your updated version of the test. I don't get any error, and the output with "set -x" seems to show the shell changing directory to the project dir. As I don't use zsh, I don't have any customizations in place. Is it possible that some setting you have in your customization file is causing a change in behavior that exposes the bug for you, but not for me? If so, I would like to include that information in the documentation for the changeset.

  6. Log in to comment