Mehrere Python-Versionen gleichzeitig

[Andreas Kohlbach]

Auf meinem alten Rechner "wuchs" Python in mehreren Versionen über die
Jahre. Durch Setzen der passenden Version in Python-Dateien konnte ich
festlegen, welche jeweils genutzt werden soll.

Ich habe keine Ahnung von Perl. So funktioniert eines der Skripte nicht
mehr, da die neue Linux Installation eine neuere Python-Version
mitbringt.

Kann ich eine ältere Python-Version neben der aktuellen Version
installieren, ohne dass aktuellere Skripte vielleicht nicht mehr
funktionieren?

Vermutlich wird es um update-alternatives gehen. Wird bei Installation
einer älteren Version dieser Link ggf. auf die dann ältere Version
verweisen?

Auf dem aktuellen Rechner (wo ein Skript nicht mehr funktioniert - da ich
keine Ahnung von Python habe, schlug das Anpassen selbst fehl) ist 3.9.2
installiert. Auf dem anderen, auf dem das Skript noch läuft, 2.7.18. Das
neue Linux ist Debian stable, das alte testing (interessant dabei, dass
testing eine ältere Python-Version mitbringt).

Da Python ziemlich wichtig für Linux selbst ist, will ich da nicht mit
herumspielen, und bitte stattdessen nach Eurem Wissen und Erfahrungen.
--
Andreas

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:

> Ich habe keine Ahnung von Perl. So funktioniert eines der Skripte nicht
> mehr, da die neue Linux Installation eine neuere Python-Version
> mitbringt.

Python hat mit Perl nix zu tun.

> Kann ich eine ältere Python-Version neben der aktuellen Version
> installieren, ohne dass aktuellere Skripte vielleicht nicht mehr
> funktionieren?

Kommt drauf an, wie du die startest. Das hast du nicht verrraten.

> Auf dem aktuellen Rechner (wo ein Skript nicht mehr funktioniert - da ich
> keine Ahnung von Python habe, schlug das Anpassen selbst fehl) ist 3.9.2
> installiert. Auf dem anderen, auf dem das Skript noch läuft, 2.7.18.

Python2 und Python3 sind nicht kompatibel.

> Da Python ziemlich wichtig für Linux selbst ist

Nicht zwingend, man kommt auch ohne aus.


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Gerald E¡scher]

Andreas Kohlbach schrieb am 25/6/2022 23:30:

> On Sat, 25 Jun 2022 18:42:42 +0000 (UTC), Ulli Horlacher wrote:
>>
>> Python2 und Python3 sind nicht kompatibel.
>

> Alsoooooo: Kann ich Python2 installieren, ohne dass vorhandene Skripte,
> die möglicherweise Python3 erwarten, aufhören zu arbeiten?

Beantwortet das deine Frage?

--------------
gerald@tigermaus:~$ ll /usr/bin/python*
lrwxrwxrwx 1 root root 7 Apr 15 2020 /usr/bin/python -> python2*
lrwxrwxrwx 1 root root 9 Mär 13 2020 /usr/bin/python2 -> python2.7*
-rwxr-xr-x 1 root root 3674216 Mär 8 2021 /usr/bin/python2.7*
lrwxrwxrwx 1 root root 9 Mai 28 2021 /usr/bin/python3 -> python3.8*
-rwxr-xr-x 1 root root 5490448 Mär 15 13:22 /usr/bin/python3.8*
[...]
--------------

Schreib halt nötigenfalls
#!/usr/bin/python3
in die erste Zeile deines Skripts.

Ob /usr/bin/python auf python2 oder python3 zeigen soll, wird WIRME bei
der Installation des jeweiligen Python-Pakets gefragt.


--
Gerald

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:

> >> Kann ich eine ältere Python-Version neben der aktuellen Version
> >> installieren, ohne dass aktuellere Skripte vielleicht nicht mehr
> >> funktionieren?
> >
> > Kommt drauf an, wie du die startest. Das hast du nicht verrraten.
>

> Die erste Zeile ist
>
> #!/usr/bin/python

Dann wird genau dieses Programm gestartet. Welche Version das ist,
bekommst du mit:

/usr/bin/python --version

python 2 ist oft /usr/bin/python2
python 3 ist oft /usr/bin/python3


> Meist starte ich es mit
>
> ./script.py
>
> Es macht keinen Unterschied, ob ich es stattdessen mit "python" oder
> "perl" (diesmal kein Versehen) vorangestellt starte. Scheint die Syntax
> ist ähnlich genug, dass es mit beiden läuft.

Ausgeschlossen. Python und Perl haben keine gleiche Syntax, nicht mal
ansatzweise.


> Es "läuft" mit Python 3 auch nur, weil ich das print-Kommando anpasste,
> bringt aber nicht die erwarteten Ergebnisse.

Weil Python 2 und 3 nicht kompatibel sind.
Starte es doch mit python2, wenn es ein Python 2 Skript ist.

> Alsoooooo: Kann ich Python2 installieren, ohne dass vorhandene Skripte,
> die möglicherweise Python3 erwarten, aufhören zu arbeiten?

Kommt drauf, wass die Instatalltionsroutine mit /usr/bin/python macht.
Laesst es das in Ruhe: ja.
Wenn nicht, musst du alle Skripte anpassen.

> >> Da Python ziemlich wichtig für Linux selbst ist
> >
> > Nicht zwingend, man kommt auch ohne aus.
>

> Vielleicht verwechsle ich das mit Perl? Umm, vermutlich ginge es auch
> ohne Perl, aber...

Ohne Perl wirds schwierig.
Du solltest aber weniger vermuten, mehr Wissen waere besser :-)

[Stefan Reuther]

Am 26.06.2022 um 00:01 schrieb Ulli Horlacher:

> Andreas Kohlbach <a...@spamfence.net> wrote:
>> Meist starte ich es mit
>>
>> ./script.py
>>
>> Es macht keinen Unterschied, ob ich es stattdessen mit "python" oder
>> "perl" (diesmal kein Versehen) vorangestellt starte. Scheint die Syntax
>> ist ähnlich genug, dass es mit beiden läuft.
>
> Ausgeschlossen. Python und Perl haben keine gleiche Syntax, nicht mal
> ansatzweise.

Perl ist aber so freundlich, Python aufzurufen, wenn es die
Shebang-Zeile von Python findet.

# If the #! line does not contain the word "perl" nor the word "indir",
# the program named after the #! is executed instead of the Perl
# interpreter. This is slightly bizarre, but it helps people on machines
# that don't do #!, because they can tell a program that their SHELL is
# /usr/bin/perl, and Perl will then dispatch the program to the correct
# interpreter for them.
<https://perldoc.perl.org/perlrun>


Stefan

[Hermann Riemann]

Am 25.06.22 um 23:30 schrieb Andreas Kohlbach:

>> Kommt drauf an, wie du die startest. Das hast du nicht verrraten.

> Die erste Zeile ist

> #!/usr/bin/python

> Meist starte ich es mit

> ./script.py

Dann ist der Anhang .py für die Ausführung überflüssig.

Die Erste Zeile nach !# besagt, welches Programm den
script interpretiert.
Ob das
/usr/bin/python
/usr/bin/python3
/usr/bin/python3.9
oder ein eigenes Programm bzw script ist.
Ist kein #! angegeben, so wird die default aktuelle shell
als Programm verwendet

Tipp:
Ich habe meine scripts in mindestens einem eigenem Verzeichnis
nun mache dann softlinks von $HOME/bin nach eigenem_Verzeichnis.
Wobei ich in $HOME/bin die Typ Zusätze wie .py .sh weglasse.
chmod 755 ist nur für die script Dateien im eigenem Verzeichnis notwendig.

>> Python2 und Python3 sind nicht kompatibel.

> Alsoooooo: Kann ich Python2 installieren, ohne dass vorhandene Skripte,
> die möglicherweise Python3 erwarten, aufhören zu arbeiten?

Im Prinzip ja, aber Python2 ist irgendwann so tot wie KDE2
Eigene Python2 Programm würde ich auf Python3 anpassen.
Für fremde Programmen, die Python2 brauchen, einen Ersatz suchen.

>>> Da Python ziemlich wichtig für Linux selbst ist

>> Nicht zwingend, man kommt auch ohne aus.

> Vielleicht verwechsle ich das mit Perl? Umm, vermutlich ginge es auch
> ohne Perl, aber...

Also Python3 soll in etlichen Linux Anwendungen vorkommen.
So braucht SuSE 15.3 noch Python 3.6 statt >=3.9. (grrr)

Nach meiner Vermutung wird Perl nicht von Linux verwendet.
Gedanklich ist beim mir Perl ( und Java ) im Altmüll container
wegen aufwändig, unhandlich und nicht notwendig.

--
http://www.hermann-riemann.de

[Patrick Roemer]

Responding to Andreas Kohlbach:

> Kann ich eine ältere Python-Version neben der aktuellen Version
> installieren, ohne dass aktuellere Skripte vielleicht nicht mehr
> funktionieren?

Python selber hat auch einen "virtualenv"-Mechanismus.

https://docs.python.org/3.10/tutorial/venv.html

Damit kann man beliebige Versionen in beliebigen Konfigurationen
parallel in dedizierten Shellumgebungen installieren/laufen lassen. Ich
habe das neulich mal verwendet, um spleeter wie hier beschrieben
auszuprobieren:

https://github.com/deezer/spleeter/issues/754

[Christian Garbs]

Mahlzeit!

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
> Am 25.06.22 um 23:30 schrieb Andreas Kohlbach:

>>>> Da Python ziemlich wichtig für Linux selbst ist
>
>>> Nicht zwingend, man kommt auch ohne aus.
>
>> Vielleicht verwechsle ich das mit Perl? Umm, vermutlich ginge es auch
>> ohne Perl, aber...
>
> Also Python3 soll in etlichen Linux Anwendungen vorkommen.
> So braucht SuSE 15.3 noch Python 3.6 statt >=3.9. (grrr)

Perl kommt ebenfalls in diversen Anwendungen vor – hauptsächlich die,
die in Perl geschrieben sind ;-)

> Nach meiner Vermutung wird Perl nicht von Linux verwendet.

Python auch nicht. Es kann sein, dass Deine Distribution irgendwelche
Anwendungen verwendet, die Perl oder Python voraussetzen
(z.B. Paketmanager oder ähnliches), aber das eigentliche Linux kommt
ohne aus.

> Gedanklich ist beim mir Perl ( und Java ) im Altmüll container
> wegen aufwändig, unhandlich und nicht notwendig.

Das klingt wie "ich habe Orange und Blau aus meinem Malkasten
entfernt".

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Don't look for my sig!

[Christian Garbs]

Mahlzeit!

Andreas Kohlbach <a...@spamfence.net> wrote:

> Auf dem aktuellen Rechner (wo ein Skript nicht mehr funktioniert - da ich
> keine Ahnung von Python habe, schlug das Anpassen selbst fehl) ist 3.9.2
> installiert. Auf dem anderen, auf dem das Skript noch läuft, 2.7.18. Das
> neue Linux ist Debian stable, das alte testing (interessant dabei, dass
> testing eine ältere Python-Version mitbringt).

Dass Python 2 "aus der Wartung" und Python 3 leider inkompatibel ist,
wurde ja schon an anderer Stelle hier im Thread erwähnt.

Die Debian-Spezifika sind in den Debian-Releasenotes erklärt:

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html

Unter "5.3.1. Nennenswerte veraltete Pakete" steht folgendes:

| Python 2 hat das Ende seiner Lebenszeit bereits überschritten, und
| wird keine Sicherheitsaktualisierungen mehr erhalten. Es wird nicht
| mehr unterstützt, um Anwendungen laufen zu lassen und Pakete, die
| darauf aufbauen, sind entweder auf Python 3 konvertiert oder
| entfernt worden. Allerdings enthält Debian Bullseye noch die Version
| Python 2.7, sowie eine kleinere Anzahl von Bauwerkzeugen für Python
| 2, wie z.B. python-setuptools. Diese sind jedoch nur vorhanden, da
| sie noch benötigt werden, um einige wenige Anwendungen zu bauen, die
| noch nicht auf Python 3 konvertiert wurden.


Im Debian-Wiki finden sich weitergehende Informationen:

https://wiki.debian.org/Python#Python_in_Debian
https://wiki.debian.org/Python/FAQ#Python_2_support

> Da Python ziemlich wichtig für Linux selbst ist, will ich da nicht mit
> herumspielen, und bitte stattdessen nach Eurem Wissen und Erfahrungen.

Mit Blick auf die Debian-Doku ist der offizielle Weg in Debian klar:
Es gibt nur noch Python 3, werde Deine alten Python-2-Skripte los.

Wo Du wirklich nicht um Python 2 herumkommst, dann solltest Du Dir ein
eigenes Python irgendwo hininstallieren (über das anderswo hier in Thread
erwähnte virtualenv).

Am besten aber die betroffenen Skripte auf Python 3 migrieren. Es
gibt vermutlich haufenweise Anleitungen dazu im Netz, tausende
Programmierer haben sich die letzten Jahre damit beschäftigt.

Kurzes Googeln bringt das hier:

https://docs.python.org/3/howto/pyporting.html

und darus findet man dann ein ganzes _Buch_ über die Migration:

http://python3porting.com/

Da wird von einem Tool "2to3" gesprochen.

Ich programmiere aber kein Python (wohl aber Perl ;-), daher habe ich
das jetzt zwar gefunden, da aber keine tiefere Ahnung von.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

"You're in Asgard, the home of the gods." Ryoga put
his palm to his forehead. "Oh, man, now I'm really
lost! I belong in a completely different fanfic.

[Sieghard Schicktanz]

Hallo Hermann Riemann,

Du schriebst am Sun, 26 Jun 2022 08:49:35 +0200:

> > Meist starte ich es mit
>
> > ./script.py
>
> Dann ist der Anhang .py für die Ausführung überflüssig.

HAst Du das mal selber ausprobiert?
Wenn das Script "script.py" heißt, dann muß (MUSS) es auch so
aufgerufen werden.

> Die Erste Zeile nach !# besagt, welches Programm den
> script interpretiert.
> Ob das
> /usr/bin/python
> /usr/bin/python3
> /usr/bin/python3.9
> oder ein eigenes Programm bzw script ist.
> Ist kein #! angegeben, so wird die default aktuelle shell
> als Programm verwendet

Korrekt.

> nun mache dann softlinks von $HOME/bin nach eigenem_Verzeichnis.
> Wobei ich in $HOME/bin die Typ Zusätze wie .py .sh weglasse.

Ja, _denn_ (und nurdann) kannst Du nicht nur die "Zusätze" weglassen,
sondern _mußt_ die weglassen.

> chmod 755 ist nur für die script Dateien im eigenem Verzeichnis
> notwendig.

Ein "chmod", das das "x"- (ausführen) Attribut setzt. ist grundsätzlich
nötig, wenn das Script eigenständig (d.h. ohne Angabe eines
interpretierenden Programms) ausgeführt werden soll. Und dann ist die
o.g. erste Zeile mit der "#!" relevant (soweit sie vom Aufruf der
laufenden "shell" abweicht).

...

> Nach meiner Vermutung wird Perl nicht von Linux verwendet.

Von "Linux" selber (dem Kernel) nicht, aber von vielen
Hilfsprogrämmchen. Und nachdem grade eine neue perl-Version
'rausgekommen istt, hatte ich mal wieder "viel Spaß" mit einigen
selbstinstallierten, weil von externen Utilities angeforderten,
derselben. Da gab's reihenweise Fehler beim Aktualisieren, weil Perl
die einzige - mir bekannte - Programmiersprache ist, die zum
Aktualisieren der eigenen Biliotheken die aktualisierte Versin verlangt
und daher bei installierter alter Version auf die Schnauze fällt.
(Leider zeigt inzwischen Python auch schon erste Ansätze zu einer
solchen Entwicklung...)

> Gedanklich ist beim mir Perl ( und Java ) im Altmüll container
> wegen aufwändig, unhandlich und nicht notwendig.

Wäre schön, ist aber, außer in speziellen Umgebungen, nicht so.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Ulli Horlacher]

Christian Garbs <mi...@cgarbs.de> wrote:

> Am besten aber die betroffenen Skripte auf Python 3 migrieren. Es
> gibt vermutlich haufenweise Anleitungen dazu im Netz, tausende
> Programmierer haben sich die letzten Jahre damit beschäftigt.
>
> Kurzes Googeln bringt das hier:
>
> https://docs.python.org/3/howto/pyporting.html
>
> und darus findet man dann ein ganzes _Buch_ über die Migration:
>
> http://python3porting.com/
>
> Da wird von einem Tool "2to3" gesprochen.

Das funktioniert nur fuer SEHR triviale Programme.
Bei meinen eigenen Python 2 Programmen, die nur eine Stufe ueber trivial
liegen, hat es versagt. Ich musste die dann komplett neu schreiben, was
weniger Arbeit als eine manuelle Migration war.

Python ist *ZENSIERT* :-}

[Andreas Kohlbach]

On Sat, 25 Jun 2022 22:01:09 +0000 (UTC), Ulli Horlacher wrote:
>
> Andreas Kohlbach <a...@spamfence.net> wrote:
>
>> >> Kann ich eine ältere Python-Version neben der aktuellen Version
>> >> installieren, ohne dass aktuellere Skripte vielleicht nicht mehr
>> >> funktionieren?
>> >
>> > Kommt drauf an, wie du die startest. Das hast du nicht verrraten.
>>
>> Die erste Zeile ist
>>
>> #!/usr/bin/python
>
> Dann wird genau dieses Programm gestartet. Welche Version das ist,
> bekommst du mit:
>
> /usr/bin/python --version
>
> python 2 ist oft /usr/bin/python2
> python 3 ist oft /usr/bin/python3

| ank@workhorse:~$ /usr/bin/python --version
| -bash: /usr/bin/python: No such file or directory

:-D

Aber /usr/bin/python3 existiert.

>> Meist starte ich es mit
>>
>> ./script.py
>>
>> Es macht keinen Unterschied, ob ich es stattdessen mit "python" oder
>> "perl" (diesmal kein Versehen) vorangestellt starte. Scheint die Syntax
>> ist ähnlich genug, dass es mit beiden läuft.
>
> Ausgeschlossen. Python und Perl haben keine gleiche Syntax, nicht mal
> ansatzweise.

Kann ich nun bestätigen. Was habe ich da gestern gemacht? :-/

>> Es "läuft" mit Python 3 auch nur, weil ich das print-Kommando anpasste,
>> bringt aber nicht die erwarteten Ergebnisse.
>
> Weil Python 2 und 3 nicht kompatibel sind.
> Starte es doch mit python2, wenn es ein Python 2 Skript ist.

Wenn ich am Rechner bin, werde ich Python2 installieren...

[...]
--
Andreas

[Hermann Riemann]

Am 26.06.22 um 20:21 schrieb Sieghard Schicktanz:

> Hallo Hermann Riemann,
>
> Du schriebst am Sun, 26 Jun 2022 08:49:35 +0200:
>
>>> Meist starte ich es mit
>>
>>> ./script.py
>>
>> Dann ist der Anhang .py für die Ausführung überflüssig.
>
> HAst Du das mal selber ausprobiert?
> Wenn das Script "script.py" heißt, dann muß (MUSS) es auch so
> aufgerufen werden.

Und wenn es nur script heisst
reicht ./script

Probiere eine Datei z.B. p
Folgender beide Zeile einfügen:

#!/usr/bin/python3
print("Hallo")

dann chmod 755 p

dann ./p

Ohne chmod 755 p
und mv p p.py
erhalte ich bei ./p.py die Meldung:
bash: ./p.py: Keine Berechtigung

>> nun mache dann softlinks von $HOME/bin nach eigenem_Verzeichnis.
>> Wobei ich in $HOME/bin die Typ Zusätze wie .py .sh weglasse.
>
> Ja, _denn_ (und nurdann) kannst Du nicht nur die "Zusätze" weglassen,
> sondern _mußt_ die weglassen.

Dass müssen ist falsch.
Der Dateiname in $HOME/bin kann innerhalb Unixregeln ( kein \0 kein / )
beliebig sein.
Dass ich die Endungen von Dateien in $HOME/bin weg lasse,
hat sich als praktisch für mich gezeigt.
Fazit: der Zusatz wie py ist nur für Lesbarkeit, compiler Eingaben
und nach meiner Vermutung GUIs und Programme wie Apache relevant.

Relevant ist der header, auch bei Bilder, übersetzte Objekte
bzw #! in erster Textzeile.

Datei p.c
Inhalt:

main(){}

cc p.c
mv a.out a.png
./a.png
funktioniert.
Wenn man die Datei sich mit firefox ansieht:
meint firefox, sie enthält eine fehlerhafte Grafik.
mv a.png $HOME/bin/a.png
dann kann a.png aufgerufen werden.

mv $HOME/bin/a.png a.c
cc a.c
..

>> chmod 755 ist nur für die script Dateien im eigenem Verzeichnis
>> notwendig.

Damit habe ich gemeint das die Attribute bei link-Verweise
z.B. in $HOME/bin ignoriert wird.

> Ein "chmod", das das "x"- (ausführen) Attribut setzt. ist grundsätzlich
> nötig, wenn das Script eigenständig (d.h. ohne Angabe eines
> interpretierenden Programms) ausgeführt werden soll. Und dann ist die
> o.g. erste Zeile mit der "#!" relevant (soweit sie vom Aufruf der
> laufenden "shell" abweicht).

Korrekt.

>> Gedanklich ist beim mir Perl ( und Java ) im Altmüll container
>> wegen aufwändig, unhandlich und nicht notwendig.

> Wäre schön, ist aber, außer in speziellen Umgebungen, nicht so.

In browser deaktiviere ich des öfteren Java.
Manchmal auch JavaScript, was von etlichen Seiten behindert wird.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 27.06.22 um 01:35 schrieb Ulli Horlacher:

>> Da wird von einem Tool "2to3" gesprochen.
>
> Das funktioniert nur fuer SEHR triviale Programme.
> Bei meinen eigenen Python 2 Programmen, die nur eine Stufe ueber trivial
> liegen, hat es versagt. Ich musste die dann komplett neu schreiben, was
> weniger Arbeit als eine manuelle Migration war.

Die Hauptarbeit bei Python2 nach Python3
war bei mir die Änderung bei print.

2to3 habe ich nicht verwendet.
Mit grep nach print gesucht, da von Hand editiert.
Mit Programmen die erste Zeile #!.. angepasst.

Und dann probiert.

Hermann
zugebend früh Python3 statt Python2 verwendet zu haben,
so dass sehr wenig umzustellen war.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 27.06.22 um 05:19 schrieb Andreas Kohlbach:

> Wenn ich am Rechner bin, werde ich Python2 installieren...

Für einen anderen user etwa names py2 dann mit Anaconda?
Der user py2 bekommt alle alten Python2 Programme.
$USER verwendet softlinks auf alte Programme in $HOME/py2

Hermann
der gedanklich momentan so aufräumen würde.

--
http://www.hermann-riemann.de

[Peter Heitzer]

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>Am 27.06.22 um 01:35 schrieb Ulli Horlacher:

>>> Da wird von einem Tool "2to3" gesprochen.
>>
>> Das funktioniert nur fuer SEHR triviale Programme.
>> Bei meinen eigenen Python 2 Programmen, die nur eine Stufe ueber trivial
>> liegen, hat es versagt. Ich musste die dann komplett neu schreiben, was
>> weniger Arbeit als eine manuelle Migration war.

>Die Hauptarbeit bei Python2 nach Python3
>war bei mir die Änderung bei print.

Bei einfachen Skripten wohl wahr. Lästig wird es, wenn E/A mit Unicode bzw.
UTF-8 ins Spiel kommt. Dann artet das oft in encode/decode Orgien aus.
Auch hat sich die Semantik zwischen 2 und 3 teilweise subtil verändert.
Einige Bibliotheken gibt es für Python3 nicht mehr oder nur mit stark veränderter
API. Da muss ich Ulli Recht geben. In solchen Fällen ist neu schreiben oft die
bessere Alternative, zumal die Erstlingswerke in Python2 meist eher weniger
elegant geschrieben wurden.

--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Hermann Riemann]

Am 27.06.22 um 10:02 schrieb Peter Heitzer:

> Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>> Am 27.06.22 um 01:35 schrieb Ulli Horlacher:
>
>>>> Da wird von einem Tool "2to3" gesprochen.
>>>
>>> Das funktioniert nur fuer SEHR triviale Programme.
>>> Bei meinen eigenen Python 2 Programmen, die nur eine Stufe ueber trivial
>>> liegen, hat es versagt. Ich musste die dann komplett neu schreiben, was
>>> weniger Arbeit als eine manuelle Migration war.
>
>> Die Hauptarbeit bei Python2 nach Python3
>> war bei mir die Änderung bei print.
> Bei einfachen Skripten wohl wahr. Lästig wird es, wenn E/A mit Unicode bzw.
> UTF-8 ins Spiel kommt.

Stimmt, da gab es Probleme mit strings.

Python3 hat mir Probleme im Zusammenhang
print und cgi bereitet.

Unter SuSE habe ich
sys.stdout=codecs.open('dev.stdout',"w","utf8")
am Dateianfang eingefügt, damit es funktionierte.
Auf raspberry pi ging das nicht.
Wahrscheinlich muss ich da mit eigenem print_
nach &#x($hexwert); konvertieren.

> Dann artet das oft in encode/decode Orgien aus.
> Auch hat sich die Semantik zwischen 2 und 3 teilweise subtil verändert.

Z.B. das // bei Division

> Einige Bibliotheken gibt es für Python3 nicht mehr oder nur mit stark veränderter
> API. Da muss ich Ulli Recht geben.

Das ändert sich auch so.

> In solchen Fällen ist neu schreiben oft die
> bessere Alternative, zumal die Erstlingswerke in Python2 meist eher weniger
> elegant geschrieben wurden.

Mit etlicher Erfahrung schreibe ich heutzutage
auch einiges in Python3 anders als früher.

Z.B. for dirname, dirnames, filenames in os.walk($name):


Ich habe etliche C-Programme, die Texte behandelten,
in Python3 neu geschrieben.
Die Frage neu schreiben oder anpassen
ist eine Frage des Aufwandes.
Man kann auch mit copy und paste mischen.

Hermann
der beim programmieren meistens Python3 verwendet,
gelegentlich noch C (z.B. Pixelgrafik),
und nur für html-Bereich JavaScript.

--
http://www.hermann-riemann.de

[Gerald E¡scher]

Andreas Kohlbach schrieb am 27/6/2022 05:26:

> On 25 Jun 2022 21:59:31 GMT, Gerald E¡scher wrote:
>>
>> Ob /usr/bin/python auf python2 oder python3 zeigen soll, wird WIRME bei
>> der Installation des jeweiligen Python-Pakets gefragt.
>

> War ein externes und vom Autor vermutlich schnell zusammengehacktes
> Skript, was nicht installiert wurde.

Ich meinte Python selbst (2 oder 3), nicht dein Skript.

--
Gerald

[Thomas Dorner]

Christian Garbs <mi...@cgarbs.de> writes:

> Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>> Nach meiner Vermutung wird Perl nicht von Linux verwendet.
>
> Python auch nicht.

Dann suche mal in den Kernel Sourcen nach '*.p[ly]' und Du wirst beides
finden, hauptsächlich im den Verzeichnissen scripts und tools.

>> Gedanklich ist beim mir Perl ( und Java ) im Altmüll container
>> wegen aufwändig, unhandlich und nicht notwendig.
>
> Das klingt wie "ich habe Orange und Blau aus meinem Malkasten
> entfernt".

YMMD :-)

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Christian Garbs]

Mahlzeit!

Thomas Dorner <de.comp.os.unix.linu...@spamgourmet.com> wrote:
> Christian Garbs <mi...@cgarbs.de> writes:
>> Hermann Riemann <nosp...@hermann-riemann.de> wrote:

>>> Nach meiner Vermutung wird Perl nicht von Linux verwendet.
>>
>> Python auch nicht.
>
> Dann suche mal in den Kernel Sourcen nach '*.p[ly]' und Du wirst beides
> finden, hauptsächlich im den Verzeichnissen scripts und tools.

Ja gut, im Buildsystem. Aber wenn der Kernel fertig ist, läuft er
prima ohne. Sonst müsste man ja auch C-Compiler und Assembler
usw. mit auf die Liste setzen, das wird komisch ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

"Heinz, Du hast ja in jedem Satz ein Fehler!"

[Christian Garbs]

Mahlzeit!

Hermann Riemann <nosp...@hermann-riemann.de> wrote:

> In browser deaktiviere ich des öfteren Java.
> Manchmal auch JavaScript, was von etlichen Seiten behindert wird.

Da muss ich interessiert zurückfragen: Gibt es für aktuelle Browser
noch Java-Plugins? Java-Applets sind mir seit Ewigkeiten nicht mehr
vor die Füße gekommen.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Und ich habe mich nunmal nicht an die Spitze der Nahrungskette
hochgearbeitet, um Vegetarier zu werden. Sorry.
(Klaus Kessler in de.rec.tiere.misc)

[Sieghard Schicktanz]

Hallo Hermann Riemann,

Du schriebst am Mon, 27 Jun 2022 07:16:08 +0200:

> >>> Meist starte ich es mit
> >>> ./script.py
> >>
> >> Dann ist der Anhang .py für die Ausführung überflüssig.
> >
> > HAst Du das mal selber ausprobiert?
> > Wenn das Script "script.py" heißt, dann muß (MUSS) es auch so
> > aufgerufen werden.
>
> Und wenn es nur script heisst
> reicht ./script

Ja, aber dann heißt es eben _NICHT_ "script.py" - äh, naja...

> Probiere eine Datei z.B. p

...

> dann chmod 755 p
> dann ./p

Naja, gibt halt'n "Hallo" aus. Isja richtig so.

> Ohne chmod 755 p

Also:
-rw-r--r-- 1 34 Jun 27 20:27 p
?

> und mv p p.py
> erhalte ich bei ./p.py die Meldung:
> bash: ./p.py: Keine Berechtigung

Was hast'n Du für ne komische Shell am Laufen? Bei mir:
$ mv p p.py
$
und
ls p*
p.py
$
ganz normal wie zu erwarten. Du machst was falsch.

> >> nun mache dann softlinks von $HOME/bin nach eigenem_Verzeichnis.
> >> Wobei ich in $HOME/bin die Typ Zusätze wie .py .sh weglasse.
> >
> > Ja, _denn_ (und nurdann) kannst Du nicht nur die "Zusätze"
> > weglassen, sondern _mußt_ die weglassen.
>
> Dass müssen ist falsch.

Nicht bei (jeder) "normalen" Shell. Da wird (ist?) bei Dir was
manipuliert, und das kann u.U. schlimme Folgen haben. Oder das sind
schon Auswirkungen davon.

> Dass ich die Endungen von Dateien in $HOME/bin weg lasse,
> hat sich als praktisch für mich gezeigt.

Reine Schreibvereinfachung. Kann auch mal zu Kollisonen führen, wenn
man nicht aufpasst.

> Fazit: der Zusatz wie py ist nur für Lesbarkeit, compiler Eingaben
> und nach meiner Vermutung GUIs und Programme wie Apache relevant.

Sicher - der ist nur ein äußerlicher Hinweis darauf, was in der Datei
enthalten sein _KÖNNTE_.

> Relevant ist der header, auch bei Bilder, übersetzte Objekte
> bzw #! in erster Textzeile.

Solange eine (konforme) Shell oder der Kernel selber die Zeile (oder
die Daten) auswerten.

> Datei p.c
...

> cc p.c
> mv a.out a.png

gcc kann die Umbenennung gleich mit erledigen. Aber das ist Dir wohl zu
einfach, oder Du müßtest zuviel im Compiler-Aufruf tippseln...

> ./a.png
> funktioniert.

Klar, ist ja ein normales ELF-Programm.

> Wenn man die Datei sich mit firefox ansieht:
> meint firefox, sie enthält eine fehlerhafte Grafik.

Firefox ist keine Shell, der versucht alles selber zu erkennen und
benutzt dazu völlig andere Regeln (MIME).

> mv a.png $HOME/bin/a.png
> dann kann a.png aufgerufen werden.

Von Firefox? Naja, _könnte_ sein, wenn da eine passende .htaccess
drinsteht. Von Dir, ohne Pfadangabe? Nur, wenn Dein $PATH dein privates
("$HOME/bin") bin-Directory enthält.

> mv $HOME/bin/a.png a.c
> cc a.c

> ...

Na, da wird's jetzt leicht chaotisch - erst komplizierst^Wkompilierst
Du eine p.c in eine a.png, dann schiebst Du die in Deinem home 'rum,
und dann willst Du die schon kompilierte Datei nochmal kompilieren -
aber das Ergebnis läßt Du vorsichtshalber weg, das kann nämlich nur
eine Fehlermeldung sein.

> >> chmod 755 ist nur für die script Dateien im eigenem Verzeichnis
> >> notwendig.
>
> Damit habe ich gemeint das die Attribute bei link-Verweise
> z.B. in $HOME/bin ignoriert wird.

Dann schreib' das gefälligst auch. Woher sollen andere wissen, was Du
"gemeint" hast? Links benutzen _grundsätzlich_ die Rechte der
verlinkten Datei, und wenn Du versuchst, die Rechte am Link zu ändern,
dann werden die Rechte der verlinkten Datei geändert, falls Du das
Recht dazu hast.

> > Ein "chmod", das das "x"- (ausführen) Attribut setzt. ist
> > grundsätzlich nötig, wenn das Script eigenständig (d.h. ohne Angabe
> > eines interpretierenden Programms) ausgeführt werden soll. Und dann
> > ist die o.g. erste Zeile mit der "#!" relevant (soweit sie vom
> > Aufruf der laufenden "shell" abweicht).
>
> Korrekt.

Ächt? (Wobei man schon bald skeptisch sein muß, wenn Du was als
korrekt bezeichnest...)

[Hermann Riemann]

Am 27.06.22 um 21:06 schrieb Sieghard Schicktanz:

> Hallo Hermann Riemann,
>
> Du schriebst am Mon, 27 Jun 2022 07:16:08 +0200:
>
>>>>> Meist starte ich es mit
>>>>> ./script.py
>>>>
>>>> Dann ist der Anhang .py für die Ausführung überflüssig.
>>>
>>> HAst Du das mal selber ausprobiert?
>>> Wenn das Script "script.py" heißt, dann muß (MUSS) es auch so
>>> aufgerufen werden.
>>
>> Und wenn es nur script heisst
>> reicht ./script
>
> Ja, aber dann heißt es eben _NICHT_ "script.py" - äh, naja...
>
>> Probiere eine Datei z.B. p
> ...
>> dann chmod 755 p
>> dann ./p
>
> Naja, gibt halt'n "Hallo" aus. Isja richtig so.

Und das ohne den Zusat .py ( Also kein p.py)

>
>> Ohne chmod 755 p
>
> Also:
> -rw-r--r-- 1 34 Jun 27 20:27 p
> ?

Ja.

>> und mv p p.py
>> erhalte ich bei ./p.py die Meldung:
>> bash: ./p.py: Keine Berechtigung
>
> Was hast'n Du für ne komische Shell am Laufen? Bei mir:
> $ mv p p.py
> $
> und
> ls p*
> p.py
> $
> ganz normal wie zu erwarten. Du machst was falsch.

Da fehlt für obige Meldung noch ./p.py

>>>> nun mache dann softlinks von $HOME/bin nach eigenem_Verzeichnis.
>>>> Wobei ich in $HOME/bin die Typ Zusätze wie .py .sh weglasse.
>>>
>>> Ja, _denn_ (und nurdann) kannst Du nicht nur die "Zusätze"
>>> weglassen, sondern _mußt_ die weglassen.
>>
>> Dass müssen ist falsch.
>
> Nicht bei (jeder) "normalen" Shell. Da wird (ist?) bei Dir was
> manipuliert, und das kann u.U. schlimme Folgen haben. Oder das sind
> schon Auswirkungen davon.

Gibt es denn shells, die bei Ausführung
die Dateiattribute des Verweises
statt die Dateiattribute bei der verwendeten Datei verwenden?

>> Dass ich die Endungen von Dateien in $HOME/bin weg lasse,
>> hat sich als praktisch für mich gezeigt.

> Reine Schreibvereinfachung. Kann auch mal zu Kollisonen führen, wenn
> man nicht aufpasst.

Das haben Schreibvereinfachung so an sich.
Wie auch bei anderen Abkürzungen.
Gab es nicht mal einen style guide der statt index.html
the_index.html zur besseren Lesbarkeit empfahl?
( Prinzip allerdings bei Namen von Variablen
Wie bash Kommandos wohl in COBOLianisch aussehen würden? )

>> Fazit: der Zusatz wie py ist nur für Lesbarkeit, compiler Eingaben
>> und nach meiner Vermutung GUIs und Programme wie Apache relevant.
>
> Sicher - der ist nur ein äußerlicher Hinweis darauf, was in der Datei
> enthalten sein _KÖNNTE_.

ls -l zeigt ( zumindest bei bash ) die Original Dateinamen an.

>> Relevant ist der header, auch bei Bilder, übersetzte Objekte
>> bzw #! in erster Textzeile.
>
> Solange eine (konforme) Shell oder der Kernel selber die Zeile (oder
> die Daten) auswerten.
>
>> Datei p.c
> ...
>> cc p.c
>> mv a.out a.png
>
> gcc kann die Umbenennung gleich mit erledigen. Aber das ist Dir wohl zu
> einfach, oder Du müßtest zuviel im Compiler-Aufruf tippseln...

Ich tippe cc statt gcc, vi statt vim ..
Ich bin es gewohnt, es funktioniert.
Und ist von SuSE, Debian vermutlich auch Kubuntu so eingerichtet.
Raspian macht mir vi praktisch unbrauchbar,
da die gewohnte Positionierung mit Pfeiltasten nicht geht.

>
>> ./a.png
>> funktioniert.
>
> Klar, ist ja ein normales ELF-Programm.
>
>> Wenn man die Datei sich mit firefox ansieht:
>> meint firefox, sie enthält eine fehlerhafte Grafik.
>
> Firefox ist keine Shell, der versucht alles selber zu erkennen und
> benutzt dazu völlig andere Regeln (MIME).

Man kann die Datei zum anschauen auch nach a.txt oder a.html umbenennen.

Ganz so stimmt das mit alles nicht.
Dateiendungen mit .pl oder .py lösen Rückruf aus.
Da kommt je nach server etwas in html Format (wegen cgi) heraus,
oder es wird einfach nur der Quelltext angezeigt.

>> mv a.png $HOME/bin/a.png
>> dann kann a.png aufgerufen werden.

> Von Firefox?

Nein, von einer shell aus.

> Naja, _könnte_ sein, wenn da eine passende .htaccess
> drinsteht. Von Dir, ohne Pfadangabe? Nur, wenn Dein $PATH dein privates
> ("$HOME/bin") bin-Directory enthält.

Bei firefox müsste ich das über den cgi Umweg machen.
Python: os.system("a.png")

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 28.06.22 um 00:22 schrieb Andreas Kohlbach:

> On Mon, 27 Jun 2022 07:24:05 +0200, Hermann Riemann wrote:
>>
>> Am 27.06.22 um 01:35 schrieb Ulli Horlacher:
>>
>>>> Da wird von einem Tool "2to3" gesprochen.
>>> Das funktioniert nur fuer SEHR triviale Programme.
>>> Bei meinen eigenen Python 2 Programmen, die nur eine Stufe ueber trivial
>>> liegen, hat es versagt. Ich musste die dann komplett neu schreiben, was
>>> weniger Arbeit als eine manuelle Migration war.
>>
>> Die Hauptarbeit bei Python2 nach Python3
>> war bei mir die Änderung bei print.
>

> Das mit dem print ist auch genau mein Problem. Am WE werde ich mich mal
> über die Unterschiede einlesen...

Der Unterschied ist in der Regel,
das bei Python3 print ein Funkionsaufruf ist.
Es reicht normalerweise
hinter print das Zeichen ( und am Ende das Zeichen ) zu einzufügen.
Also mit grep -rn print Verzeichnis_mit_Python_Programmen suchen
und das Ergebnis anschauen.

--
http://www.hermann-riemann.de

[Sieghard Schicktanz]

Hallo Hermann Riemann,

Du schriebst am Tue, 28 Jun 2022 07:26:46 +0200:

> >> Die Hauptarbeit bei Python2 nach Python3
> >> war bei mir die Änderung bei print.

...

> Es reicht normalerweise
> hinter print das Zeichen ( und am Ende das Zeichen ) zu einzufügen.
> Also mit grep -rn print Verzeichnis_mit_Python_Programmen suchen
> und das Ergebnis anschauen.

Und dann kann man mit einem sed-Aufruf alles passend umbauen.

[Sieghard Schicktanz]

Hallo Hermann Riemann,

Du schriebst am Tue, 28 Jun 2022 07:21:21 +0200:

> >> Probiere eine Datei z.B. p

> >> dann chmod 755 p
> >> dann ./p
> >
> > Naja, gibt halt'n "Hallo" aus. Isja richtig so.
>
> Und das ohne den Zusat .py ( Also kein p.py)

Klar, den gibt es ja auch nicht.

> >> und mv p p.py
> >> erhalte ich bei ./p.py die Meldung:
> >> bash: ./p.py: Keine Berechtigung
> >
> > Was hast'n Du für ne komische Shell am Laufen? Bei mir:
> > $ mv p p.py
> > $
> > und
> > ls p*
> > p.py
> > $
> > ganz normal wie zu erwarten. Du machst was falsch.
>
> Da fehlt für obige Meldung noch ./p.py

Natürlich, das ist ja die Ausgabe vom ls-Aufruf.
Oder _meinst_ Du evtl., daß das dann unter dem neuen Namen _aufzurufen_
wäre? Dann kommt halt ein "Hallo" - ganz normal wie zu erwarten. Du
machst was falsch.

...

> Gibt es denn shells, die bei Ausführung
> die Dateiattribute des Verweises
> statt die Dateiattribute bei der verwendeten Datei verwenden?

Kann ich mir nicht vorstellen, das wäre vollkommen nutz-, sinn- und
zwecklos und widerspräche außerdem jeglichem Standard (POSIX hier).

...

> Gab es nicht mal einen style guide der statt index.html
> the_index.html zur besseren Lesbarkeit empfahl?

Das wäre _auch_ Käse, weil dann die "index.html" nicht mehr als Start
für die Seitenanzeige funktionieren würde. Dafür muß sie als Namen
"index" tragen. Aberman kann das schon auch verkonfigurieren und damit
den meisten Leuten Probleme machen.

...

> ls -l zeigt ( zumindest bei bash ) die Original Dateinamen an.

Es gibt auch andere Shells und Programmen, die den Link-_Inhalt_ listen.

...

> > Firefox ist keine Shell, der versucht alles selber zu erkennen und
> > benutzt dazu völlig andere Regeln (MIME).
>
> Man kann die Datei zum anschauen auch nach a.txt oder a.html
> umbenennen.

Klar, dem System ist der Name egal, und Programme orientieren sich an
unterschiedlichen Eigenschaften. Und wenn das nicht paßt, kommt halt
auch mal Unsinn 'raus.

> Ganz so stimmt das mit alles nicht.

? Mit wem oder was?

> Dateiendungen mit .pl oder .py lösen Rückruf aus.

Nein.

> Da kommt je nach server etwas in html Format (wegen cgi) heraus,
> oder es wird einfach nur der Quelltext angezeigt.

Wenn Du einen Browser meinst: da hängt es von der Konfiguration
_sowohl_ des Servers _als auch_ der des Browsers ab, was da 'rauskommt.

> >> mv a.png $HOME/bin/a.png
> >> dann kann a.png aufgerufen werden.
>
> > Von Firefox?
>
> Nein, von einer shell aus.

...

> Bei firefox müsste ich das über den cgi Umweg machen.
> Python: os.system("a.png")

Nee, laß' mal. Ich hör' hier lieber auf.

Es gibt halt Leute, deren Ahnung auf die Temperaturskala übertragen,
jede noch so forgeschrittenee Teiftemperatur-Forschungsgruppe neidvoll
erblassen lassen könnte...

[Christian Garbs]

Mahlzeit!

Sieghard Schicktanz <Sieghard....@schs.de> wrote:
> Du schriebst am Mon, 27 Jun 2022 07:16:08 +0200:

>> Probiere eine Datei z.B. p
> ...
>> dann chmod 755 p
>> dann ./p
>
> Naja, gibt halt'n "Hallo" aus. Isja richtig so.
>
>> Ohne chmod 755 p
>
> Also:
> -rw-r--r-- 1 34 Jun 27 20:27 p
> ?
>> und mv p p.py
>> erhalte ich bei ./p.py die Meldung:
>> bash: ./p.py: Keine Berechtigung
>
> Was hast'n Du für ne komische Shell am Laufen?

Wenn er _kein_ chmod 755 macht, p nach p.py umbenennt und dann ./p.py
aufruft, sollte es normal sein, dass die Shell das als nicht
ausführbare anmeckert, oder?

Meine sagt "bash: ./p.py: Permission denied", aber der Unterschied
liegt an der Locale.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Heute kann man ja kaum noch eine AOL-CD aus dem Fenster werfen, ohne
jemanden zu treffen, der einen SuSE-Karton unter dem Arm trägt.
(Jochem Huhmann in de.comp.os.unix.discussion)

[Christian Garbs]

Mahlzeit!

Hermann Riemann <nosp...@hermann-riemann.de> wrote:

> Am 27.06.22 um 21:06 schrieb Sieghard Schicktanz:

> Wie bash Kommandos wohl in COBOLianisch aussehen würden? )

Ich tippe auf "wie Lisp ohne Klammern" (zumindest wenn man darauf
verzichtet, ausschließlich Großbuchstaben zu verwenden).

Ich hatte mal an angefangen, ein Shell-Skript mit diversen kleinen
Funktionen in kebab-case statt snake_case zu schreiben und daraus
resultierende Konstrukte wie

if contains-key some-file some-key; then
read-value some-file some-key | display-value
fi

erinnerten mich stark an Elisp. Was vermutlich aber ausschließlich an
den Bindestrichen liegt ;-)

(Ich weiß gar nicht mehr, was mich auf snake_case umschwenken lassen
hat. Ich glaube, an irgendeiner Stelle waren keine Bindestriche
erlaubt (Funktionsnamen?) und gemischt sah es dann doof aus.)

> Ich tippe cc statt gcc, vi statt vim ..
> Ich bin es gewohnt, es funktioniert.
> Und ist von SuSE, Debian vermutlich auch Kubuntu so eingerichtet.
> Raspian macht mir vi praktisch unbrauchbar,
> da die gewohnte Positionierung mit Pfeiltasten nicht geht.

Ich könnte mir folgendes vorstellen:

- Es ist nur ein minimal-vi installiert, um Platz zu sparen
(z.B. vim-tiny statt vim). Vielleicht kann der keine Pfeiltasten.

- Es sind nicht alle Terminal-Beschreibungen installiert, daher
werden die Cursor-Tasten nicht sauber gemappt.

- Es gibt keine ordentliche Vorkonfiguration vom vi und Du musst die
Tasten selber mappen.

Das erste halte ich für das wahrscheinlichste - schau mal in den
Paketmanager. Das Problem sollte sich auf jeden Fall lösen lassen.

>> Firefox ist keine Shell, der versucht alles selber zu erkennen und
>> benutzt dazu völlig andere Regeln (MIME).

Bei _lokalen_ Dateien, die nicht von einem Webserver kommen, benutzt
Firefox glaube ich mangels MIME-Headern tatsächlich die Dateiendung
als Anhaltspunkt. Die /etc/media.types hat ja auch eine Spalte für
sowas.

> Man kann die Datei zum anschauen auch nach a.txt oder a.html umbenennen.

Das kann ich hier für lokale Dateien nachstellen. Eine PNG-Datei
umbenannt nach foo.txt wird vom Aufruf "firefox foo.txt" als
Textdatei angezeigt.

> Ganz so stimmt das mit alles nicht.
> Dateiendungen mit .pl oder .py lösen Rückruf aus.

Das ist kein "Rückruf" – zumindest kein Rückruf von Deinem Browser.

Das Perl- oder Python-Skript wird gar nicht erst an Deinen Browser
ausgeliefert (da könnten ja Passwörter o.ä. drinstehen), sondern
_direkt_ auf dem Webserver ausgeführt und das Ergebnis (meist der
STDOUT, den das Skript erzeugt) wird an Deinen Browser geschickt.

Man könnte jetzt sagen, dass das im Webserver einen Callback
darstellt, aber der Begriff "Rückruf" passt dafür IMHO nicht.

> Da kommt je nach server etwas in html Format (wegen cgi) heraus,
> oder es wird einfach nur der Quelltext angezeigt.

Genau: Wenn im Webserver nicht konfiguriert ist "lasste alle *.py in diesem
Ordner von Python ausführen und schicke die Ergebnisse raus", wird er
einfach sagen "oh, eine Textdatei mit Quellcode drin, hier bitte".

Mit den Dateiendungen hat das aber auch wieder nur bedingt zu tun, die
meisten Webserver sind da flexibler konfigurierbar – und komplizierter
als CGI geht es auch, wobei das für einfache Dinge, wo keine Hochlast
gefahren wird, meiner Meinung nach immer noch ganz brauchbar ist. Je
weniger Parameter das Skript übergeben bekommt, umso besser ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

|||||||||\\\\__ __ __ __ __ __ (Dominoeffekt)

[Hermann Riemann]

Am 28.06.22 um 19:29 schrieb Andreas Kohlbach:

> Da bekomme ich (unter anderem)
>
> print output("Irgendwas", irgendwas)
>
> Die Datei (für Python2) mit
>
> python3 datei.py
>
> aufgerufen gibt
>
> print output("Irgendwas", irgendwas)
> ^
> SyntaxError: invalid syntax
>
> Fehlt da ein drittes Argument?

Hinter dem Wort print muss ( kommen.
als print ( output("Irgendwas", irgendwas) )
print ("a", a+b )
müsste gehen, wenn a und b bereits Variablen sind.
print ist ein Funktion,
die bei jedem Argument etwa
das Python2 etwa print str(eval(argument)) macht,
wobei der Zeilenvorschub ohne end=irgendwas
erst nach dem letzten Argument geschieht.
( irgenwas ersetzt hier den Zeilenvorschub)

Hermann
vermutend, Probleme wegen ISO utf8
sind haltbarer.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 28.06.22 um 20:04 schrieb Sieghard Schicktanz:

> Hallo Hermann Riemann,
>
> Du schriebst am Tue, 28 Jun 2022 07:26:46 +0200:
>
>>>> Die Hauptarbeit bei Python2 nach Python3
>>>> war bei mir die Änderung bei print.
> ...
>> Es reicht normalerweise
>> hinter print das Zeichen ( und am Ende das Zeichen ) zu einzufügen.
>> Also mit grep -rn print Verzeichnis_mit_Python_Programmen suchen
>> und das Ergebnis anschauen.
>
> Und dann kann man mit einem sed-Aufruf alles passend umbauen.

Ich bin nicht man.
sed habe ich praktisch nie programmiert.
Stattdessen früher C heute Python3 ( ganz früher FORTRAN)

Nach meinem Eindruck versagen etliche Linux tools,
wenn ungewohnte Anordnungen wie Zeilenwechsel
Wechsel der Tabellenstruktur (und deren header)
und weiteres stattfindet.
Die APL artige Tippvermeidung
mach das ganze schwerer lesbar und testbar,
wann es kompliziert wird.

Hermann
dessen ca 20 shellscripts im Mittel 3 Zeilen
lang sein könnten.


--
http://www.hermann-riemann.de

[Sieghard Schicktanz]

Hallo Christian Garbs,

Du schriebst am Tue, 28 Jun 2022 22:04:10 -0000 (UTC):

> >> Probiere eine Datei z.B. p
> > ...
> >> dann chmod 755 p
> >> dann ./p

...

> >> und mv p p.py
> >> erhalte ich bei ./p.py die Meldung:
> >> bash: ./p.py: Keine Berechtigung

...

> Wenn er _kein_ chmod 755 macht, p nach p.py umbenennt und dann ./p.py
> aufruft, sollte es normal sein, dass die Shell das als nicht
> ausführbare anmeckert, oder?

Wenn er vorher die Datei "p" ausführen konnte, dann muß das auch nach
dem Umbenennen gehen. "mv" ändert keine Dateirechte.
Aber vielleicht hat er ja auch was ganz anderes gemacht, er schreibt
"manchmal" schon recht konfus.

[Sieghard Schicktanz]

Hallo Andreas Kohlbach,

Du schriebst am Tue, 28 Jun 2022 13:29:14 -0400:

> print output("Irgendwas", irgendwas)

D.h. da soll unter py2 ein Ergebnis-String der Funktion "output"
ausgegeben werden.

> Die Datei (für Python2) mit
> python3 datei.py
> aufgerufen gibt
>
> print output("Irgendwas", irgendwas)
> ^
> SyntaxError: invalid syntax
>
> Fehlt da ein drittes Argument?

Nein, da fehlen die Klammern um den auszugebenden Text, der das
Ergebnis des (zuvor ausgeführten) Aufrus der Funktion "output" ist.
Kannste das verstehen?

[Holger Schauer]

On 10527 September 1993, Sieghard Schicktanz wrote:
>> Also mit grep -rn print Verzeichnis_mit_Python_Programmen suchen
>> und das Ergebnis anschauen.
> Und dann kann man mit einem sed-Aufruf alles passend umbauen.

Ihr wollt euch beide dringend
https://docs.python.org/3/library/2to3.html ansehen, glaube ich.

HTH,

Holger

--
--- http://blog.find-method.de/ ---
"Warum kostet Linux nichts?
Warum gibt es kein einheitliches Frontend?"
-- Aus "Wie starte ich einen Endlosthread ?", Teil 1327

[Hermann Riemann]

Am 30.06.22 um 10:58 schrieb Holger Schauer:

> On 10527 September 1993, Sieghard Schicktanz wrote:
>>> Also mit grep -rn print Verzeichnis_mit_Python_Programmen suchen
>>> und das Ergebnis anschauen.
>> Und dann kann man mit einem sed-Aufruf alles passend umbauen.
>
> Ihr wollt euch beide dringend
> https://docs.python.org/3/library/2to3.html ansehen, glaube ich.

Für mich zu spät.
Meine Umstellung war ca 2011
Und bei 2to3 gab es nach meiner schwachen Erinnerung
irgendwelche Probleme.

Die effektivste Neuerung danach war für mich das f Format.
Das .format, welches das c-typische % ablösen sollte,
fand ich kaum nützlich.

Hermann
der Textdateien seit längerem mit
l=open(name).readlines() liest
und seit gestern mit
open(name,"w").writelines(l) schreibt.

--
http://www.hermann-riemann.de

[Christian Garbs]

Mahlzeit!

Holger Schauer <Holger....@gmx.de> wrote:

> Ihr wollt euch beide dringend
> https://docs.python.org/3/library/2to3.html ansehen, glaube ich.

Oh, das tut ja mehr, als ich erwartet hätte – nicht, dass ich
abschätzen könnte, was es alles nicht tut ;-)

Mich wundert, dass lib2to3 deprecated ist (steht am Ende des Links):

| Deprecated since version 3.11, will be removed in version 3.13:
| Python 3.9 switched to a PEG parser (see PEP 617) while lib2to3 is
| using a less flexible LL(1) parser. Python 3.10 includes new
| language syntax that is not parsable by lib2to3’s LL(1) parser (see
| PEP 634). The lib2to3 module was marked pending for deprecation in
| Python 3.9 […]

lib2to3 soll doch Python 2 lesen und Python 3 ausspucken.
Warum wird es dann deprecated, wenn es Python >= 3.10 nicht mehr lesen
kann? Das soll es doch überhaupt nicht, die Konvertierung ist doch
nur für Python < 3.0 gedacht?

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Moderator not found. Begin flame war (Y/n)?

[Sieghard Schicktanz]

Hallo Holger Schauer,

Du schriebst am Thu, 30 Jun 2022 10:58:21 +0200:

> >> Also mit grep -rn print Verzeichnis_mit_Python_Programmen suchen
> >> und das Ergebnis anschauen.
> > Und dann kann man mit einem sed-Aufruf alles passend umbauen.
>
> Ihr wollt euch beide dringend
> https://docs.python.org/3/library/2to3.html ansehen, glaube ich.

warum?