[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635826#comment-17635826
]
Stefan Miklosovic edited comment on CASSANDRA-17832 at 11/18/22 11:49 AM:
--------------------------------------------------------------------------
For the record, I spent a little bit more time on this and what I noticed is
that if you take a look into bin/cqlsh, it is invoking python3 directly, here
(1,2). What that does is that it will iterate over "python3" and "python"
binaries and whatever command it finds and its version is greater than 3.6, it
will start it.
If you do a simple test by changing shebang in bin/cqlsh.py to "#!/usr/bin/env
python5" and you try to start bin/cqlsh, it will start it, because it will try
to run that python3 it found in shell script.
On the other hand, if you execute bin/cqlsh.py directly, without shell wrapper,
it will error out on python5 not found.
So, in a nutshell, this is effectively used only in case a user tries to
execute bin/cqlsh.py directly, which I would say is not going to happen in
practice at all. If cqlsh is invoked via shell, people can even specify their
own versions of Python to run that cqlsh.py with so it completely bypasses the
shebang.
If we accept this, I am ok. But ideally we might probably get what /usr/bin/env
python3 is resolving in that shell cqlsh script and we use that binary to parse
the version of. Because now it just uses "python3" wherever it is, not honoring
env et all.
Actually, the documentation of env command here (3) says (sectin 23.2.2):
_When a script’s interpreter is in a non-standard location in the PATH
environment variable, it is recommended to use env on the first line of the
script to find the executable and run it:_
So if I have my python3 in my PATH variable, it will try to use that one first,
presumably. But we are not doing the same thing in shell bin/cqlsh, do we? I
would like to know what python3 we are going to use, what interpreter is going
to be used in (1), when I have python3 in my PATH. Ideally it should use that
one, same as it will do by doing it by "env".
(1) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L80
(2) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L93
(3)
https://www.gnu.org/software/coreutils/manual/html_node/env-invocation.html#env-invocation
was (Author: smiklosovic):
For the record, I spent a little bit more time on this and what I noticed is
that if you take a look into bin/cqlsh, it is invoking python3 directly, here
(1,2). What that does is that it will iterate over "python3" and "python"
binaries and whatever command it finds and its version is greater than 3.6, it
will start it.
If you do a simple test by changing shebang in bin/cqlsh.py to "#!/usr/bin/env
python5" and you try to start bin/cqlsh, it will start it, because it will try
to run that python3 it found in shell script.
On the other hand, if you execute bin/cqlsh.py directly, without shell wrapper,
it will error out on python5 not found.
So, in a nutshell, this is effectively used only in case a user tries to
execute bin/cqlsh.py directly, which I would say is not going to happen in
practice at all. If cqlsh is invoked via shell, people can even specify their
own versions of Python to run that cqlsh.py with so it completely bypasses the
shebang.
If we accept this, I am ok. But ideally we might probably get what /usr/bin/env
python3 is resolving in that shell cqlsh script and we use that binary to parse
the version of. Because now it just uses "python3" wherever it is, not honoring
env et all.
(1) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L80
(2) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L93
> Change bin/cqlsh.py shebang to use PATH with env prefix
> -------------------------------------------------------
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
> Reporter: Brad Schoening
> Assignee: Brad Schoening
> Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
