Discussion:
The AWK Programming Language (2. Auflage)
(zu alt für eine Antwort)
Christian Weisgerber
2023-11-02 21:39:33 UTC
Permalink
Heute ist etwas überraschend das vorbestellte Aho/Kernighan/Weinberger,
_The AWK Programming Language_, 2. Auflage, 2024, eingetroffen.

Vielleicht ein Tipp für diejenigen, die sich eine Einführung in
awk(1) über die Manpage hinaus wünschen. Ich habe vor Jahrzehnten
_sed & awk_ aus der O'Reilly Nutshell-Reihe gelesen. Zeit, das mal
wieder etwas aufzufrischen.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Andreas Kohlbach
2023-11-02 23:06:54 UTC
Permalink
Post by Christian Weisgerber
Heute ist etwas überraschend das vorbestellte Aho/Kernighan/Weinberger,
_The AWK Programming Language_, 2. Auflage, 2024, eingetroffen.
Vielleicht ein Tipp für diejenigen, die sich eine Einführung in
awk(1) über die Manpage hinaus wünschen. Ich habe vor Jahrzehnten
_sed & awk_ aus der O'Reilly Nutshell-Reihe gelesen.
Ich auch. Könnte ziemlich genau 20 Jahre her sein.
Post by Christian Weisgerber
Zeit, das mal wieder etwas aufzufrischen.
Nutzte ich aber nie. Habe praktisch alles wieder vergessen, was im Buch
stand.

Ich finde es aber gut, dass es neue Doku gibt.
--
Andreas
Ulli Horlacher
2023-11-03 08:19:28 UTC
Permalink
Post by Christian Weisgerber
Heute ist etwas überraschend das vorbestellte Aho/Kernighan/Weinberger,
_The AWK Programming Language_, 2. Auflage, 2024, eingetroffen.
^^^^
Zurueck in die Zukunft? :-)
Post by Christian Weisgerber
Vielleicht ein Tipp für diejenigen, die sich eine Einführung in
awk(1) über die Manpage hinaus wünschen. Ich habe vor Jahrzehnten
_sed & awk_ aus der O'Reilly Nutshell-Reihe gelesen. Zeit, das mal
wieder etwas aufzufrischen.
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Ausser aus historischem Interesse, das gilt immer :-)
Und haben die Original-Autoren tatsaechlich ihr Werk ueberarbeitet?
Oder ist das nur ein "bug-fix release" wo in erster Linie Typografie und
Tippfehler korrigiert wurden?
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Christian Weisgerber
2023-11-03 13:21:05 UTC
Permalink
Post by Ulli Horlacher
Post by Christian Weisgerber
Heute ist etwas überraschend das vorbestellte Aho/Kernighan/Weinberger,
_The AWK Programming Language_, 2. Auflage, 2024, eingetroffen.
^^^^
Zurueck in die Zukunft? :-)
Wibbly wobbly, timey wimey.
Post by Ulli Horlacher
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Awk existiert immer noch, hat seine Nische und einen angenehm
überschaubaren Sprachumfang. Ich benutze es gelegentlich.
Post by Ulli Horlacher
Und haben die Original-Autoren tatsaechlich ihr Werk ueberarbeitet?
Ja! Ich meine beim Durchblättern --csv gesehen zu haben; es ist
also wirklich aktualisiert.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Christian Garbs
2023-11-03 20:24:10 UTC
Permalink
Mahlzeit!
Post by Christian Weisgerber
Ja! Ich meine beim Durchblättern --csv gesehen zu haben; es ist
also wirklich aktualisiert.
Meine Nutzung von awk(1) beschränkt sich primär auf sowas wie
'{print $2}', um das x. Wort aus jeder Zeile zu ziehen.¹
Und wenn dabei ein 'grep | awk' herauskommt, ziehe ich die Regexp
inzwischen mit in das awk-Skript. Mehr ist nicht drin.

Aber wenn es bei awk(1) inzwischen sowas wie --csv gibt, muss ich mir
das echt nochmal genauer angucken. Danke für den Hinweis!

Gruß
Christian

¹ Gibt's dafür eigentlich auch ein anderes Standard-Tool als awk(1)?
cut(1) ist raus, weil der Delimiter immer ein Zeichen ist, der würde
z.B. mehrere Leerzeichen in Folge als mehrere Fields zählen. Eine
Shell-Schleife wie 'while read -r _ _ keep _; do echo "$keep"; done'
ist mir zu unhandlich und selbst in Perl wird's länger als in awk(1).
--
....Christian.Garbs....................................https://www.cgarbs.de
"I do not feel obliged to believe that the same God who has endowed us
with sense, reason, and intellect has intended us to forego their use."
-- Galileo Galilei
Stefan Ram
2023-11-03 20:43:08 UTC
Permalink
Post by Christian Garbs
¹ Gibt's dafür eigentlich auch ein anderes Standard-Tool als awk(1)?
Hier zeige ich, wie man in Python eine Zeile in ihre Wörter zerlegen
kann. Dafür wird zunächst eine Beispieldatei angelegt. Warnung: Eine
eventuell vorhandene Datei gleichen Namens würde dabei überschrieben
werden! Dann werden die Zeilen gelesen und zerlegt. Schließlich wird
die Zerlegung "words" ausgegeben:

filename = 'tmp202311032130170100_tmp_DML.txt'

def datei_schreiben():
with open( filename, 'w' )as out_stream:
print( 'alpha beta gamma', file=out_stream )
datei_schreiben()

with open( filename )as in_stream:
for line in in_stream:
words = line.split()
print( words )

. Die Ausgabe lautet dann:

['alpha', 'beta', 'gamma']

. Man könnte im Quelltext dann "alpha" beispielsweise als "words[ 0 ]"
erhalten.

Solche elementaren Dinge gehen ohne Zusatzmodule. Es wird nicht einmal
ein Standardmodul benötigt.

Um hinter dem Skript aufzuräumen, müßte in diesem Fall die Datei
"tmp202311032130170100_tmp_DML.txt" wieder gelöscht werden. Dies
könnte man natürlich auch mit Python machen, aber ich habe es hier
zur Vereinfachung weggelassen. "DML" verwende ich für "delete me
later".
Ulli Horlacher
2023-11-03 22:07:08 UTC
Permalink
Post by Stefan Ram
Post by Christian Garbs
¹ Gibt's dafür eigentlich auch ein anderes Standard-Tool als awk(1)?
Hier zeige ich, wie man in Python eine Zeile in ihre Wörter zerlegen
kann. Dafür wird zunächst eine Beispieldatei angelegt. Warnung: Eine
eventuell vorhandene Datei gleichen Namens würde dabei überschrieben
werden! Dann werden die Zeilen gelesen und zerlegt. Schließlich wird
filename = 'tmp202311032130170100_tmp_DML.txt'
print( 'alpha beta gamma', file=out_stream )
datei_schreiben()
words = line.split()
print( words )
Also 9 Zeilen, wo es in awk 1 waere. DAS nenn ich Fortschritt :-}
Post by Stefan Ram
Um hinter dem Skript aufzuräumen, müßte in diesem Fall die Datei
"tmp202311032130170100_tmp_DML.txt" wieder gelöscht werden.
Und DAS auch noch.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Ulli Horlacher
2023-11-03 20:47:02 UTC
Permalink
Post by Christian Weisgerber
Awk existiert immer noch, hat seine Nische und einen angenehm
überschaubaren Sprachumfang. Ich benutze es gelegentlich.
https://fex.belwue.de/fstools/pawk.html
Post by Christian Weisgerber
Post by Ulli Horlacher
Und haben die Original-Autoren tatsaechlich ihr Werk ueberarbeitet?
Ja! Ich meine beim Durchblättern --csv gesehen zu haben; es ist
also wirklich aktualisiert.
Erstaunlich!
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Christian Weisgerber
2023-12-09 16:22:59 UTC
Permalink
Post by Christian Weisgerber
Post by Ulli Horlacher
Und haben die Original-Autoren tatsaechlich ihr Werk ueberarbeitet?
Ja! Ich meine beim Durchblättern --csv gesehen zu haben; es ist
also wirklich aktualisiert.
Ich habe jetzt die ersten drei Kapitel gelesen und da wird ständig
auf Dinge Bezug genommen, die es 1988 zur Zeit der ersten Auflage
noch nicht gab: das Web, Wikipedia, Python, usw. usf.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Marcel Logen
2024-02-24 10:44:09 UTC
Permalink
Post by Christian Weisgerber
Ich habe jetzt die ersten drei Kapitel gelesen und da wird ständig
auf Dinge Bezug genommen, die es 1988 zur Zeit der ersten Auflage
noch nicht gab: das Web, Wikipedia, Python, usw. usf.
Danke für den Hinweis! Habe mir das Buch gekauft.

Es ist BTW auch in der man page von awk auf OpenBSD erwähnt
(im Abschnitt SEE ALSO).

<https://man.openbsd.org/OpenBSD-7.4/awk#SEE_ALSO>

Zum Buch gibt es eine Website: <https://www.awk.dev/>.

---

Derzeit stehe ich vor einem Problem mit dem OpenBSD-awk, welches
z. B. unter Debian mit mawk nicht auftritt:

Ich möchte hexadezimale Zahlen in dezimale umwandeln. Das scheint
mit dem OpenBSD-awk nicht zu funktionieren. Aus der man page:

| Hexadecimal values (allowed since C99) convert to zero, as
| they did prior to C99.

Das mawk gibt (wie gewünscht) aus:

| ***@n14:~$ echo '0x5E' | mawk '{print 0+$1}'
| 94

Geht auch mit kleinem e.

Anwendungsfall: Ich möchte mit awk die erste Spalte mit den
hexadezimalen Werten aus der Datei

<https://www.unicode.org/Public/15.1.0/ucd/UnicodeData.txt>
(1,8 MB)

dezimal ausgeben. Vielleicht hat ja jemand eine Idee, wie das
mit dem OpenBSD-awk gehen könnte. Sonst nehme ich halt Python3
dafür.

Im erwähnten Buch fand ich auf die Schnelle nichts zu diesem
Thema.

Marcel hrdl (585141)
--
╭──────╮ ╭──────╮ ╭─╮ ╭──────╮ ╭─╮ ╭─╮ ╭─
│ ╭───╯ ╭──╮ ╭─╯ ╰──╯ │ ╰──╮ ╰──╮ ╭─╮ │ ╰─────╯ ╰─────╯
─╯ ╰─╮ ╭──╯ │ ╭─╯ ╰─╮ │ ╰───╯ ╰─╯
╰─╯ ╰──╯ ╰───╯ 92a6d8
Peter J. Holzer
2024-02-24 11:18:54 UTC
Permalink
Post by Marcel Logen
Ich möchte hexadezimale Zahlen in dezimale umwandeln. Das scheint
| Hexadecimal values (allowed since C99) convert to zero, as
| they did prior to C99.
Ich habe eine Weile gebraucht, um herauszufinden, dass hier vermutlich
die C-Funktion strtod gemeint ist. Die hat in C89 nur dezimale
Floatingpointzahlen akzeptiert, in C11 (und vermutlich auch schon C99)
aber auch hexadezimale.

Die Funktion strtol (die unter anderem hexadezimale Integers akzeptiert)
existiert seit mindestens C89. In C Sourcecode sind hexadezimale
(Integer-)Konstanten bereits in K&R I erwähnt.

hp
Marcel Logen
2024-02-24 12:11:57 UTC
Permalink
Post by Peter J. Holzer
Post by Marcel Logen
Ich möchte hexadezimale Zahlen in dezimale umwandeln. Das scheint
| Hexadecimal values (allowed since C99) convert to zero, as
| they did prior to C99.
Ich habe eine Weile gebraucht, um herauszufinden, dass hier vermutlich
die C-Funktion strtod gemeint ist. Die hat in C89 nur dezimale
Floatingpointzahlen akzeptiert, in C11 (und vermutlich auch schon C99)
aber auch hexadezimale.
strtod() ist wohl gemeint. Ich hatte den oben zitierten Satz hier
<https://man.openbsd.org/OpenBSD-7.4/awk#UNUSUAL_FLOATING-POINT_VALUES>
entnommen.

Aber:

| awk now follows GNU awk, and prefilters string values before
| attempting to convert them to numbers, as follows:
[... und dann folgt das oben von mir Zitierte ...]

Ich habe hier gerade kein GNU awk zur Verfügung, um das zu prüfen.

Marcel huft (588285)
--
╭────────╮ ╭────╮ ╭─────╮
╭──────╮ ╰─────╮ ╰────╮ ╭────╯ ╭─╯ ╭─╮ ╭──╯ ╭─╯ ╭─╮
╰─╮ ╭─╯ ╭─╮ ╭──╯ ╭────╯ ╭──╮ ╭─╯ ╰────╯ │ ╰─╮ │ ╭──╯ │ ╭──
╭──╯ ╰───╯ ╰─╯ ╰───────╯ ╰─╯ 6d9cc1 ╰────╯ ╰─╯ ╰─╯
Michael Bäuerle
2024-02-25 09:11:58 UTC
Permalink
Post by Marcel Logen
Post by Peter J. Holzer
Post by Marcel Logen
Ich möchte hexadezimale Zahlen in dezimale umwandeln. Das scheint
| Hexadecimal values (allowed since C99) convert to zero, as
| they did prior to C99.
Ich habe eine Weile gebraucht, um herauszufinden, dass hier vermutlich
die C-Funktion strtod gemeint ist. Die hat in C89 nur dezimale
Floatingpointzahlen akzeptiert, in C11 (und vermutlich auch schon C99)
aber auch hexadezimale.
strtod() ist wohl gemeint. Ich hatte den oben zitierten Satz hier
<https://man.openbsd.org/OpenBSD-7.4/awk#UNUSUAL_FLOATING-POINT_VALUES>
entnommen.
| awk now follows GNU awk, and prefilters string values before
[... und dann folgt das oben von mir Zitierte ...]
Ich habe hier gerade kein GNU awk zur Verfügung, um das zu prüfen.
Diverse ältere awk-Versionen ergeben bei mir kein einheitliches Bild:

$ mawk -W version
mawk 1.3.4 20171017
[...]
$ echo '0x5E' | mawk '{print 0+$1}'
94

$ gawk --version
GNU Awk 5.0.0, API: 2.0 (GNU MPFR 4.0.2, GNU MP 6.1.2)
[...]
$ echo '0x5E' | gawk '{print 0+$1}'
0

$ nawk --version
awk version 20121220
$ echo '0x5E' | nawk '{print 0+$1}'
94

Und noch ein UNIX® awk (von HP-UX 11.11):

$ echo '0x5E' | awk '{print 0+$1}'
0

Christian Weisgerber
2024-02-24 22:19:33 UTC
Permalink
Post by Marcel Logen
Derzeit stehe ich vor einem Problem mit dem OpenBSD-awk,
Das ist übrigens onetrueawk, also die im genannten Buch beschriebene
Implementierung. Nur die Manpage ist neu geschrieben.
Post by Marcel Logen
Anwendungsfall: Ich möchte mit awk die erste Spalte mit den
hexadezimalen Werten aus der Datei
<https://www.unicode.org/Public/15.1.0/ucd/UnicodeData.txt>
(1,8 MB)
dezimal ausgeben. Vielleicht hat ja jemand eine Idee, wie das
mit dem OpenBSD-awk gehen könnte.
Halt per Hand konvertieren:

awk -F';' '{
len = length($1)
sum = 0
for(i = 1; i <= len; i++) {
sum *= 16
sum += index("0123456789ABCDEF", substr($1, i, 1)) - 1
};
print sum
}'


Nebenbei: /usr/src/gnu/usr.bin/perl/lib/unicore/UnicodeData.txt
--
Christian "naddy" Weisgerber ***@mips.inka.de
Marcel Logen
2024-02-24 23:45:14 UTC
Permalink
Post by Christian Weisgerber
Post by Marcel Logen
Derzeit stehe ich vor einem Problem mit dem OpenBSD-awk,
Das ist übrigens onetrueawk, also die im genannten Buch beschriebene
Implementierung. Nur die Manpage ist neu geschrieben.
Den Namen "onetrueawk" finde ich nicht im Index des Buches,
und auch im Vorwort und im Epilog scheint er nicht vorzukommen.
Post by Christian Weisgerber
Post by Marcel Logen
Anwendungsfall: Ich möchte mit awk die erste Spalte mit den
hexadezimalen Werten aus der Datei
<https://www.unicode.org/Public/15.1.0/ucd/UnicodeData.txt>
(1,8 MB)
dezimal ausgeben. Vielleicht hat ja jemand eine Idee, wie das
mit dem OpenBSD-awk gehen könnte.
Ja, daran hatte ich auch schon gedacht.
Post by Christian Weisgerber
awk -F';' '{
len = length($1)
sum = 0
for(i = 1; i <= len; i++) {
sum *= 16
sum += index("0123456789ABCDEF", substr($1, i, 1)) - 1
};
print sum
}'
Das sieht IMHO recht elegant aus.

Ich hätte wahrscheinlich die Hex-Ziffern stur von rechts nach
links ausgelesen und dann mit dem jeweiligen Stellenwert multi-
pliziert.
Post by Christian Weisgerber
Nebenbei: /usr/src/gnu/usr.bin/perl/lib/unicore/UnicodeData.txt
Die Original-Datei von der Unicode-Site scheint mir jedoch
aktueller zu sein.

Marcel igkj (606867)
--
╭────────╮ ╭────────╮
╭─╮ ╭─╯ ╭───╮ ╰───╮ ╰─╮ ╭───╯ ╭─╮
╯ │ ╰────╯ ╭─╯ │ ╭─╮ ╭───╮ ╭──╯ ╰──╮ ╭─╯ ╰─╮ ╭──╮
╰─────────╯ ╰──────────╯ ╰───╯ ╰─╯ 075d1d ╰──╯ ╰──╯ ╰────
fritz_s
2024-02-25 00:03:00 UTC
Permalink
Post by Christian Weisgerber
Post by Marcel Logen
Derzeit stehe ich vor einem Problem mit dem OpenBSD-awk,
Das ist übrigens onetrueawk, also die im genannten Buch beschriebene
Implementierung. Nur die Manpage ist neu geschrieben.
Post by Marcel Logen
Anwendungsfall: Ich möchte mit awk die erste Spalte mit den
hexadezimalen Werten aus der Datei
<https://www.unicode.org/Public/15.1.0/ucd/UnicodeData.txt>
(1,8 MB)
dezimal ausgeben. Vielleicht hat ja jemand eine Idee, wie das
mit dem OpenBSD-awk gehen könnte.
awk -F';' '{
len = length($1)
sum = 0
for(i = 1; i <= len; i++) {
sum *= 16
sum += index("0123456789ABCDEF", substr($1, i, 1)) - 1
};
print sum
}'
Wenn's auch was anderes als awk sein kann - dc:
z.B. (mit 5E):
echo 16 i 5E p | dc
94
oder als bash function
function hex2dec { typeset -u val=$1; echo 16i $val p | dc; }
hex2dec 5e
94
--
fs (***@gmail.com)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Without facts, the decision cannot be made logically. You must rely on
your human intuition. -- Spock, "Assignment: Earth", stardate unknown
Urs Janßen
2024-02-25 03:27:03 UTC
Permalink
Post by Christian Weisgerber
awk -F';' '{
len = length($1)
sum = 0
for(i = 1; i <= len; i++) {
sum *= 16
sum += index("0123456789ABCDEF", substr($1, i, 1)) - 1
};
print sum
}'
evtl. noch minimal fehlerbehandlung dazu

#v+
awk -F';' '{
len = length($1)
sum = 0
for(i = 1; i <= len; i++) {
cur = index("0123456789ABCDEF", toupper(substr($1, i, 1))) - 1
if (cur < 0)
break
else {
sum *= 16
sum += cur
}
};
print sum
}'
#v-
Stefan Möding
2023-11-03 13:31:27 UTC
Permalink
Post by Ulli Horlacher
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen? Bei Perl kann man sich nur mühsam an die
korrekte Syntax erinnern und Python hat zwar genau dafür ein Modul, was
aber lokal nicht installiert ist: AWK hat dafür bei mir seinen Platz.
--
Stefan
Christian Weisgerber
2023-11-03 14:59:13 UTC
Permalink
Post by Stefan Möding
Post by Ulli Horlacher
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen?
Zum einen das. Zum andern, wann man mal wieder z.B. ein paar tausend
Makefiles ändern muss, dann kann man dafür ruhig ein Wegwerfskript
./a schreiben, das mit "#!/usr/bin/awk -f" anfängt.
Post by Stefan Möding
Bei Perl kann man sich nur mühsam an die
korrekte Syntax erinnern
Und muss dann erst einmal in der perl(1) Index-Manpage nachschlagen,
welche eigentlichen, überlangen Manpages denn in Frage kommen.
There is such a thing as too much.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Ulli Horlacher
2023-11-03 20:54:25 UTC
Permalink
Post by Christian Weisgerber
Post by Stefan Möding
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen?
Zum einen das. Zum andern, wann man mal wieder z.B. ein paar tausend
Makefiles ändern muss, dann kann man dafür ruhig ein Wegwerfskript
./a schreiben, das mit "#!/usr/bin/awk -f" anfängt.
Bei Perl braucht es fuer so was idR nicht mal ein Skript, das geht direkt
aus der Shell raus mit einem Einzeiler.

Ab und zu verwende ich aber auch noch awk. Meist aus Nostalgie :-)
(Ich hab awk noch unter VMS 4 gelernt)
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marc Haber
2023-11-04 08:31:00 UTC
Permalink
Post by Ulli Horlacher
Post by Christian Weisgerber
Post by Stefan Möding
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen?
Zum einen das. Zum andern, wann man mal wieder z.B. ein paar tausend
Makefiles ändern muss, dann kann man dafür ruhig ein Wegwerfskript
./a schreiben, das mit "#!/usr/bin/awk -f" anfängt.
Bei Perl braucht es fuer so was idR nicht mal ein Skript, das geht direkt
aus der Shell raus mit einem Einzeiler.
Wenn man sich an die Syntax erinnert, ja. awk sitzt bei mir um einiges
flüssiger.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Ulli Horlacher
2023-11-04 08:51:39 UTC
Permalink
Post by Marc Haber
Post by Ulli Horlacher
Bei Perl braucht es fuer so was idR nicht mal ein Skript, das geht direkt
aus der Shell raus mit einem Einzeiler.
Wenn man sich an die Syntax erinnert, ja. awk sitzt bei mir um einiges
flüssiger.
Also Stand vor 35 Jahren.
Bist du nicht derjenige, der andere auffordert mal was neues zu lernen? :-)

Ich hatte ja auch mit awk begonnen, hab mich dann aber an dessen
Unzulaenglichkeiten geaergert. Substitute Funktion kam erst mit GNU awk,
das wiederum nicht ueberall verfuegbar war.
Perl hat dann alle Probleme geloest.
In Kombination mit bash als CLI hab ich noch nichts besseres gefunden.

awk verwende ich trotzdem immer noch fuer einfache Anwendungen.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marc Haber
2023-11-04 10:18:52 UTC
Permalink
Post by Ulli Horlacher
Post by Marc Haber
Post by Ulli Horlacher
Bei Perl braucht es fuer so was idR nicht mal ein Skript, das geht direkt
aus der Shell raus mit einem Einzeiler.
Wenn man sich an die Syntax erinnert, ja. awk sitzt bei mir um einiges
flüssiger.
Also Stand vor 35 Jahren.
Ich mache erst seit 25 Jahren Unix.
Post by Ulli Horlacher
Bist du nicht derjenige, der andere auffordert mal was neues zu lernen? :-)
Ja, aber perl ist nicht "was neues".
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Ulli Horlacher
2023-11-04 11:46:05 UTC
Permalink
Post by Marc Haber
Post by Ulli Horlacher
Post by Marc Haber
Post by Ulli Horlacher
Bei Perl braucht es fuer so was idR nicht mal ein Skript, das geht direkt
aus der Shell raus mit einem Einzeiler.
Wenn man sich an die Syntax erinnert, ja. awk sitzt bei mir um einiges
flüssiger.
Also Stand vor 35 Jahren.
Ich mache erst seit 25 Jahren Unix.
Dann hast du schon damals (ver-)altes Zeug gelernt. Machts nicht besser.
Post by Marc Haber
Post by Ulli Horlacher
Bist du nicht derjenige, der andere auffordert mal was neues zu lernen? :-)
Ja, aber perl ist nicht "was neues".
Wir reden hier ueber awk. Und da ist Perl neuer - und ein Superset.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Thomas Hochstein
2023-11-04 12:09:39 UTC
Permalink
Post by Marc Haber
Ja, aber perl ist nicht "was neues".
Das ist eine Frage der Perspektive. ;)
Stefan Ram
2023-11-03 15:34:52 UTC
Permalink
Post by Stefan Möding
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen? Bei Perl kann man sich nur mühsam an die
korrekte Syntax erinnern und Python hat zwar genau dafür ein Modul, was
aber lokal nicht installiert ist: AWK hat dafür bei mir seinen Platz.
|Python's obviously a great tool for all kinds of programming things,
|and I would say, if you're only gonna use one programming
|language in your live, Python will probably the right one.
Brian Kernighan (in "Coffee with Brian Kernighan")
Stefan Ram
2023-11-03 15:54:21 UTC
Permalink
Post by Stefan Ram
|Python's obviously a great tool for all kinds of programming things,
|and I would say, if you're only gonna use one programming
|language in your live, Python will probably the right one.
Brian Kernighan (in "Coffee with Brian Kernighan")
3s/probably the/probably be the/
Christian Weisgerber
2023-11-03 16:32:33 UTC
Permalink
Post by Stefan Ram
Post by Stefan Ram
|Python's obviously a great tool for all kinds of programming things,
|and I would say, if you're only gonna use one programming
|language in your live, Python will probably the right one.
Brian Kernighan (in "Coffee with Brian Kernighan")
3s/probably the/probably be the/
3s/live/life/
--
Christian "naddy" Weisgerber ***@mips.inka.de
Markus Schaaf
2023-11-03 15:56:06 UTC
Permalink
Post by Stefan Ram
|Python's obviously a great tool for all kinds of programming things,
|and I would say, if you're only gonna use one programming
|language in your live, Python will probably the right one.
Brian Kernighan (in "Coffee with Brian Kernighan")
Das Problem bei Python ist nicht die Sprache, die ist prima,
sondern die fragile Laufzeitumgebung.
Stefan Ram
2023-11-03 16:12:00 UTC
Permalink
Post by Markus Schaaf
Das Problem bei Python ist nicht die Sprache, die ist prima,
sondern die fragile Laufzeitumgebung.
Ich bin mir nicht sicher, ob ich den Punkt richtig verstehe,
auf den Du hinaus willst.

Für eine in Python geschriebene Anwendung, wie zum Beispiel
CherryTree, gibt es fertig "kompilierte" Versionen, zum
Beispiel Exes für Windows, die der Endanwender so einfach
installieren und benutzen kann wie andere Anwendungen auch.

Wenn man selber Skripte schreiben will, kommt man mit einer der
aktuellen Versionen von Python schon sehr weit. Alles, was man
mit AWK kann, sollte schon mit den Standardmodulen möglich sein.
Will man Zusatzmodule installieren und gleichzeitig eine ganz
neue Python-Version verwenden, dann könnte es sein, daß mal ein
Zusatzmodul für die neuste Python-Version noch nicht verfügbar ist.
Markus Schaaf
2023-11-03 16:30:19 UTC
Permalink
Post by Stefan Ram
Post by Markus Schaaf
Das Problem bei Python ist nicht die Sprache, die ist prima,
sondern die fragile Laufzeitumgebung.
Ich bin mir nicht sicher, ob ich den Punkt richtig verstehe,
auf den Du hinaus willst.
Ich hab da ein paar Jahre altes Programm, das größtenteils in
Python (2) geschrieben ist und heute ohne extreme Handstände
nicht mehr läuft. Dann erlebe ich ab und zu seltsame Fehler bei
irgendwelchem Python-Kram, der daher kommt, dass es irgendeine
subtile Änderung von einer Minor-Version zur nächsten gab. Dann
läuft auf einer älteren Maschine momentan kein Borg mehr, weil
irgendein Python-Modul das Update nicht überlebt hat, da der
Python-Krempel extrem fragil zu bauen ist und seit einiger Zeit
sogar Rust braucht.

An so eine Scheiße kann ich mich weder bei Perl noch bei Awk o.ä.
erinnern.

MfG
Marc Haber
2023-11-03 17:39:54 UTC
Permalink
Post by Markus Schaaf
Ich hab da ein paar Jahre altes Programm, das größtenteils in
Python (2) geschrieben ist und heute ohne extreme Handstände
nicht mehr läuft. Dann erlebe ich ab und zu seltsame Fehler bei
irgendwelchem Python-Kram, der daher kommt, dass es irgendeine
subtile Änderung von einer Minor-Version zur nächsten gab. Dann
läuft auf einer älteren Maschine momentan kein Borg mehr, weil
irgendein Python-Modul das Update nicht überlebt hat, da der
Python-Krempel extrem fragil zu bauen ist und seit einiger Zeit
sogar Rust braucht.
Und dass die Python-Community venv als die allgemeingültige
Universallösung für den Produktivbetrieb sieht, anstelle zu verstehen,
dass man sowas eigentlich wegdockern oder einazuren¹ muss.

Grüße
Marc

¹ gesprochen "einäschern"
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Christian Garbs
2023-11-03 20:13:53 UTC
Permalink
Mahlzeit!
Post by Marc Haber
Und dass die Python-Community venv als die allgemeingültige
Universallösung für den Produktivbetrieb sieht, anstelle zu verstehen,
dass man sowas eigentlich wegdockern oder einazuren¹ muss.
Ich hätte jetzt spontan erwartet, dass man sich im Build ein venv
zusammenbaut und genau das Verzeichnis dann (zusammen mit der
Python-Runtime und den Baselibs) wegdockert.

Hat das irgendwelche Fallstricke?
Post by Marc Haber
¹ gesprochen "einäschern"
Den merke ich mir!

Gruß
Chris "ich dockere primär Java, JavaScript, etwas Bash und einmal Perl" tian
--
....Christian.Garbs....................................https://www.cgarbs.de
"The only real way to look younger is not to be born so soon."
-- Charles Schulz, "Things I've Had to Learn Over and
Over and Over"
Peter J. Holzer
2023-11-03 20:59:03 UTC
Permalink
Post by Markus Schaaf
Post by Stefan Ram
Post by Markus Schaaf
Das Problem bei Python ist nicht die Sprache, die ist prima,
sondern die fragile Laufzeitumgebung.
Ich bin mir nicht sicher, ob ich den Punkt richtig verstehe,
auf den Du hinaus willst.
Ich hab da ein paar Jahre altes Programm, das größtenteils in
Python (2) geschrieben ist
Python2 ist seit 14 Jahren (dem Release von 2.7) deprecated und seit 3
Jahren endgültig tot, soweit es die Python Foundation betrifft
(Linux-Distributionen mit Long Term Support pflegen das natürlich noch
weiter, aber das sind aber vermutlich auch nur mehr Security-Fixes und
ganz schlimme Bugs).

Wenn jemand vor "ein paar Jahren" noch ein Programm in Python2
geschrieben hat, dann war das fahrlässig.
Post by Markus Schaaf
und heute ohne extreme Handstände nicht mehr läuft.
Der extreme Handstand besteht wahrscheinlich darin, Python2 zu
verwenden. Das bedingt dann eventuell auch eine ältere
Linux-Distribution (Ubuntu 22.04 enthält noch Python 2.7, Debian 12
nicht mehr). Und wer auch immer Dein Programm geschrieben hat, sollte
möglichst die exakten Versionsnummern verwendeter PyPI-Packages (sofern
verwendet) dokumentiert haben. Am besten eine VM bauen und nie mehr
angreifen.

Auf Python3 zu portieren wäre mittelfristig aber klüger.
Post by Markus Schaaf
Dann erlebe ich ab und zu seltsame Fehler bei irgendwelchem
Python-Kram, der daher kommt, dass es irgendeine subtile Änderung von
einer Minor-Version zur nächsten gab. Dann läuft auf einer älteren
Maschine momentan kein Borg mehr, weil irgendein Python-Modul das
Update nicht überlebt hat, da der Python-Krempel extrem fragil zu
bauen ist und seit einiger Zeit sogar Rust braucht.
Was für ein System verwendest Du, auf dem Du Python selber bauen musst?

Unter Linux sollte es sowohl einen leidlich neuen Python-Core als auch
die üblichen Packages geben, und wenn mal ein Paket fehlt, ist »pip
install« meiner Erfahrung nach ziemlich problemlos (zugebenermaßen sind
meine Linux-Systeme ziemlich mainstream).
Post by Markus Schaaf
An so eine Scheiße kann ich mich weder bei Perl noch bei Awk o.ä.
erinnern.
Bei Perl hatte ich durchaus auch schon (mehrmals) den Fall, dass ich
Code wegen Änderungen im Core (geringfügig) umschreiben musste. Und bei
CPAN-Modulen variiert die Langzeitstabilität sowieso drastisch.

Awk ist m.E. mit Perl oder Python nicht zu vergleichen.

hp
Stefan Reuther
2023-11-03 17:33:26 UTC
Permalink
Post by Stefan Ram
Post by Markus Schaaf
Das Problem bei Python ist nicht die Sprache, die ist prima,
sondern die fragile Laufzeitumgebung.
Ich bin mir nicht sicher, ob ich den Punkt richtig verstehe,
auf den Du hinaus willst.
Für eine in Python geschriebene Anwendung, wie zum Beispiel
CherryTree, gibt es fertig "kompilierte" Versionen, zum
Beispiel Exes für Windows, die der Endanwender so einfach
installieren und benutzen kann wie andere Anwendungen auch.
Bei mir sieht das so aus, dass ich von irgendwoher ein Python-Skript
bekomme, und dann erstmal drei Tage gegen den Package-Manager kämpfe,
bis ich alle Dependencies in den richtigen Versionen zusammen habe. Die
meisten in Version "0.x", was eine prima Ausrede ist, zwischen "0.4" und
"0.4.2" die API inkompatibel zu ändern.

Das ist nicht das, was ich mir vorstelle, wenn jemand mit "batteries
included" wirbt.

In Perl ist mir das in dem Ausmaß noch nicht passiert. Sicherlich auch,
weil ich mir da nur das Modul `IO::Socket::SSL` aus der Library hole und
die paar Zeilen Code für HTTPS/POP3S/SMTPS mal eben selber
runterschreibe, anstatt ewig nach was fertigem zu suchen :)


Stefan
Peter J. Holzer
2023-11-03 21:28:03 UTC
Permalink
Post by Stefan Reuther
Post by Stefan Ram
Post by Markus Schaaf
Das Problem bei Python ist nicht die Sprache, die ist prima,
sondern die fragile Laufzeitumgebung.
Ich bin mir nicht sicher, ob ich den Punkt richtig verstehe,
auf den Du hinaus willst.
Für eine in Python geschriebene Anwendung, wie zum Beispiel
CherryTree, gibt es fertig "kompilierte" Versionen, zum
Beispiel Exes für Windows, die der Endanwender so einfach
installieren und benutzen kann wie andere Anwendungen auch.
Bei mir sieht das so aus, dass ich von irgendwoher ein Python-Skript
bekomme, und dann erstmal drei Tage gegen den Package-Manager kämpfe,
bis ich alle Dependencies in den richtigen Versionen zusammen habe.
Da hat der Autor geschlampt.

(Zugeben: Ich bin auch schlampig. Mein requirements.txt ist absichtlich
minimal gehalten, aber das führt manchmal zu Überraschungen. Momentan
ist der Plan, immer zwei Files zu haben: Ein manuell gewartetes
requirements.txt und ein automatisch erstelltes requirements-frozen.txt
(analog zu package.json und package-lock.json in npm). Aber ob das so
funktioniert, wie ich es mir vorstelle, werde ich erst in ein paar
Jahren wissen.)

Es kann sein, dass es da einen Kultur-Unterschied gibt. In meiner
aktiven Perl-Zeit war CPAN eine wichtige Ressource, aber man hat das
gezielt und überlegt eingesetzt.

In der Python-Welt (und noch viel mehr in der JavaScript-Welt) ist die
Suche nach fertigen Packages selbst für triviale Aufgaben die
Default-Option.

Ist aber vielleicht einfach nur die Stackoverflow-Generation.
Post by Stefan Reuther
Die meisten in Version "0.x", was eine prima Ausrede ist, zwischen
"0.4" und "0.4.2" die API inkompatibel zu ändern.
Das ist nicht das, was ich mir vorstelle, wenn jemand mit "batteries
included" wirbt.
Mit den "Batterien" ist die Standard-Library gemeint, *nicht* PyPI.

Und die Standard-Library enthält bei Python doch einiges, wofür man bei
Perl auf CPAN zurückgreifen muss (von C ganz zu schweigen).
Post by Stefan Reuther
In Perl ist mir das in dem Ausmaß noch nicht passiert. Sicherlich auch,
weil ich mir da nur das Modul `IO::Socket::SSL` aus der Library hole und
die paar Zeilen Code für HTTPS/POP3S/SMTPS mal eben selber
runterschreibe, anstatt ewig nach was fertigem zu suchen :)
Es steht Dir frei, das in Python auch zu machen. Da hast Du TLS sogar in
der Standard-Library, brauchst also gar kein externes Paket. (und
HTTP(S), POP und SMTP auch.)

hp
Ulli Horlacher
2023-11-03 20:57:02 UTC
Permalink
Post by Stefan Ram
Wenn man selber Skripte schreiben will, kommt man mit einer der
aktuellen Versionen von Python schon sehr weit. Alles, was man
mit AWK kann, sollte schon mit den Standardmodulen möglich sein.
Nicht direkt aus der Shell heraus und man braucht 3-5 mal so viel Code,
Untauglich fuer adhoc scripting.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Peter J. Holzer
2023-11-03 20:13:52 UTC
Permalink
Post by Stefan Ram
|Python's obviously a great tool for all kinds of programming things,
|and I would say, if you're only gonna use one programming
^^ ^^^^ ^^^^^^^
Post by Stefan Ram
|language in your live,
Ex falso quodlibet. Ich habe schon ca. ein Dutzend Programmiersprachen
benutzt und auch wenn ich manche davon ziemlich sicher nie mehr
verwenden werde (COBOL) und etwas dazu neige, meine aktuelle
Hauptprogrammiersprache auch dort einzusetzen, wo sie nicht mehr ideal
ist, werde ich wohl nie nur eine Programmiersprache verwenden.
Post by Stefan Ram
|Python will probably the right one.
Brian Kernighan (in "Coffee with Brian Kernighan")
Ich stimme Kernighan zu. Wenn jemand noch nie programmiert hat und eine
Programmiersprache lernen will, ist Python eine gute Wahl. Auch wenn
jemand schon Programmiererfahrung in anderen Sprachen hat, aber in
seinem Kopf nur Platz für *eine* Programmiersprache ist (z.B. weil
andere Dinge wichtiger sind[1]) ist Python vermutlich in der engeren
Auswahl.

hp

[1] Shocking, I know.
Stefan Reuther
2023-11-03 17:25:11 UTC
Permalink
Post by Stefan Möding
Post by Ulli Horlacher
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen? Bei Perl kann man sich nur mühsam an die
korrekte Syntax erinnern und Python hat zwar genau dafür ein Modul, was
aber lokal nicht installiert ist: AWK hat dafür bei mir seinen Platz.
Bei mir ist's halt inzwischen andersrum: ich erinner mich eher an die
Syntax von Perl als die von awk. Auch wenn mein Linux-Leben mit awk
begann...


Stefan
Thomas Dorner
2023-11-03 20:24:20 UTC
Permalink
Post by Stefan Reuther
Post by Stefan Möding
Post by Ulli Horlacher
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen? Bei Perl kann man sich nur mühsam an die
korrekte Syntax erinnern und Python hat zwar genau dafür ein Modul, was
aber lokal nicht installiert ist: AWK hat dafür bei mir seinen Platz.
Bei mir ist's halt inzwischen andersrum: ich erinner mich eher an die
Syntax von Perl als die von awk. Auch wenn mein Linux-Leben mit awk
begann...
Full ACK, bei mir war's genauso, aber seit ich Perl 5.5 auf eine
exotische Hardware portiert habe, um dort die Skript Performance
deutlich zu verbessern, habe ich AWK so gut wie nie wieder benutzt.

Viele Grüße, Thomas

PS: Schon das Perl Configure Skript mit seinen teilweise netten
Kommentaren hat richtig Spaß gemacht. :-)
--
Adresse gilt nur kurzzeitig!
Ulli Horlacher
2023-11-03 20:50:07 UTC
Permalink
Post by Stefan Möding
Post by Ulli Horlacher
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen? Bei Perl kann man sich nur mühsam an die
korrekte Syntax erinnern
Perl Syntax ist an AWK angelehnt und nicht komplizierter.
Wer allerdings nur AWK kennt, tut sich mit allem anderen schwer :-)
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Stefan Reuther
2023-11-04 09:08:39 UTC
Permalink
Post by Ulli Horlacher
Post by Stefan Möding
Post by Ulli Horlacher
Welchen Grund gibt es heutzutage sich damit noch zu beschaeftigen?
Hat man nicht immer mal eine Ad-Hoc Pipeline, wo schnell ein paar Daten
verwursten werden sollen? Bei Perl kann man sich nur mühsam an die
korrekte Syntax erinnern
Perl Syntax ist an AWK angelehnt und nicht komplizierter.
Wer allerdings nur AWK kennt, tut sich mit allem anderen schwer :-)
Eselsbrücke in meinen Anfangszeiten war: in Perl kommt ein `$` vor die
Variablen, und in awk kommt ein `gsub` vor den Suchen+Ersetzen-Regex.

Aber Perl hat halt den besseren Upgrade-Pfad. Klar, `awk '{print $3}'`
ist schick, aber wenn ich jetzt noch Dinge aggregieren oder spaßige
Dekodierungen machen will (was in Perl sowas wie `++$count{$1}`,
`s/%([0-9a-f]{2})/chr hex $1/ig` wäre) sieht man in awk halt alt aus und
muss von vorn beginnen. Ersteres müsste in awk auch gehen, aber da muss
ich dann erstmal die Syntax nachschlagen :)


Stefan
Ulli Horlacher
2023-11-04 09:18:17 UTC
Permalink
Post by Stefan Reuther
Eselsbrücke in meinen Anfangszeiten war: in Perl kommt ein `$` vor die
Variablen
Gilt aber nur fuer Skalare.
Ja, eines der Dinge, die an Perl nerven :-}
Post by Stefan Reuther
und in awk kommt ein `gsub` vor den Suchen+Ersetzen-Regex.
Gibts nur in GNU awk und DER Grund warum ich auf Perl umgestiegen bin.
Post by Stefan Reuther
Klar, `awk '{print $3}'` ist schick
Weshalb ich immer noch manchmal awk einsetze :-)
Oder eben: pawk '{print $_3}'

https://fex.belwue.de/fstools/#pawk
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Stefan Möding
2023-11-04 09:44:57 UTC
Permalink
Post by Ulli Horlacher
Gibts nur in GNU awk und DER Grund warum ich auf Perl umgestiegen bin.
Wenn man noch mal auf alten Systemen unterwegs ist, dann merkt man erst,
wie man sich an "Alles ist Linux" und "GNU ist überall" gewöhnt hat.
--
Stefan
Axel Reichert
2023-11-04 09:46:23 UTC
Permalink
Post by Ulli Horlacher
Post by Stefan Reuther
und in awk kommt ein `gsub` vor den Suchen+Ersetzen-Regex.
Gibts nur in GNU awk und DER Grund warum ich auf Perl umgestiegen bin.
Du schriebst im Thread weiter oben sinngemaess, dass bash und perl deine
Schweizer Taschenmesser sind. Bei mir sind es bash und gawk. Ich bin
grosser Freund von Universalwerkzeugen. Alle drei Werkzeuge sind
jenseits von POSIX-Minimalismus, also nicht unbedingt als Standard auf
jedem System verfuegbar.

Wenn du dich also sowohl mit der bash als auch mit perl vom
POSIX-Minimalismus entfernst (mache ich ja auch, aber sehe sowohl die
GNU-Software als auch perl als unproblematisch an): Welches sind weitere
Gruende fuer dich, perl statt awk in den Werkzeugkoffer zu stecken?

Meine Frage ruehrt daher, dass ich in grauer (vielmehr: noch nicht so
grauer) Vorzeit weder sed noch awk konzeptionell verstanden hatte und
der Knoten im Hirn sich erst dann loeste, als ich perl lernte. Ab dem
Zeitpunkt habe ich dann eigentlich mehr sed und awk benutzt, weniger
perl, das eher als Verstaendniskatalysator diente.

Mir ist klar, dass perl eine Obermenge von awk ist (von daher
universeller, aber auch syntaktisch komplexer und manchmal weniger
konzis), aber welches sind die perl-Features ("g(en)sub" zaehlt nicht),
die du mehr oder weniger staendig nutzt und die den kognitiven
Mehraufwand fuer dich rechtfertigen?

Immer an Werkzeugdiskussionen interessiert (am wichtigsten ist
natuerlich, sie meisterhaft zu benutzen, "it's not about the bike")
gruesst

Axel
Peter J. Holzer
2023-11-04 11:10:51 UTC
Permalink
Post by Axel Reichert
Post by Ulli Horlacher
Post by Stefan Reuther
und in awk kommt ein `gsub` vor den Suchen+Ersetzen-Regex.
Gibts nur in GNU awk und DER Grund warum ich auf Perl umgestiegen bin.
Du schriebst im Thread weiter oben sinngemaess, dass bash und perl deine
Schweizer Taschenmesser sind. Bei mir sind es bash und gawk. Ich bin
grosser Freund von Universalwerkzeugen. Alle drei Werkzeuge sind
jenseits von POSIX-Minimalismus, also nicht unbedingt als Standard auf
jedem System verfuegbar.
Wenn du dich also sowohl mit der bash als auch mit perl vom
POSIX-Minimalismus entfernst (mache ich ja auch, aber sehe sowohl die
GNU-Software als auch perl als unproblematisch an): Welches sind weitere
Gruende fuer dich, perl statt awk in den Werkzeugkoffer zu stecken?
Wie Stefan schon geschrieben hat: Upgrade-Pfad.

Sowohl awk als auch Perl eignen sich für Einzeiler. Auch für einfache
Mehrzeiler kann man beides verwenden. Aber darüber (insbesondere, wenn
es nicht nur um das Verarbeiten eines einzelnen Text-Streams geht), wird
es bald mühsam. Mein längstes awk-Script (das ich noch finde) hat 173 Zeilen.
Mein komplexestes Perl-Programm, das noch im Einsatz ist, hat hingegen
5152 Zeilen (plus 8990 Zeilen Tests).

Wenn man regelmäßig Programme schreibt, bei denen man mit awk an die
Grenzen stößt und daher ohnehin Perl auch kennen muss, liegt es nahe,
Perl auch für Einzeiler zu verwenden, und awk und sed links liegen zu
lassen.

(Python ist für Einzeiler eher wenig geeignet. Vergleiche:

% awk '{s += $2} END {print s}' foo
26

% perl -n -E '@f = split; $s += $f[1]; END { say $s }' foo
26

% perl -n -a -E '$s += $F[1]; END { say $s }' foo
26
(dafür brauchte ich die Man-Page)

% python3 -c '
import sys
s = 0
for ln in sys.stdin:
f = ln.split()
s += float(f[1])
print(s)
' < foo
26.0

Der Python-Programmierer wird also für die Commandline noch andere
Tools brauchen, z.B. awk)
Post by Axel Reichert
Meine Frage ruehrt daher, dass ich in grauer (vielmehr: noch nicht so
grauer) Vorzeit weder sed noch awk konzeptionell verstanden hatte und
der Knoten im Hirn sich erst dann loeste, als ich perl lernte.
Mir ist es mit C so ähnlich gegangen. Pointer in Pascal habe ich nicht
verstanden. Dann habe ich C gelernt, dort verstanden, was Pointer sind,
und konnte sie hinfort auch in Pascal (und Modula, Perl, Java, Python,
...) verwenden (nicht dass ich danach noch viel Pascal programmiert
hätte).
Post by Axel Reichert
Mir ist klar, dass perl eine Obermenge von awk ist (von daher
universeller, aber auch syntaktisch komplexer und manchmal weniger
konzis), aber welches sind die perl-Features ("g(en)sub" zaehlt nicht),
die du mehr oder weniger staendig nutzt und die den kognitiven
Mehraufwand fuer dich rechtfertigen?
Ungefähr alles, was größere Programme möglich macht. Angefangen bei
lokalen Variablen[1] über Pointer und Klassen bis zu CPAN und einer
Konvention für Test-Suites.

hp

[1] Per Konvention werden in (g)awk lokale Variablen als zusätzliche
Parameter definiert. Die Man-Page nennt das "rather clumsy".
Zugegeben, die »my ($x, $y) = @_«-Konvention für Parameter in Perl
ist auch nicht sehr elegant.
Axel Reichert
2023-11-06 17:39:32 UTC
Permalink
Post by Peter J. Holzer
Sowohl awk als auch Perl eignen sich für Einzeiler. Auch für einfache
Mehrzeiler kann man beides verwenden. Aber darüber (insbesondere, wenn
es nicht nur um das Verarbeiten eines einzelnen Text-Streams geht), wird
es bald mühsam. Mein längstes awk-Script (das ich noch finde) hat 173 Zeilen.
Mein komplexestes Perl-Programm, das noch im Einsatz ist, hat hingegen
5152 Zeilen (plus 8990 Zeilen Tests).
Ich glaube nicht, dass ich fuer meine Zwecke jemals dreistellig geworden
Post by Peter J. Holzer
Wenn man regelmäßig Programme schreibt, bei denen man mit awk an die
Grenzen stößt und daher ohnehin Perl auch kennen muss, liegt es nahe,
Perl auch für Einzeiler zu verwenden, und awk und sed links liegen zu
lassen.
Klar, Stichwort Universalwerkzeug.
Post by Peter J. Holzer
% perl -n -a -E '$s += $F[1]; END { say $s }' foo
26
(dafür brauchte ich die Man-Page)
Das "a" fuer "autosplit" hatte ich sogar noch auf dem Schirm, dafuer
"say" nicht. Die Optionen kannst du noch zusammenfassen, dann ist es in
der Tat schoen knapp:

perl -anE '$s += $F[1]; END {say $s}' foo

Vielleicht sollte ich perl doch wieder reaktivieren.
Post by Peter J. Holzer
Der Python-Programmierer wird also für die Commandline noch andere
Tools brauchen, z.B. awk)
Klar. Tatsaechlich wuerde ich bei dreistelliger Zeilenanzahl von awk
sowieso auf Python statt auf Perl wechseln.

[perl-Funktionalitaet jenseits von awk]
Post by Peter J. Holzer
Ungefähr alles, was größere Programme möglich macht. Angefangen bei
lokalen Variablen[1] über Pointer und Klassen bis zu CPAN und einer
Konvention für Test-Suites.
OK, danke. Da bin ich dann mit Python unterwegs.

Tschoe!

Axel
Stefan Ram
2023-11-06 19:11:36 UTC
Permalink
Post by Axel Reichert
perl -anE '$s += $F[1]; END {say $s}' foo
py -c "import sys; print(sum(int(F.split()[1])for F in sys.stdin))" <in

"py" ist eine unter Windows übliche Abkürzung. Unter Linux würde man
dort wohl "python3" schreiben. Es ist der Python-Interpretierer.

"-c" erlaubt es, eine Folge von Anweisungen auf der Kommandozeile
zu übergeben (mit vielleicht gewissen Einschränkungen).

"for F in sys.stdin" bewirkt, daß F alle Zeilen aus stdin durchläuft.
Diese ist keine spezielle Syntax, wie das "<>" in Perl, und es wird
hier auch keine spezielle Option wie das "-a" oder "-n" von Perl
benötigt.

Durch ".split()[1]" wird das Feld 1 ausgewählt. Auch hier
kommt kein magischer Name, wie das "F" in Perl, zum Einsatz.
"F" ist ein frei gewählter Name in dem Skript, den man durch
andere Namen ersetzen könnte. "int" wandelt die Zeichenfolge
aus dem Feld in eine Zahl.

"sum" ist ein allgemeine Funktion zum Summieren einer Sequenz.

Beim Aufruf von "perl" kann das "-n" übrigens entfallen, wenn
schon "-a" verwendet wurde.
Axel Reichert
2023-11-07 05:55:51 UTC
Permalink
Post by Stefan Ram
py -c "import sys; print(sum(int(F.split()[1])for F in sys.stdin))" <in
[weitere Erklaerung]

Danke, Python kann ich. Im Code-Golf-Vergleich (auf der Kommandozeile
wichtig) ist

python -c "import sys; print(sum(int(F.split()[1]) for F in sys.stdin))" < foo

aber mehr als Faktor 2 zu

awk 's+=$1; END {print s}' foo
Post by Stefan Ram
Beim Aufruf von "perl" kann das "-n" übrigens entfallen, wenn
schon "-a" verwendet wurde.
Stimmt, danke, das hatte ich nicht mehr im Kopf.

Tschoe!

Axel
Ulli Horlacher
2023-11-07 07:46:08 UTC
Permalink
Post by Axel Reichert
python -c "import sys; print(sum(int(F.split()[1]) for F in sys.stdin))" < foo
aber mehr als Faktor 2 zu
awk 's+=$1; END {print s}' foo
Dabei war das ja nur ein trivial-Beispiel.
Sobald Schleifen oder if-then-else hinzukommen, ist es vorbei mit Python
auf Kommandozeile wegen "whitespace control flow"

Python ist prima fuer echte Programme, eignet sich aber nicht fuer direkte
CLI shell Eingabe, von ganz wenigen Ausnahmen abgesehen.

Andersrum: grosse Programme mit awk schreiben wird schwierig/umstaendlich
obwohl auch das geht: Ein Studiums-Kollege von mir hatte einen Assembler
in awk geschrieben mit weit ueber 1000 Zeilen.
Ich war schwer beeindruckt :-)
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Peter J. Holzer
2023-11-07 10:56:00 UTC
Permalink
Post by Ulli Horlacher
Post by Axel Reichert
python -c "import sys; print(sum(int(F.split()[1]) for F in sys.stdin))" < foo
aber mehr als Faktor 2 zu
awk 's+=$1; END {print s}' foo
Dabei war das ja nur ein trivial-Beispiel.
Sobald Schleifen oder if-then-else hinzukommen, ist es vorbei mit Python
auf Kommandozeile wegen "whitespace control flow"
Naja. Wie mein Beispiel gezeigt hat, kann man durchaus mehrzeilige
Python-Scripts auf der Kommandozeile eingeben (wenn man eine gescheite
Shell verwendet).

Aber es wird halt schnell mühsam ...
Post by Ulli Horlacher
Python ist prima fuer echte Programme, eignet sich aber nicht fuer direkte
CLI shell Eingabe, von ganz wenigen Ausnahmen abgesehen.
ACK.

hp
Martin Vaeth
2023-11-07 06:29:48 UTC
Permalink
Post by Stefan Ram
"for F in sys.stdin" bewirkt, daß F alle Zeilen aus stdin durchläuft.
Diese ist keine spezielle Syntax
Doch. List comprehension ist eine sehr spezielle Syntax.
Stefan Ram
2023-11-07 16:29:00 UTC
Permalink
Post by Stefan Ram
py -c "import sys; print(sum(int(F.split()[1])for F in sys.stdin))" <in
Eine Python-Newsgroup schlug auf meine Anfrage hin
folgende kürzere Schreibweise vor:

py -c "print(sum(int(F.split()[1])for F in open(0)))" <in

. (Laut Handbuch ist der numerische Deskriptor "0"
"normalerweise" stdin.)
Stefan Ram
2023-11-08 08:25:46 UTC
Permalink
Post by Stefan Ram
Eine Python-Newsgroup schlug auf meine Anfrage hin
Hier die beiden Quelltexte direkt untereinander:

$s += $F[1]; END {say $s}
print(sum(int(F.split()[1])for F in open(0)))

. Man sieht, daß die Notwendigkeit Perls "-n"-Option mit
"for F in open(0)" nachzubilden, der wichtigste Grund dafür ist,
daß das Python-Programm länger ist. Vergleicht man nun den Rest,
so ist Python nur noch unwesentlich länger:

$s += $F[1]; END {say $s}
print(sum(int(F.split()[1])))

. Das "split()" bildet im Prinzip Perls "-a"-Option nach. Ich lasse
es im folgende mal weg:

$s += $F[1]; END {say $s}
print(sum(int(|F[1]|)))

. So ähnlich wäre der Kernalgorithmus in Python, wenn Python eine
"-a"-Option hätte. Hier habe ich senkrechte Striche zum Python-
Programm hinzugefügt, weil man ja irgendwie sagen muß, was in
die Schleife soll, und was einmalig außerhalb der Schleife steht
(ähnlich wie mit "END" in Perl).

Man könnte sich im Prinzip in Python eine Bibliothek schreiben,
die das "-a" nachbildet und "print(sum(int(|F[1]|)))"
entsprechend interpretiert. Allerdings wären damit
geschrieben Shell-Skripte dann natürlich weniger portabel,
solange solch eine Bibliothek nicht verbreitet ist.

Oder man sieht in der etwas größeren Länge des Python-Stücks

print(sum(int(F.split()[1])for F in open(0)))

den Preis dafür, daß es recht lesbar ist ("print(sum(int..."
= "Drucke die Summe der Zahlenwerte von ...") und keinerlei
Spezialschreibweisen für Shell-Skripte sondern nur normale
Konstrukte der Programmiersprache verwendet.
Stefan Reuther
2023-11-07 17:20:24 UTC
Permalink
Post by Stefan Ram
Post by Axel Reichert
perl -anE '$s += $F[1]; END {say $s}' foo
py -c "import sys; print(sum(int(F.split()[1])for F in sys.stdin))" <in
Ich glaube, dass es *geht* ist nicht wirklich strittig. Wenn man das in
Perl vollständig aufschreibt, kommt auch nichts groß anderes raus:

perl -e 'while(defined($x=<STDIN>)){$t+=(split/\s+/,$x)[1]} say $t'

Nur hat perl aber eben extra Optionen, die den Boilerplate
dazugenerieren, inkl. impliziter/magischer Variablen. Das ist in der
Manpage dokumentiert, '-n' packt beispielsweise einfach nur eine
while-Schleife drum. Und das ist nicht nur so flapsig daher gesagt,
sondern funktioniert genau so: statt

perl -ne '++$n; END() { print $n }'

kann man auch

perl -ne '++$n }{ print $n'

schreiben, funktioniert genauso.

Und wenn Perl solche Hacks direkt anbietet, würde ich ihm schon das
Attribut "für Oneliner optimiert" geben. (Dafür ist die
Objektorientierung im Vergleich zu Python halt schon ziemlich mau.)


Stefan
Ulli Horlacher
2023-11-04 11:49:42 UTC
Permalink
Post by Axel Reichert
POSIX-Minimalismus entfernst (mache ich ja auch, aber sehe sowohl die
GNU-Software als auch perl als unproblematisch an): Welches sind weitere
Gruende fuer dich, perl statt awk in den Werkzeugkoffer zu stecken?
Perl ist halt mehr als 10-fach maechtiger als awk.
Post by Axel Reichert
Mir ist klar, dass perl eine Obermenge von awk ist (von daher
universeller, aber auch syntaktisch komplexer und manchmal weniger
konzis), aber welches sind die perl-Features ("g(en)sub" zaehlt nicht),
die du mehr oder weniger staendig nutzt und die den kognitiven
Mehraufwand fuer dich rechtfertigen?
Regexp, Netzwerk und POSIX Systemcalls.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Axel Reichert
2023-11-07 05:47:26 UTC
Permalink
Post by Ulli Horlacher
Perl ist halt mehr als 10-fach maechtiger als awk.
Ja, aber brauche ich fuer meinen Kleinkram meist nicht. Wenn ich 'was
Gscheites brauche, nehme ich Python, da ist die Syntax und die
Dokumentation mehr nach meinem Gusto.
Post by Ulli Horlacher
Post by Axel Reichert
konzis), aber welches sind die perl-Features ("g(en)sub" zaehlt nicht),
die du mehr oder weniger staendig nutzt und die den kognitiven
Mehraufwand fuer dich rechtfertigen?
Regexp, Netzwerk und POSIX Systemcalls.
Regexps sind ein guter Punkt, da komme ich mit den aelteren Werkzeugen
haeufiger mal an den Anschlag. Danke fuer die Erinnerung!

Axel
Ulli Horlacher
2023-11-07 07:53:54 UTC
Permalink
Axel Reichert <***@axel-reichert.de> wrote:

(Perl)
Post by Axel Reichert
Regexps sind ein guter Punkt, da komme ich mit den aelteren Werkzeugen
haeufiger mal an den Anschlag. Danke fuer die Erinnerung!
Einer der Punkte, die an UNIX nerven und vor allem Neulinge zur
Verzweiflung bringen (ich unterrichte seit Jahrzehnten):
(Fast) jedes tool hat seine eigene Definition von regexp, die sich
alle heimtueckisch im Detail unterscheiden.
Deshalb hatte ich mal grep in Perl nachprogrammiert, weil ich allzu oft in
die regexp-Inkompatibilitaetsfalle getappt war:

https://fex.belwue.de/fstools/#fpg

Inzwischen hat GNU grep die -P Option fuer Perl kompatible regexp.
So was fehlt noch fuer bash...
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Christian Weisgerber
2023-11-07 16:08:22 UTC
Permalink
Post by Ulli Horlacher
Einer der Punkte, die an UNIX nerven und vor allem Neulinge zur
(Fast) jedes tool hat seine eigene Definition von regexp, die sich
alle heimtueckisch im Detail unterscheiden.
Eigentlich hat Unix genau zwei RE-Varianten:
Basic Regular Expressions (z.B. ed, grep, sed) und
Extended Regular Expressions (z.B. egrep, awk).

Das ist auch so in POSIX standardisiert und auf 4.4BSD-Abkömmlingen
in re_format(7) ordentlich dokumentiert. Wie die zwei Varianten
historisch entstanden sind, weiß ich nicht.

Und dann sind die GNU-Leute gekommen und haben ihre eigene Variante
geschaffen, die gleich schon mal EREs in BRE-Syntax und BREs in
ERE-Syntax erlaubt. _Das_ verwirrt die Leute. Mich früher auch.

Perl hat natürlich sein eigenes, inzwischen unüberschaubar aufgeblähtes
Ding.
Post by Ulli Horlacher
Inzwischen hat GNU grep die -P Option fuer Perl kompatible regexp.
Es gibt ja PCRE, die "Perl-Compatible Regular Expression library".
Da ist auch ein pcregrep(1) dabei, das ich wegen seines -M Multiline-
Features gelegentlich verwende.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Stefan Möding
2023-11-07 17:47:24 UTC
Permalink
Post by Christian Weisgerber
Basic Regular Expressions (z.B. ed, grep, sed) und
Extended Regular Expressions (z.B. egrep, awk).
Das ist auch so in POSIX standardisiert und auf 4.4BSD-Abkömmlingen
in re_format(7) ordentlich dokumentiert. Wie die zwei Varianten
historisch entstanden sind, weiß ich nicht.
Kernighan erzählt das in seinem Buch "Die UNIX-Story" etwa so:

Ken Thompson hat unter Multics den Editor QED um eine der ersten
Implementierungen für BREs erweitert. Als er später mit UNIX angefangen
hat, war das die Basis für die REs in ed und damit auch für grep (was ja
ursprünglich nur ein ausführbares Kommando für einen internen ed-Befehl
war).

Al Aho (das A in AWK) hat sich bei den Bell Labs mit effizienten
Algorithmen für reguläre Ausdrücke beschäftigt und dabei auch die Syntax
erweitert, was zu EREs führte. Statt das grep Programm von Thompson zu
modifizieren, hat er dafür einfach egrep entwickelt. Die Implementierung
ist aus offensichtlichen Gründen dann auch in AWK verwendet worden.
--
Stefan
Ulli Horlacher
2023-11-07 17:49:09 UTC
Permalink
Post by Christian Weisgerber
Post by Ulli Horlacher
Einer der Punkte, die an UNIX nerven und vor allem Neulinge zur
(Fast) jedes tool hat seine eigene Definition von regexp, die sich
alle heimtueckisch im Detail unterscheiden.
Basic Regular Expressions (z.B. ed, grep, sed) und
Extended Regular Expressions (z.B. egrep, awk).
Und die shell wildcards, die zumindest von der (Informatik-)Theorie her
auch "regular expression" sind, aber wieder ganz andere Bedeutung haben.
Post by Christian Weisgerber
Post by Ulli Horlacher
Inzwischen hat GNU grep die -P Option fuer Perl kompatible regexp.
Es gibt ja PCRE, die "Perl-Compatible Regular Expression library".
Da ist auch ein pcregrep(1) dabei, das ich wegen seines -M Multiline-
Features gelegentlich verwende.
Das haben die alle von mir abgekupfert! ;-)

Im Ernst: weil es das frueher nicht gab, ich es aber brauchte, hab ichs
halt implementiert, eben weil es mit Perl recht einfach ging.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Thomas Dorner
2023-11-07 18:52:12 UTC
Permalink
Post by Ulli Horlacher
Und die shell wildcards, die zumindest von der (Informatik-)Theorie her
auch "regular expression" sind, aber wieder ganz andere Bedeutung haben.
Hmm, sind sie das? Ich halte sie in der Beziehung für unvollständig.
Wie schreibe ich damit z.B. "beliebig viele A"? Ich meine das
Äquivalent zu:
AA*

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!
Ulli Horlacher
2023-11-07 22:45:51 UTC
Permalink
Post by Thomas Dorner
Post by Ulli Horlacher
Und die shell wildcards, die zumindest von der (Informatik-)Theorie her
auch "regular expression" sind, aber wieder ganz andere Bedeutung haben.
Hmm, sind sie das?
Per Defintion nach, ja.
Sagt dir jeder Informatiker.
Post by Thomas Dorner
Ich halte sie in der Beziehung für unvollständig.
Nicht alle regular expression sind gleich maechtig.
Post by Thomas Dorner
Wie schreibe ich damit z.B. "beliebig viele A"?
Das geht mit shell wildcards nicht, zumindest nicht mit bash oder ksh.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Martin Vaeth
2023-11-08 06:34:41 UTC
Permalink
Post by Ulli Horlacher
Post by Thomas Dorner
Post by Ulli Horlacher
Und die shell wildcards, die zumindest von der (Informatik-)Theorie her
auch "regular expression" sind, aber wieder ganz andere Bedeutung haben.
Hmm, sind sie das?
Per Defintion nach, ja.
Sagt dir jeder Informatiker.
Zumindest keiner, der die Definition aus der Theorie heranzieht.
Post by Ulli Horlacher
Post by Thomas Dorner
Ich halte sie in der Beziehung für unvollständig.
Nicht alle regular expression sind gleich maechtig.
Doch. Das ist ja gerade der theoretische Kern der Sache:
regular expression sind - bis auf syntaktischen Schnickschack -
*genau* die Ausdrücke, die ein endlicher Automat (prinizipiell)
erkennen kann (wenn der Automat als Überganggänge in jedem
Zustand genau die Elemente des Alphabets hat).
Unix Shell wildcards leisten dies nicht.
Post by Ulli Horlacher
Post by Thomas Dorner
Wie schreibe ich damit z.B. "beliebig viele A"?
Das geht mit shell wildcards nicht, zumindest nicht mit bash oder ksh.
Mit zsh geht es (wenn ich auch erst nachschauen müsste, wie),
und daher ziemlich sicher auch mit ksh.
Allerdings kann man WIMRE z.B. keine geklammerten Ausdrücke beliebig
oft wiederholt suchen, und schon gar nicht Wiederholungen
beliebiger geklammerter Ausdrücke.
Peter J. Holzer
2023-11-08 17:55:52 UTC
Permalink
Post by Martin Vaeth
Post by Ulli Horlacher
Post by Thomas Dorner
Post by Ulli Horlacher
Und die shell wildcards, die zumindest von der (Informatik-)Theorie her
auch "regular expression" sind, aber wieder ganz andere Bedeutung haben.
Hmm, sind sie das?
Per Defintion nach, ja.
Sagt dir jeder Informatiker.
Zumindest keiner, der die Definition aus der Theorie heranzieht.
Bist mir zuvorgekommen ;-).
Post by Martin Vaeth
Post by Ulli Horlacher
Post by Thomas Dorner
Ich halte sie in der Beziehung für unvollständig.
Nicht alle regular expression sind gleich maechtig.
regular expression sind - bis auf syntaktischen Schnickschack -
*genau* die Ausdrücke, die ein endlicher Automat (prinizipiell)
erkennen kann (wenn der Automat als Überganggänge in jedem
Zustand genau die Elemente des Alphabets hat).
Unix Shell wildcards leisten dies nicht.
ACK.

Umgekehrt haben manche Sprachen "Regular Expressions", die mächtiger
sind, als endliche Automaten (z.B. Perl). Strenggenommen sind das dann
keine Regular Expressions.

(Aside: Sind nicht schon Backreferences eine Erweiterung? Ich wüsste
jetzt z.B. nicht, wie ich /^(a*)b\1$/ als endlichen Automaten schreiben
sollte - aber vielleicht übersehe ich die offensichtliche Lösung.)
Post by Martin Vaeth
Post by Ulli Horlacher
Post by Thomas Dorner
Wie schreibe ich damit z.B. "beliebig viele A"?
Das geht mit shell wildcards nicht, zumindest nicht mit bash oder ksh.
Mit zsh geht es (wenn ich auch erst nachschauen müsste, wie),
und daher ziemlich sicher auch mit ksh.
Ja, aber mit anderer Syntax (Nachgestelltes # in der zsh, vorgestelltes
* in der ksh (und bash).
Post by Martin Vaeth
Allerdings kann man WIMRE z.B. keine geklammerten Ausdrücke beliebig
oft wiederholt suchen,
Doch, geht.
Post by Martin Vaeth
und schon gar nicht Wiederholungen beliebiger geklammerter Ausdrücke.
Meinst Du Backreferences? Das geht soweit ich sehe wirklich nicht.

hp
Martin Vaeth
2023-11-08 19:29:54 UTC
Permalink
Post by Peter J. Holzer
Umgekehrt haben manche Sprachen "Regular Expressions", die mächtiger
sind, als endliche Automaten (z.B. Perl). Strenggenommen sind das dann
keine Regular Expressions.
Korrekt.
Post by Peter J. Holzer
(Aside: Sind nicht schon Backreferences eine Erweiterung?
Ja.
Post by Peter J. Holzer
Ich wüsste
jetzt z.B. nicht, wie ich /^(a*)b\1$/ als endlichen Automaten schreiben
sollte
Korrekt: Es gibt keinen endlichen Automaten, der genau diese
Zeichenketten akzeptiert: Zum Beweis wähle man einfach mehr a, als der
Automat Zustände hat, wende das Schubfachprinzip an, und überlege sich
dann, was die "Schleife" zwischen den doppelt angenommenen Zuständen
impliziert...

Backtracking braucht hier übrigens auch schon quadratische Laufzeit.
Post by Peter J. Holzer
Post by Martin Vaeth
Mit zsh geht es (wenn ich auch erst nachschauen müsste, wie),
und daher ziemlich sicher auch mit ksh.
Ja, aber mit anderer Syntax (Nachgestelltes # in der zsh, vorgestelltes
* in der ksh (und bash).
Erstaunlich: Ich dachte immer, zsh und ksh wären in solchen Erweiterungen
sehr ähnlich.
Post by Peter J. Holzer
Post by Martin Vaeth
Allerdings kann man WIMRE z.B. keine geklammerten Ausdrücke beliebig
oft wiederholt suchen,
Doch, geht.
Du hast recht.
Post by Peter J. Holzer
Post by Martin Vaeth
und schon gar nicht Wiederholungen beliebiger geklammerter Ausdrücke.
Meinst Du Backreferences?
Nein, ich meinte (in zsh) so etwas wie (a(bb#))#
Scheint aber tatsächlich zu gehen.
Man lernt nie. aus.
Christian Weisgerber
2023-11-08 20:51:04 UTC
Permalink
Post by Martin Vaeth
Post by Peter J. Holzer
Ich wüsste
jetzt z.B. nicht, wie ich /^(a*)b\1$/ als endlichen Automaten schreiben
sollte
Korrekt: Es gibt keinen endlichen Automaten, der genau diese
Damit wird irgendwie zusammenhängen, dass zwar BREs Back References
haben, EREs aber nicht.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Christian Weisgerber
2023-11-08 14:47:28 UTC
Permalink
Post by Ulli Horlacher
Post by Thomas Dorner
Wie schreibe ich damit z.B. "beliebig viele A"?
Das geht mit shell wildcards nicht,
Mit POSIX/sh-Globs nicht.
Post by Ulli Horlacher
zumindest nicht mit bash oder ksh.
Doch mit den erweiterten Globs von ksh: *(A) bzw. +(A) je nachdem,
ob du mit "beliebig viele" auch null einschließt oder nicht.

Bei bash kann man das für Dateinamen einschalten (shopt extglob);
für Mustervergleiche in [[ ... ]] ist es immer aktiv.
--
Christian "naddy" Weisgerber ***@mips.inka.de
Ulli Horlacher
2023-11-08 20:30:39 UTC
Permalink
Post by Christian Weisgerber
Post by Ulli Horlacher
zumindest nicht mit bash oder ksh.
Doch mit den erweiterten Globs von ksh: *(A) bzw. +(A) je nachdem,
ob du mit "beliebig viele" auch null einschließt oder nicht.
Bei bash kann man das für Dateinamen einschalten (shopt extglob);
für Mustervergleiche in [[ ... ]] ist es immer aktiv.
Wieder was neues gelernt :-)
Ist bei mir in bash 5.1.16 sogar default.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Thomas Dorner
2023-11-08 17:34:40 UTC
Permalink
Post by Ulli Horlacher
Post by Thomas Dorner
Post by Ulli Horlacher
Und die shell wildcards, die zumindest von der (Informatik-)Theorie her
auch "regular expression" sind, aber wieder ganz andere Bedeutung haben.
Hmm, sind sie das?
Per Defintion nach, ja.
Sagt dir jeder Informatiker.
Nun, alle Informatik Professoren an der Uni Karlsruhe haben mir das im
Studium anders erklärt (endliche Automaten wurden ja schon erwähnt).
Das ist aber auch schon etwas länger her (daher UNIKA und nicht KIT ;-).

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!
Stefan Ram
2023-11-04 10:10:08 UTC
Permalink
Post by Stefan Reuther
Eselsbrücke in meinen Anfangszeiten war: in Perl kommt ein `$` vor die
Variablen,
Vor die Skalare. (Daneben gibt es auch noch Variablen für Reihungen
und Zuordnungen.)
Loading...