Issues

Issue #130 resolved

Issues sourcing virtualenvwrapper.sh in OpenBSD ksh

dspruell
created an issue

{{{ virtualenvwrapper 3.0.1 Python 2.7.1 OpenBSD/i386 5.0 }}}

{{{ $ echo $KSH_VERSION @(#)PD KSH v5.2.14 99/07/13.2 }}}

Have run into a couple of issues using virtualenvwrapper under ksh included in OpenBSD (standard shell at /bin/ksh, based on pdksh but heavily modified and maintained by project).

http://www.openbsd.org/cgi-bin/man.cgi?query=ksh

:: No 'source' builtin

The 'source' builtin isn't implemented. Sourcing virtualenvwrapper.sh works instead with the '.' builtin:

{{{ . /usr/local/bin/virtualenvwrapper.sh }}}

This is also portable to Bash (tested and documented for v4.2.10) and Zsh (tested and documented for v4.3.12).

:: Failures sourcing virtualenvwrapper.sh

When sourcing virtualenvwrapper.sh in this ksh, syntax failures occur in the array setup code:

{{{ $ . /usr/local/bin/virtualenvwrapper.sh ksh: /usr/local/bin/virtualenvwrapper.sh[180]: syntax error: `(' unexpected }}}

The ( ) syntax is not supported. I'm not sure what would be portable across all the shells. The 'set' builtin provides for array initialization.

{{{ set -A name val1 valN ... }}}

The above syntax appears to be supported in Zsh too but not in Bash.

Possible to enable support?

Comments (3)

  1. Doug Hellmann repo owner
    • changed status to open

    I test using the ksh from OS X.

    $ echo ${.sh.version}
    Version M 1993-12-28 s+
    $ source `which virtualenvwrapper.sh`
    $
    

    It looks like OS X actually uses an older version than OpenBSD (or possibly it's another shell pretending to be ksh). I'm not sure how widely used the version of ksh from OpenBSD is, so I'm not predisposed to spend a lot of effort on a port that would increase the difficulty of supporting more modern shells.

    If you change the array setup code, does anything else break?

  2. dspruell reporter

    Yes, I think. Changed 2 instances of 'source' to '.' and 13 '( )' array declarations to 'set -A' and a couple of other goodies pop up pretty immediately:

    # at login...
    virtualenvwrapper_run_hook: /tmp/virtualenvwrapper-initialize-hook-M6TkOuMufS[6]: source: not found
    
    $ workon                                                                                                 
    [1] 15749
    getopts
    [1] + Done                 command -v "getopts"
    

    As the array changes aren't portable anyway that doesn't seem critical.

    At any rate, I'm happy to let this go and can invoke bash when needed. I sense that this is a non-trivial portability issue. :)

  3. Log in to comment