On Thu, 23 Apr 2026 22:13:19 +0000, Lew Pitcher wrote:
When writing scripts for distribution, it seems to me to be common
sense to write those scripts in a manner such that they need as
little customization as possible. You cannot know all the quirks of
the environment in which it will run, but you can dictate some
minimum requirements for the script.
If, for instance, you write a Perl or Python script for distribution,
it must not, to be useful to the intended audience, assume much more
than the common components of the selected language; a Python 3 script
won't be much use on a system that only has Python 2 installed, unless
it restricts itself to the subset of Python 3 syntax and features that
are common with Python 2.
While there is, AFAIK, no "minimum subset" defined for Python or Perl ...
On Mon, 27 Apr 2026 06:19:09 -0000 (UTC), Lew Pitcher wrote:
If, for instance, you write a Perl or Python script for distribution,
it must not, to be useful to the intended audience, assume much more
than the common components of the selected language; a Python 3 script
won't be much use on a system that only has Python 2 installed, unless
it restricts itself to the subset of Python 3 syntax and features that
are common with Python 2.
I would not bother maintaining compatibility with any version of
either Perl or Python that no longer gets official support from
upstream.
For example, the last 2.x version of Python lost support over 6 years
ago. For Python 3, the oldest currently-maintained version is 3.10.
And going by past schedules, that will likely fall out of support
sometime around October this year.
On Thu, 23 Apr 2026 22:13:19 +0000, Lew Pitcher wrote:
On Thu, 23 Apr 2026 23:05:14 +0200, Carlos E.R. wrote:
[snip]
What is not right is declare in a script that it uses the common shell,
and then have bashisms inside.
Agreed. That's why my script does /not/ have bashisms inside.
It uses the (POSIX shell) common subset that ash, bash, dash, ksh,
and zsh all support.
When writing scripts for distribution, it seems to me to be
common sense to write those scripts in a manner such that they
need as little customization as possible. You cannot know all
the quirks of the environment in which it will run, but you can
dictate some minimum requirements for the script.
If, for instance, you write a Perl or Python script for distribution,
it must not, to be useful to the intended audience, assume much more
than the common components of the selected language; a Python 3 script
won't be much use on a system that only has Python 2 installed, unless
it restricts itself to the subset of Python 3 syntax and features that
are common with Python 2. Similarly, a bash script won't be of much use
on a system that only has Korn shell installed, if it uses features
only available in bash.
While some will argue against this, for their own reasons, I will
continue to distribute POSIX shell compatible scripts.
For what it's worth.
On 2026-04-27 10:12, Lawrence D’Oliveiro wrote:
On Mon, 27 Apr 2026 06:19:09 -0000 (UTC), Lew Pitcher wrote:
If, for instance, you write a Perl or Python script for
distribution, it must not, to be useful to the intended audience,
assume much more than the common components of the selected
language; a Python 3 script won't be much use on a system that only
has Python 2 installed, unless it restricts itself to the subset of
Python 3 syntax and features that are common with Python 2.
I would not bother maintaining compatibility with any version of
either Perl or Python that no longer gets official support from
upstream.
For example, the last 2.x version of Python lost support over 6 years
ago. For Python 3, the oldest currently-maintained version is 3.10.
And going by past schedules, that will likely fall out of support
sometime around October this year.
My system still has python 2 installed.
Scripts that I have seen do not specify versions, but they can.
#!/usr/bin/env python3
For example, the last 2.x version of Python lost support over 6 years
ago.
For Python 3, the oldest currently-maintained version is 3.10.
And going by past schedules, that will likely fall out of support
sometime around October this year.
My system still has python 2 installed.
Scripts that I have seen do not specify versions, but they can.
But they should. The well known planewave program abinit has a python
script to run the test programs. Unfortunately the hashbang just
specifies python. Actually the script needs python3. On a system (e.g. OpenSuse) where "python" by default is a symlink to python2, chaos
ensues,
with many obscure error messages till you realize what's happening. I
have been trying to get the abinitsters to change their hashbang, to no avail.
When writing scripts for distribution, it seems to me to be
common sense to write those scripts in a manner such that they
need as little customization as possible. You cannot know all
the quirks of the environment in which it will run, but you can
dictate some minimum requirements for the script.
If, for instance, you write a Perl or Python script for distribution,
it must not, to be useful to the intended audience, assume much more
than the common components of the selected language; a Python 3 script
won't be much use on a system that only has Python 2 installed, unless
it restricts itself to the subset of Python 3 syntax and features that
are common with Python 2. Similarly, a bash script won't be of much use
on a system that only has Korn shell installed, if it uses features
only available in bash.
Carlos E.R. wrote:
On 2026-04-27 10:12, Lawrence D’Oliveiro wrote:But they should. The well known planewave program abinit has a python
On Mon, 27 Apr 2026 06:19:09 -0000 (UTC), Lew Pitcher wrote:
If, for instance, you write a Perl or Python script for
distribution, it must not, to be useful to the intended audience,
assume much more than the common components of the selected
language; a Python 3 script won't be much use on a system that only
has Python 2 installed, unless it restricts itself to the subset of
Python 3 syntax and features that are common with Python 2.
I would not bother maintaining compatibility with any version of
either Perl or Python that no longer gets official support from
upstream.
For example, the last 2.x version of Python lost support over 6 years
ago. For Python 3, the oldest currently-maintained version is 3.10.
And going by past schedules, that will likely fall out of support
sometime around October this year.
My system still has python 2 installed.
Scripts that I have seen do not specify versions, but they can.
#!/usr/bin/env python3
script to run the test programs. Unfortunately the hashbang just
specifies python. Actually the script needs python3. On a system (e.g. OpenSuse) where "python" by default is a symlink to python2, chaos
ensues, with many obscure error messages till you realize what's
happening. I have been trying to get the abinitsters to change their hashbang, to no avail.
On Mon, 27 Apr 2026 12:42:38 +0200, Carlos E.R. wrote:
My system still has python 2 installed.
Scripts that I have seen do not specify versions, but they can.
Leap 16? Mine doesn't although you need to invoke it with python3 still.
Unfortunately the hashbang just specifies python. Actually the
script needs python3. On a system (e.g. OpenSuse) where "python" by
default is a symlink to python2, chaos ensues ...
I am trying to remember when I first used Unix.
For sure we were coding on a VAX VMS around 1986, which had Usenet.
On Mon, 27 Apr 2026 09:43:06 -0700, Ian wrote:
Unfortunately the hashbang just specifies python. Actually the
script needs python3. On a system (e.g. OpenSuse) where "python" by
default is a symlink to python2, chaos ensues ...
Yeah, some distros have repurposed “python” as a synonym for “python3”, others have not ...
On Mon, 27 Apr 2026 09:43:06 -0700, Ian wrote:
Unfortunately the hashbang just specifies python. Actually the
script needs python3. On a system (e.g. OpenSuse) where "python" by
default is a symlink to python2, chaos ensues ...
Yeah, some distros have repurposed “python” as a synonym for >“python3”, others have not ...
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,116 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 85:27:40 |
| Calls: | 14,305 |
| Files: | 186,338 |
| D/L today: |
647 files (184M bytes) |
| Messages: | 2,525,478 |