Merge pull request #27 from dhellmann/11-drop-ksh-support

drop ksh support

Author: mergify[bot]

README.txt

@@ -47,7 +47,7 @@ Supported Shells
 ================
 
 virtualenvwrapper is a set of shell *functions* defined in Bourne
-shell compatible syntax.  It is tested under ``bash``, ``ksh``, and
+shell compatible syntax.  It is tested under ``bash`` and
 ``zsh``.  It may work with other shells, so if you find that it does
 work with a shell not listed here please let us know by opening a
 `ticket on GitHub

docs/source/install.rst

@@ -12,14 +12,13 @@ shell compatible syntax.  Its automated tests run under these
 shells on OS X and Linux:
 
 * ``bash``
-* ``ksh``
 * ``zsh``
 
 It may work with other shells, so if you find that it does work with a
-shell not listed here please let me know.  If you can modify it to
+shell not listed here please let us know.  If you can modify it to
 work with another shell without completely rewriting it, then send a pull
 request through the `GitHub project page`_.  If you write a clone to
-work with an incompatible shell, let me know and I will link to it
+work with an incompatible shell, let us know and we will link to it
 from this page.
 
 .. _GitHub project page: https://GitHub.com/python-virtualenvwrapper/virtualenvwrapper/

docs/source/plugins.rst

@@ -80,7 +80,7 @@ techniques.
 
 The API is the same for every extension point.  Each uses a Python
 function that takes a single argument, a list of strings passed to the
-hook loader on the command line.  
+hook loader on the command line.
 
 ::
 
@@ -106,7 +106,7 @@ user scripts when ``virtualenvwrapper.sh`` is loaded.
     def initialize(args):
         for filename, comment in GLOBAL_HOOKS:
             make_hook(os.path.join('$WORKON_HOME', filename), comment)
-        return 
+        return
 
 .. _plugins-user-env:
 
@@ -150,13 +150,13 @@ shell process.
 .. warning::
 
     virtualenvwrapper works under several shells with slightly
-    different syntax (bash, sh, zsh, ksh).  Take this portability into
+    different syntax (bash, sh, zsh).  Take this portability into
     account when defining source hooks.  Sticking to the simplest
     possible syntax usually avoids problems, but there may be cases
     where examining the ``SHELL`` environment variable to generate
     different syntax for each case is the only way to achieve the
     desired result.
-    
+
 Registering Entry Points
 ------------------------
 
@@ -200,9 +200,9 @@ application, use the ``-m`` option to the interpreter::
 
   $ python -m virtualenvwrapper.hook_loader -h
   Usage: virtualenvwrapper.hook_loader [options] <hook> [<arguments>]
-  
+
   Manage hooks for virtualenvwrapper
-  
+
   Options:
     -h, --help            show this help message and exit
     -s, --source          Print the shell commands to be run in the current
@@ -213,7 +213,7 @@ application, use the ``-m`` option to the interpreter::
     -q, --quiet           Show less information on the console
     -n NAMES, --name=NAMES
                           Only run the hook from the named plugin
-  
+
 To run the extensions for the initialize hook::
 
   $ python -m virtualenvwrapper.hook_loader -v initialize
@@ -375,7 +375,7 @@ Plugins that define new operations can also define new extension
 points.  No setup needs to be done to allow the hook loader to find
 the extensions; documenting the names and adding calls to
 ``virtualenvwrapper_run_hook`` is sufficient to cause them to be
-invoked.  
+invoked.
 
 The hook loader assumes all extension point names start with
 ``virtualenvwrapper.`` and new plugins will want to use their own

tests/run_tests

@@ -61,7 +61,6 @@ do
     echo "  SHELL=$SHELL"
     echo "  BASH_VERSION=$BASH_VERSION"
     echo "  ZSH_VERSION=$ZSH_VERSION"
-    echo "  KSH_VERSION=$KSH_VERSION"
     echo "  virtualenv=$(which virtualenv)"
     echo "  test_shell_opts=$test_shell_opts"
     echo "  ZSH=$ZSH_NAME $ZSH_EVAL_CONTEXT"

tests/test_dir_stack.sh

@@ -29,7 +29,6 @@ tearDown() {
 }
 
 test_ticket_101 () {
-    [ ! -z "$KSH_VERSION" ] && echo "Skipping test under ksh"  && return 0
     mkvirtualenv some_env
     deactivate
     cd "$WORKON_HOME/start_here"

tox.ini

@@ -14,7 +14,6 @@ setenv =
 allowlist_externals =
     bash
     zsh
-    ksh
 
 [testenv:fast]
 setenv =
@@ -32,12 +31,6 @@ setenv =
   test_shell_opts = -o shwordsplit
 commands =  zsh -o shwordsplit ./tests/run_tests {envdir} []
 
-[testenv:ksh]
-basepython=python2.7
-setenv =
-  SHELL = /bin/ksh
-commands =  ksh ./tests/run_tests {envdir} []
-
 [testenv:docs]
 deps =
   -r{toxinidir}/requirements.txt

virtualenvwrapper.sh

@@ -121,20 +121,16 @@ fi
 # alias or even a shell function. Under bash and zsh, "builtin" forces
 # the use of a command that is part of the shell itself instead of an
 # alias, function, or external command, while "command" does something
-# similar but allows external commands. Under ksh "builtin" registers
-# a new command from a shared library, but "command" will pick up
-# existing builtin commands. We need to use a builtin for cd because
-# we are trying to change the state of the current shell, so we use
-# "builtin" for bash and zsh but "command" under ksh.
+# similar but allows external commands. We need to use a builtin for
+# cd because we are trying to change the state of the current shell,
+# so we use "builtin".
 function virtualenvwrapper_cd {
     if [ -n "${BASH:-}" ]
     then
         builtin \cd "$@"
     elif [ -n "${ZSH_VERSION:-}" ]
     then
         builtin \cd -q "$@"
-    else
-        command \cd "$@"
     fi
 }