/usr/bin/env: python: No such file or directory
ddidierd78
I am running redhat 7.2 and installed the following:
python2.2-2.2b1-2.i386.rpm
python2.2-devel-2.2b1-2.i386.rpm
python2.2-tools-2.2b1-2.i386.rpm
When trying to run a script, I get the following message:
/usr/bin/env: python: No such file or directory
additionally the only thing relating to python in /usr/bin is the file
python2.2
Thanks for any help,
Dan
Erik Max Francis
> When trying to run a script, I get the following message:
>
> /usr/bin/env: python: No such file or directory
>
> additionally the only thing relating to python in /usr/bin is the file
> python2.2
Where did you install Python? /usr/bin/env isn't perfect, it can only
search a limited PATH for executables.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Laws are silent in time of war.
\__/ Cicero
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Fernando Pérez
the problem is Rhat installs python1.5 as python and python2.x as python2. So
you need to symlink python2.x to python in /usr/bin.
cheers,
f
Carl D. Roth
d> Hi, I am running redhat 7.2 and installed the following:
d> python2.2-2.2b1-2.i386.rpm python2.2-devel-2.2b1-2.i386.rpm
d> python2.2-tools-2.2b1-2.i386.rpm
d> When trying to run a script, I get the following message:
d> /usr/bin/env: python: No such file or directory
The stock redhat configuration uses python 1.5 as 'python'. If you
can't find it, you should check to make sure your python package is
still OK. Don't uninstall it, because it works alongside the python2
packages. Your system administration tools that come with RHL
probably do *not* work with python 2.
If you want to run python 2 instead of python 1.5 on that system,
change the 'env' line to refer to 'python2' or 'python2.2'.
-- C
Hamish Lawson
>
> /usr/bin/env: python: No such file or directory
Though perhaps not the case here, I'll just mention a problem that is
worth being aware of when transferring a script from a Windows/DOS
system to Unix. If the difference in line-ending conventions hasn't
been taken care of (such as by using ASCII mode during FTP transfer),
then the spurious ^M in the script's #! line can trip up the shell or
the env command, since it will be trying to run the program python^M.
Hamish Lawson
Steve Holden
It would be safer to modify your scripts to make the shebang line read
#!/usr/bin/env python2
to avoid possible breakage in the Red Hat anaconda adminstration suite. You
will need to create a symbolic link (/usr/bin/python2 --> python2.2) before
the shebang line will work correctly. Or you could just use
#!/usr/bin/env python2.2
but that might be a bit version-specific...
regards
Steve
--
http://www.holdenweb.com/
John W. Baxter
<fper...@yahoo.com> wrote:
Doing which, a few weeks ago and with a 2.2 alpha and RH 7.1, caused
printing to stop working due to an expected module not being in the 2.2
alpha (which one...I don't know).
I fixed that by pointing the python link back to 1.5.2. Then I
upgraded to RH 7.2 and lost printing again (but not for as long as
before...the fix was different and more obvious).
--John
Fernando Pérez
>
> Doing which, a few weeks ago and with a 2.2 alpha and RH 7.1, caused
> printing to stop working due to an expected module not being in the 2.2
> alpha (which one...I don't know).
>
Right. Just discovered that yesterday: I also broke printing!
At this point I'm fully willing to say that RedHat has simply put out a
broken python setup. I fail to see one good reason for the current mess, with
system-level things (like printing) needing python 1.5 to be the default and
be called python.
It is NOT practical to expect users to write their scripts using
#!/usr/bin/env python2, simply because that's a weird, redhat only default
that breaks everywhere else. And what of code they download? Now they have to
manually inspect every script they get from the web to replace
python->python2? That's plain moronic.
If redhat is too lazy to upgrade their code in anaconda and other tools to
use python2, at least they could have the courtesy of putting explicitly
python1.5 calls in their OWN stuff, instead of forcing upon their users a
broken convention.
I normally use mandrake (had been away from redhat for years) and only last
week was forced to deal with redhat again. What an ugly, messy excuse for a
linux distribution.
cheers,
f
Erik Max Francis
> Right. Just discovered that yesterday: I also broke printing!
>
> At this point I'm fully willing to say that RedHat has simply put out
> a
> broken python setup. I fail to see one good reason for the current
> mess, with
> system-level things (like printing) needing python 1.5 to be the
> default and
> be called python.
It wouldn't be too surprising. Red Hat seems to be fond of shipping
custom versions of everything, to the point that some are totally
unofficial or downright broken. Take the gcc 2.96 fiasco, for instance.
Donn Cave
...
| If redhat is too lazy to upgrade their code in anaconda and other tools to
| use python2, at least they could have the courtesy of putting explicitly
| python1.5 calls in their OWN stuff, instead of forcing upon their users a
| broken convention.
|
| I normally use mandrake (had been away from redhat for years) and only last
| week was forced to deal with redhat again. What an ugly, messy excuse for a
| linux distribution.
Does mandrake use Python for system software?
The last big go-round on this, the upshot as I recall it was that any
Python software had better be released with a dedicated interpreter.
More or less like what you propose.
It's too bad it has to be that way. On one hand, it's unrealistic to
expect all developers to foresee this problem, and on the other it
seems pretty expensive for small to medium projects - maybe Redhat can
afford to tuck away 10Mb of their own python for their system software,
but even for them it's probably not exactly a selling point for Python.
I have never used Redhat Linux, but I would have to give them credit
for deploying Python software, and blame the Python community as much
as Redhat for the problem. -- Why won't Redhat upgrade their software?
-- To what version? Assuming it takes some time, and they start with the
official 2.x release, when they're finally shipping the upgraded software,
will 2.x even still be current, or at least capable of running recently
written Python software? What a thankless task!
Donn Cave, do...@u.washington.edu
Michael Hudson
> It is NOT practical to expect users to write their scripts using
> #!/usr/bin/env python2, simply because that's a weird, redhat only
> default that breaks everywhere else. And what of code they download?
> Now they have to manually inspect every script they get from the web
> to replace python->python2? That's plain moronic.
No, those scripts should use distutils, which will get it right when
it installs them.
$ python2 setup.py install --prefix=$HOME
Everyone should use distutils. All the time.
Cheers,
M.
--
> Why are we talking about bricks and concrete in a lisp newsgroup?
After long experiment it was found preferable to talking about why
Lisp is slower than C++...
-- Duane Rettig & Tim Bradshaw, comp.lang.lisp
Trond Eivind Glomsrød
> Quoth Fernando P rez <fper...@yahoo.com>:
>
> | If redhat is too lazy to upgrade their code in anaconda and other
> | tools to use python2, at least they could have the courtesy of
> | putting explicitly python1.5 calls in their OWN stuff, instead of
> | forcing upon their users a broken convention.
> |
> | I normally use mandrake (had been away from redhat for years) and
> | only last week was forced to deal with redhat again. What an ugly,
> | messy excuse for a linux distribution.
>
> Does mandrake use Python for system software?
They use perl. Somehow, that didn't surprise me ;).
> It's too bad it has to be that way. On one hand, it's unrealistic to
> expect all developers to foresee this problem, and on the other it
> seems pretty expensive for small to medium projects - maybe Redhat can
> afford to tuck away 10Mb of their own python for their system software,
> but even for them it's probably not exactly a selling point for Python.
Well, we have pretty good control over which python we use in the
installer and in the distribution...
> Why won't Redhat upgrade their software?
Compatiblity. Programs for RHL 7 should run just fine on 7.2 as well.
When we start a new series, we will upgrade to the newest python
available at the time, port the software using python to that and
stick with this release for that series of Red Hat Linux releases.
--
Trond Eivind Glomsrød
Red Hat, Inc.
Trond Eivind Glomsrød
> Fernando Pérez wrote:
>
> > Right. Just discovered that yesterday: I also broke printing!
> >
> > At this point I'm fully willing to say that RedHat has simply put out
> > a
> > broken python setup. I fail to see one good reason for the current
> > mess, with
> > system-level things (like printing) needing python 1.5 to be the
> > default and
> > be called python.
>
> It wouldn't be too surprising. Red Hat seems to be fond of shipping
> custom versions of everything, to the point that some are totally
> unofficial or downright broken. Take the gcc 2.96 fiasco, for instance.
Having the best compiler for a year and a half can hardly be called a
fiasco for us - it is a problem that there were no decent official
releases to ship, though.
Fernando Pérez
> Fernando Pérez <fper...@yahoo.com> writes:
>
>> It is NOT practical to expect users to write their scripts using
>> #!/usr/bin/env python2, simply because that's a weird, redhat only
>> default that breaks everywhere else. And what of code they download?
>> Now they have to manually inspect every script they get from the web
>> to replace python->python2? That's plain moronic.
>
> No, those scripts should use distutils, which will get it right when
> it installs them.
>
> $ python2 setup.py install --prefix=$HOME
>
> Everyone should use distutils. All the time.
>
> Cheers,
> M.
>
Well, not if it's a single script not intended as a package. It often happens
that you find something useful on the web which is a stand-alone script. The
widely accepted convention is that #!/usr/bin/env python will 'do the right
thing' but unfortunately redhat breaks that. That's my beef.
f.
Fernando Pérez
>> Why won't Redhat upgrade their software?
>
> Compatiblity. Programs for RHL 7 should run just fine on 7.2 as well.
>
> When we start a new series, we will upgrade to the newest python
> available at the time, port the software using python to that and
> stick with this release for that series of Red Hat Linux releases.
>
I see someone from RH is listening, so let me ask again, and apologies for
any inflammatory language in my first post. But the issue made me waste so
many hours this past week that I wasn't in a particularly good mood about it.
I understand you compatibility issues. On the other hand, I'm sure you
realize you are breaking an extremely widely used convention by installing
the currently standard series of python as /usr/bin/python2, since that means
the idiom '#!/usr/bin/env python' won't work for many people, and it will be
particularly suprising to those who assumed they had installed Python 2.x. I
know, they can always go and fix all their scripts, but that puts an undue
burden on the user, it seems to me.
I see a few options for RedHat to do things 'right' for your users in terms
of providing a saner python environment without breaking your own internal
setup:
1) Upgrade your internal anaconda and other system code to work with Python
2.x, *without requiring it*. This way you could ship 7.2 with python 2.x as
the default python and the same programs would still run under python 1.x in
older redhat releases. This shouldn't be too hard at all, since almost all of
python 1.5 code runs unchanged under 2.x. In fact I suspect the code may
actually work already, once the support packages are copied to the right
place (haven't had time to try). If that's the case, it is a real shame that
you put pyhton1.5 as the system default without any real techical
justification.
or
2) Change *only* the first line in your system python scripts to explicitly
point to /usr/bin/python1.5. I don't know if this would change anything with
respect to your older releases, but the code itself wouldn't be affected.
Again, this would allow python 2.x to be the default at /usr/bin/python with
absolutely minor changes to all your system scripts. And if someone is going
to install system 7.2 scripts on a 7.1 machine, as bizarre as that sounds, a
simple fix would be for them to link python1.5 to python.
These seem to be perfectly reasonable solutions, while the current setup
leaves the users in a particularly unpleasant situation: any code you run
with '#!/usr/bin/env python' will trigger a call to python1.5, which may
cause it not to run (if it needs python2 features), but you can't change the
system default without breaking fundamental functionality.
So could you explain to us why RedHat chose not to allow their users to use
python2 as the standard system default, even though as I pointed, there are
very reasonable ways of maintaining compatibility for your own scripts?
Regards,
F.
Fredrik Lundh
> Having the best compiler for a year and a half can hardly be called a
> fiasco for us
maybe not for you, but it was rather annoying for us Python
developers...
Python 2.0b2 (#2, Sep 27 2000, 11:40:58)
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: integer multiplication
(next time you release a brand new C compiler, try compiling the
latest Python interpreter *before* the release ;-)
</F>
Erik Max Francis
> Having the best compiler for a year and a half can hardly be called a
> fiasco for us - it is a problem that there were no decent official
> releases to ship, though.
So good, in fact, that it prompted an immediate press release from the
GCC team that it was a development version, was never intended as an
official release, and a recommendation not to use it.
http://gcc.gnu.org/gcc-2.96.html
Note that additionally, the ABI in 2.96 was different than in _both_
2.95.x and 3.x. That's what one gets for releasing a development
snapshot as if it were a true release.
Paul Boddie
This may well be the case, in fact. One solution is to write a short
Python script to replace the DOS line endings with the native
equivalent. Something like this, perhaps:
# Warning! Untested! Try it on something you've already backed up!
s = open(filename, "rb").read()
# NOTE: Python 2 string methods used - import string and use
# NOTE: string.replace with earlier releases of Python.
s = s.replace("\r\n", "\n")
open(filename, "w").write(s)
Yes, I know it could have been done on one line (or using 'sed')! :-)
Paul
Chris Barker
> If you want to run python 2 instead of python 1.5 on that system,
> change the 'env' line to refer to 'python2' or 'python2.2'.
This an discussion that came and went as part of one of the discusions
about an incompatable change to Python.
Frankly, while you can certainly start chaning the #! line to point to
the version you need on *nix, that won't help with other OSs. Some folks
suggested a *.py2 extension for Windows, which might work.
Personally, I'd love to see a native Python solution this problem: some
sort of version keyword that would specify what version was required,
and ideally, whatever was in the $PATH called "python" would look for
that keyword, and dispatch the script off to whatever was required. This
would be an all OS solution. On a given system, it would probably be
best if it was not required that al versions actually be installed, but
an error mesage that siad something about a version mismatch would be a
whole lot more useful that just having the scrip tfail in some wierd
way.
It's too late for any solution of this nature to resolve 1.5.* vs 2.*
problems, but at least we could solve this for the future. I'm sure
others on this list could come up with better ideas thatn mine, but I'm
convinced that there really needs to be a Python solution to this
problem, rather than tossing it of to the admistrators of every system
out there!
-Chris
--
Christopher Barker,
Ph.D.
ChrisH...@attbi.net --- --- ---
---@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------
Quinn Dunkan
>Fernando Pérez <fper...@yahoo.com> writes:
>
>> It is NOT practical to expect users to write their scripts using
>> #!/usr/bin/env python2, simply because that's a weird, redhat only
>> default that breaks everywhere else. And what of code they download?
>> Now they have to manually inspect every script they get from the web
>> to replace python->python2? That's plain moronic.
>
>No, those scripts should use distutils, which will get it right when
>it installs them.
>
>$ python2 setup.py install --prefix=$HOME
>
>Everyone should use distutils. All the time.
It seems to me like a move from "install with cp" to "install with this
complicated system that gropes around your system, mangles the files, etc. and
then does cp" is a step backwards.
I don't know how much time I've wasted fighting with too-clever install
scripts, broken Makefile-mazes that want to rebuild the world every time, GNU
configure picking broken settings, setup.py deciding to start using
'gcc -shared' to make shared objects on SunOS when only 'gcc -G' works and
what do you edit to change that, and programs which generate perl scripts
which generate imakefiles which generate makefiles which generate shell
scripts which sed out a bunch of magic tokens in configuration files, which
then breaks, etc. etc. when all I really needed was 'cc -c *.c -o program;
cp program /usr/local/bin'. Now, of course, this ideal is naive in a world of
13 flavors of unix misimplementing broken POSIX functions in different ways
and compilers with two pages of command line flags and mazes of shared
libraries. But that's the C world.
The way I see it, people should use distutils when they have to, but use plain
/bin/cp when they can. I mean no disrespect to the distutils developers, I'm
sure it's quite handy when you want to build dynamically loaded C extensions
that rely on a few random shared libraries that may or may not have the right
functions and who knows where the system is hiding them, etc.
Besides, what if distutils goes and changes all your shebangs to python2 but
your python scripts are network mounted?
Paul Boddie
>
> I don't know how much time I've wasted fighting with too-clever install
> scripts, broken Makefile-mazes that want to rebuild the world every time, GNU
> configure picking broken settings, setup.py deciding to start using
> 'gcc -shared' to make shared objects on SunOS when only 'gcc -G' works and
> what do you edit to change that, and programs which generate perl scripts
> which generate imakefiles which generate makefiles which generate shell
> scripts which sed out a bunch of magic tokens in configuration files, which
> then breaks, etc. etc. when all I really needed was 'cc -c *.c -o program;
> cp program /usr/local/bin'.
This kind of reminds me of all those projects which use automake
instead of autoconf, or at least I assume they use automake, because
instead of pertinent questions being asked in the configure script,
you get hundreds of checks being run for no obviously good reason:
Checking for maiden name of aunt... Jenkins
From what I've seen of distutils, it does seem to do a reasonably good
job, and it certainly seems a lot more workable than the old
Makefile.pre.in/Setup thing (which, in turn, at least managed to do
the right thing most of the time, unlike certain parts of the KOffice
build process), but I haven't actually attempted to employ it in
anything I've written. Indeed, that's probably because I mostly stay
clear of writing C-level extensions. Perhaps the issue here is how to
get distutils to scale down so that it's trivial to use - even for
pure Python projects.
Having written the above, I now anticipate an example of distutils'
triviality... ;-)
Paul
Michael Hudson
> Having written the above, I now anticipate an example of distutils'
> triviality... ;-)
from distutils.core import setup
setup(scripts=['script.py'])
I think. It's nice to include author_email & things, but that should
suffice.
I agree distutils is a bit overkill for demonstration scripts & such,
but I can't really conceive of a better system.
Cheers,
M.
Chris Barker
> Though perhaps not the case here, I'll just mention a problem that is
> worth being aware of when transferring a script from a Windows/DOS
> system to Unix. If the difference in line-ending conventions hasn't
> been taken care of (such as by using ASCII mode during FTP transfer),
> then the spurious ^M in the script's #! line can trip up the shell or
> the env command, since it will be trying to run the program python^M.
This is a "moving stuff from Windows to *nix" issue, and has NOTHING to
do with Python in particular. As stated, it is the shell (is it the
shell? or is it something lower in the system...I have no idea) that is
examining that first #! line, so we havn't gotten anywhere near Python
yet.
We really do need to find a Python solution to distinguishing different
Python versions, however. Python has now gotten mature enough, and
established enough that there are a lot of programs out there that work
just fine with a current version, and users should not have to do
anything to keep them working...It should be hard to break an existing
settup when you upgrade Python, not hard to preserve it!
I suppose, if we all, as a community, start using:
#!/use/bin/env python2.1
Then the problem will be solved, at least on *nix...
Then what do you do with a script that will run on either 1.5 or 2.0 or
2.1 ????? and you don't know which of these might be installed?
Cliff Wells
Chris Barker <chrish...@attbi.com> wrote:
> I suppose, if we all, as a community, start using:
>
> #!/use/bin/env python2.1
>
> Then the problem will be solved, at least on *nix...
>
> Then what do you do with a script that will run on either 1.5 or 2.0 or
> 2.1 ????? and you don't know which of these might be installed?
>
It seems reasonable that if your script requires a particular version of Python to append the version to the executable name (i.e. python2.1), and if your script doesn't care, then just use "python" which could be a symbolic link to the default python interpreter (much as redhat has it now). It might be helpful if the python interpreter took a flag such as --required-version or --minimum-version so that a warning could be printed if the script requires a version different than what is available on the system.
--
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308
Chris Barker
> On Thu, 20 Dec 2001 10:16:54 -0800
> Chris Barker <chrish...@attbi.com> wrote:
>
> > I suppose, if we all, as a community, start using:
> >
> > #!/use/bin/env python2.1
> >
> > Then the problem will be solved, at least on *nix...
> >
> > Then what do you do with a script that will run on either 1.5 or 2.0 or
> > 2.1 ????? and you don't know which of these might be installed?
> It seems reasonable that if your script requires a particular version of Python to append the version to the executable name (i.e. python2.1),
There are two problems here:
1) This would only work if we all, as a community, established this
convention. So far I have only seem "python" used, for all versions...
2) It only applies to *nix. Windows and the Macintosh would need
different conventions. I think a platform independent Python based
solution is a better way to go.
>> and if your script doesn't care, then just use "python" which could be a symbolic link to the >> default python interpreter (much as redhat has it
>> now).
The problem with what RedHat has now is that apparently some of the
scripts DO care! even though now it is not too hard to write code that
will run on version 1.5 - 2.2, eventually we will be at Python 4.*, and
you may be very hard pressed to write code that doesn't care, but you
may be able to write code that works on 2.2 - 3,5 , for instance. Also
while you may write a script now that "doesn't care", when Python 3
comes out with some new incompatability, it will then care, but the
"python" will still be there.
>> It might be helpful if the python interpreter took a flag such as
>> --required-version or >> --minimum-version so that a warning could
>> be printed if the script requires a version different than what is
>> available on the system.
How would the interpreter know what version was required? That's exactly
what I think we need...A way to tell the interpreter what version is
required by a script.
Cliff Wells
Chris Barker <chrish...@attbi.com> wrote:
> There are two problems here:
>
> 1) This would only work if we all, as a community, established this
> convention. So far I have only seem "python" used, for all versions...
Very true.
> 2) It only applies to *nix. Windows and the Macintosh would need
> different conventions. I think a platform independent Python based
> solution is a better way to go.
I don't disagree.
[snip]
>
> >> It might be helpful if the python interpreter took a flag such as
> >> --required-version or >> --minimum-version so that a warning could
> >> be printed if the script requires a version different than what is
> >> available on the system.
>
> How would the interpreter know what version was required? That's exactly
> what I think we need...A way to tell the interpreter what version is
> required by a script.
That is what the flags would be for: to tell the interpreter what version/minimum version is required. Of course, since only Unix supports shebang scripts (does Mac OS X ? It is Unix, isn't it? Sort of?) this wouldn't be much help on other platforms.
How about #pragma directives? =)
Regards,
Thomas Bellman
> How would the interpreter know what version was required? That's exactly
> what I think we need...A way to tell the interpreter what version is
> required by a script.
So, your script requires Python version 2.5 to run, but won't run on
2.4 or 2.6. But is that version 2.5 of the language specification, or
is that version 2.5 of Guido's Python interpreter (which implements
version 2.4 of the language spec)? Or is it perhaps version 2.5 of
the Jython interpreter (which implements some features from version
2.6 of the language spec, but misses some features that came back in
version 2.3)?
Well, assume that we could resolve that. But your script also
requires PIL of a version between 2.718 and 3.142; except versions
3.000 through 3.013, which inadvertently broke compatibility in
some obscure corner which you were using.
And it also wants to talk to an Informix database. Version 9, but
version 10 won't do. Some versions of Oracle or PostgreSQL might
also work well...
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"Adde parvum parvo magnus acervus erit" ! bellman @ lysator.liu.se
(From The Mythical Man-Month) ! Make Love -- Nicht Wahr!
Hernan M. Foffani
> > what I think we need...A way to tell the interpreter what version is
> > required by a script.
>
> So, your script requires Python version 2.5 to run, but won't run on
> 2.4 or 2.6. But is that version 2.5 of the language specification, or
> is that version 2.5 of Guido's Python interpreter (which implements
> version 2.4 of the language spec)?
The simplest way to do is to pack your own interpreter and put it in some
deep-down directory. Think on Zope! If they do it (and they pay python
devs salaries :)) I won't go upstream.
Actually RH should provide 2 python interpreters. The one that would be
installed in a special dir along with the bunch of scripts they need
and the one that goes with the devs package or whatever RH like to
name it.
Yes. We may end with a dozen of Python's interpreters in the hard-drive.
But, so what? :)
Regards,
-Hernan
nbe...@fred.net
#!/usr/bin/python1.5
I proposed that to them before and they rejected it.
Trond Eivind Glomsrød
> The correct solution is for Redhat to put:
> #!/usr/bin/python1.5
The scripts don't depend on Python 1.5 - they depend on having certain
modules available, with the same functionality as they were developed
on.
Chris Gonnerman
From: "Trond Eivind Glomsrød" <t...@redhat.com>
> nbe...@fred.net writes:
>
> > The correct solution is for Redhat to put:
> > #!/usr/bin/python1.5
>
> The scripts don't depend on Python 1.5 - they depend on having
> certain modules available, with the same functionality as they
> were developed on.
True, but irrelevant.
If Red Hat did as nbe...@fred.net suggested, this would solve the
problem with incompatible Python installs, assuming only that the
system admin did not remove the 1.5 stuff before installing 2.x.
The fact that the statement
#!/usr/bin/python1.5
at the top of the script does not SAY "certain modules" must be
available does not change the fact that it would work fine.
Another option would be to put
#!/usr/bin/redhat-python
at the top of the script (creating the correct link in the process)
to make the purpose more transparent.
Aloysius Toh
<nbe...@fred.net> wrote in message news:m3ellko...@nbecker.fred.net...
nbe...@fred.net
Aloysius> Redhat 7.2 has both 1.5 and 2.1
Yes. Since RedHat scripts require 1.5, they should say so
explicitly. This would enable you to install 2.1 or 2.2 or whatever
you like without conflicts.
Aloysius Toh
<nbe...@fred.net> wrote in message news:m3ellko...@nbecker.fred.net...
> The correct solution is for Redhat to put:
> #!/usr/bin/python1.5
>
> I proposed that to them before and they rejected it.
========= WAS CANCELLED BY =======:
Path: news.sol.net!spool1-nwblwi.newsops.execpc.com!newsfeeds.sol.net!news-out.visi.com!hermes.visi.com!upp1.onvoy!onvoy.com!nntp1.phx1.gblx.net!nntp.gblx.net!nntp.gblx.net!enews.sgi.com!news-xfer.nuri.net!feeder.kornet.net!news1.kornet.net!ua4canc3ll3r
From: "Aloysius Toh" <to...@ozemail.com.au>
Newsgroups: comp.lang.python
Subject: cmsg cancel <NCxX7.100785$li3.1...@ozemail.com.au>
Control: cancel <NCxX7.100785$li3.1...@ozemail.com.au>
Date: Mon, 31 Dec 2001 01:45:40 GMT
Organization: A poorly-installed InterNetNews site
Lines: 2
Message-ID: <cancel.NCxX7.100785$li3.1...@ozemail.com.au>
NNTP-Posting-Host: 211.57.49.2
X-Trace: news2.kornet.net 1009774385 27193 211.57.49.2 (31 Dec 2001 04:53:05 GMT)
X-Complaints-To: use...@news2.kornet.net
NNTP-Posting-Date: Mon, 31 Dec 2001 04:53:05 +0000 (UTC)
X-No-Archive: yes
X-Unac4ncel: yes
X-Commentary: I love NewsAgent 1.10 and the Sandblaster Cancel Engine Build 74 (19 March 1999)
This message was cancelled from within Mozilla.
nbe...@fred.net
========= WAS CANCELLED BY =======:
Path: news.sol.net!spool1-nwblwi.newsops.execpc.com!newsfeeds.sol.net!news-out.visi.com!hermes.visi.com!newsxfer.interpacket.net!news-xfer.nuri.net!feeder.kornet.net!news1.kornet.net!ua4canc3ll3r
From: nbe...@fred.net
Newsgroups: comp.lang.python
Subject: cmsg cancel <m3ofkgi...@nbecker.fred.net>
Control: cancel <m3ofkgi...@nbecker.fred.net>
Date: Mon, 31 Dec 2001 01:46:18 GMT
Organization: A poorly-installed InterNetNews site
Lines: 2
Message-ID: <cancel.m3o...@nbecker.fred.net>
NNTP-Posting-Host: 211.57.49.2
X-Trace: news2.kornet.net 1009774087 27193 211.57.49.2 (31 Dec 2001 04:48:07 GMT)
X-Complaints-To: use...@news2.kornet.net
NNTP-Posting-Date: Mon, 31 Dec 2001 04:48:07 +0000 (UTC)
Trond Eivind Glomsrød
> >>>>> "Aloysius" == Aloysius Toh <to...@ozemail.com.au> writes:
>
> Aloysius> Redhat 7.2 has both 1.5 and 2.1
>
> Yes. Since RedHat scripts require 1.5, they should say so
> explicitly.
It doesn't. If you have python 2.2 and newt installed, some scripts
will work. If you add the libglade, pygtk etc for it, even more will.
I doubt there is much version-specific python code.
Fernando Pérez
[snip]
>
I see someone from RH is listening, so let me ask again, and apologies for
any inflammatory language in my first post. But the issue made me waste so
many hours this past week that I wasn't in a particularly good mood about it.
I understand your compatibility issues. On the other hand, I'm sure you
realize you are breaking an extremely widely used convention by installing
the currently standard series of python as /usr/bin/python2, since that means
the idiom '#!/usr/bin/env python' won't work for many people, and it will be
particularly suprising to those who assumed they had installed Python 2.x. I
know, they can always go and fix all their scripts, but that puts an undue
burden on the user, it seems to me.
I see a few options for RedHat to do things 'right' for your users in terms
of providing a saner python environment without breaking your own internal
setup:
1) Upgrade your internal anaconda and other system code to work with Python
2.x, *without requiring it*. This way you could ship 7.2 with python 2.x as
the default python and the same programs would still run under python 1.x in
older redhat releases. This shouldn't be too hard at all, since almost all of
python 1.5 code runs unchanged under 2.x. In fact I suspect the code may
actually work already, once the support packages are copied to the right
place (haven't had time to try). If that's the case, it is a real shame that
you put pyhton1.5 as the system default without any real techical
justification.
or
2) Change only the first line in your system python scripts to explicitly
ToddW
> Trond Eivind Glomsrød wrote:
>
> > Having the best compiler for a year and a half can hardly be called a
> > fiasco for us - it is a problem that there were no decent official
> > releases to ship, though.
>
> So good, in fact, that it prompted an immediate press release from the
> GCC team that it was a development version, was never intended as an
> official release, and a recommendation not to use it.
>
> http://gcc.gnu.org/gcc-2.96.html
>
> Note that additionally, the ABI in 2.96 was different than in _both_
> 2.95.x and 3.x. That's what one gets for releasing a development
> snapshot as if it were a true release.
They over reacted. Plus lots of things break ABI from release to release,
including stable gcc releases. 2.96 was such a good decision. The C++
programmers especially sighed a big sigh of relief.
But, bero said it so much better: http://www.bero.org/gcc296.html
Scott David Daniels
> Cliff Wells wrote:
> How would the interpreter know what version was required? That's exactly
> what I think we need...A way to tell the interpreter what version is
> required by a script.
How about:
import sys
assert 0x2010000 < sys.hexversion < 0x2030000
at the top of the script (to insist on 2.1 or 2.2).
-Scott
Cliff Wells
dan...@developNET.com (Scott David Daniels) wrote:
> Chris Barker <chrish...@attbi.com> wrote in message
news:<3C225488...@attbi.com>...
> > Cliff Wells wrote:
> > How would the interpreter know what version was required? That's
exactly
> > what I think we need...A way to tell the interpreter what version is
> > required by a script.
um... Chris said that, not me (not that I disagree with his sentiment).