fix(venv): make relocatable activation scripts support ksh #5640
Conversation
|
Can you note why ksh is important to support in particular? There are a lot of shells out there. Are we going to support all of them? |
I agree that trying to support all of them is futile. The Korn shell in particular is very much entrenched in a lot of enterprise environments at least. Not sure about zsh -- I recall ohmyzsh being trendy some years ago... never used it much myself. I personally do not object to excluding it, but others might? |
|
I think Zsh is very important, I believe it's the default on macOS. |
|
I'm fine with this as it's only used for |
Yes. I will actually go back and drop the sourced'ness checks for all except bash (which is what currently exists). I am testing them right now and are really brittle stuff -- would not want them to impact real users. |
It transpires that detecting the directory a script was sourced from is non-trivial across `bash`, `ksh` and `zsh`. The previous version was a one-liner and supported `bash` and `zsh` but not `ksh`. It is possible to keep the one-liner and add `ksh` support, but that is mutually-exclusive with `zsh`. Therefore, the only way to square this circle is to add an `if` block. A silver lining here is that although longer, the script is probably easier to follow as there is less code-golfing going on.
|
Phew, that was not fun. Tested (by hand) across bash, ksh and zsh. So far so good. zsh in particular is where the |
|
I guess my qualm with ksh (and curiosity as to why it is important) is that it's not included in our existing I presume it's present in enterprise because of red hat? |
That is a fair concern. I had a brief look at the module and it doesn't look terribly complicated (save for
The correlation is rather uncanny indeed. Although I would not be surprised if that the affinity for |
|
Ok @zanieb it turns out it was a fairly trivial addition considering there's already a pattern of supporting multiple POSIX shells with largely the same code. |
charliermarsh
added
the
compatibility
|
Thank you. This seems reasonable to me, especially now that we added Ksh to our shell enum. |
It transpires that detecting the directory a script was sourced from is non-trivial across
bash,kshandzsh.The previous version was a one-liner and supported
bashandzshbut notksh.It is possible to keep the one-liner and add
kshsupport, but that is mutually-exclusive withzsh.Therefore, the only way to square this circle is to add an
ifblock. A silver lining here is that although longer, the script is probably easier to follow as there is less code-golfing going on.© 2024 Morgan Stanley.
THIS SOFTWARE IS CONTRIBUTED SUBJECT TO THE TERMS OF THE APACHE LICENSE V.2.0 AND THE MIT LICENSE.
THIS SOFTWARE IS LICENSED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THIS SOFTWARE MAY BE REDISTRIBUTED TO OTHERS ONLY BY EFFECTIVELY USING THIS OR ANOTHER EQUIVALENT DISCLAIMER IN ADDITION TO ANY OTHER REQUIRED LICENSE TERMS.