The AWK Programming Language (2. Auflage)

[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. Zeit, das mal
wieder etwas aufzufrischen.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Ulli Horlacher]

Christian Weisgerber <na...@mips.inka.de> wrote:
> Heute ist etwas überraschend das vorbestellte Aho/Kernighan/Weinberger,
> _The AWK Programming Language_, 2. Auflage, 2024, eingetroffen.

^^^^
Zurueck in die Zukunft? :-)

> 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: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/

[Christian Weisgerber]

On 2023-11-03, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

>> 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.

> 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.

> Und haben die Original-Autoren tatsaechlich ihr Werk ueberarbeitet?

Ja! Ich meine beim Durchblättern --csv gesehen zu haben; es ist
also wirklich aktualisiert.

[Stefan Möding]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> 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]

On 2023-11-03, Stefan Möding <Nov2023....@spamgourmet.com> wrote:

>> 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.

> 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.

[Markus Schaaf]

Am 03.11.23 um 16:34 schrieb 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.

[Markus Schaaf]

Am 03.11.23 um 17:12 schrieb Stefan Ram:

> Markus Schaaf <msc...@elaboris.de> writes:
>> 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

[Christian Weisgerber]

On 2023-11-03, Stefan Ram <r...@zedat.fu-berlin.de> wrote:

>>|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/

[Marc Haber]

Markus Schaaf <msc...@elaboris.de> wrote:
>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

[Stefan Reuther]

Am 03.11.2023 um 17:12 schrieb Stefan Ram:
> Markus Schaaf <msc...@elaboris.de> writes:

>> 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

[Stefan Reuther]

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

[Peter J. Holzer]

On 2023-11-03 15:34, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>|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,

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.

>|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.

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> 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?

> ¹ 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"

[Christian Garbs]

Mahlzeit!

Christian Weisgerber <na...@mips.inka.de> wrote:

> 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

[Thomas Dorner]

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]

Christian Weisgerber <na...@mips.inka.de> wrote:

> Awk existiert immer noch, hat seine Nische und einen angenehm
> überschaubaren Sprachumfang. Ich benutze es gelegentlich.

https://fex.belwue.de/fstools/pawk.html

>> 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!

[Ulli Horlacher]

Stefan Möding <Nov2023....@spamgourmet.com> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>
>> 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 :-)

[Ulli Horlacher]

Christian Weisgerber <na...@mips.inka.de> wrote:

>> 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)

[Ulli Horlacher]

Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> 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.

[Peter J. Holzer]

On 2023-11-03 16:30, Markus Schaaf <msc...@elaboris.de> wrote:
> Am 03.11.23 um 17:12 schrieb Stefan Ram:
>> Markus Schaaf <msc...@elaboris.de> writes:
>>> 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.

> 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.

> 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).

> 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

[Peter J. Holzer]

On 2023-11-03 17:33, Stefan Reuther <stefa...@arcor.de> wrote:
> Am 03.11.2023 um 17:12 schrieb Stefan Ram:
>> Markus Schaaf <msc...@elaboris.de> writes:
>>> 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.

> 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).

> 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]

Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> Christian Garbs <mi...@cgarbs.de> writes:
>>¹ 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 )

Also 9 Zeilen, wo es in awk 1 waere. DAS nenn ich Fortschritt :-}


> 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.

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Christian Weisgerber <na...@mips.inka.de> wrote:
>
>>> 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

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:

>>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.

[Stefan Reuther]

Am 03.11.2023 um 21:50 schrieb Ulli Horlacher:
> Stefan Möding <Nov2023....@spamgourmet.com> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>>
>>> 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]

Stefan Reuther <stefa...@arcor.de> wrote:

> 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 :-}

> 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.

> Klar, `awk '{print $3}'` ist schick

Weshalb ich immer noch manchmal awk einsetze :-)
Oder eben: pawk '{print $_3}'

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

[Stefan Möding]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> 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]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> Stefan Reuther <stefa...@arcor.de> wrote:
>
>> 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

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>
>>>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.

>Bist du nicht derjenige, der andere auffordert mal was neues zu lernen? :-)

Ja, aber perl ist nicht "was neues".

[Peter J. Holzer]

On 2023-11-04 09:46, Axel Reichert <ma...@axel-reichert.de> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>> Stefan Reuther <stefa...@arcor.de> wrote:
>>> 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)

> 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).

> 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.

[Ulli Horlacher]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:
>>
>>>>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.

>>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.

[Ulli Horlacher]

Axel Reichert <ma...@axel-reichert.de> wrote:

> 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.

> 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.

[Thomas Hochstein]

Marc Haber schrieb:

> Ja, aber perl ist nicht "was neues".

Das ist eine Frage der Perspektive. ;)

[Axel Reichert]

"Peter J. Holzer" <hjp-u...@hjp.at> writes:

> 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
bin, weder mit awk noch mit perl. (-:

> 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.

> % 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.

> 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]

> 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

[Axel Reichert]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> 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.

>> 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

[Axel Reichert]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> 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

> 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

[Martin Vaeth]

Stefan Ram <r...@zedat.fu-berlin.de> schrieb:
>
> "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.

[Ulli Horlacher]

Axel Reichert <ma...@axel-reichert.de> wrote:

> 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 :-)

[Ulli Horlacher]

Axel Reichert <ma...@axel-reichert.de> wrote:

(Perl)

> 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...

[Peter J. Holzer]

On 2023-11-07 07:46, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Axel Reichert <ma...@axel-reichert.de> wrote:
>
>> 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 ...

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

ACK.

hp

[Christian Weisgerber]

On 2023-11-07, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> 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.

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.

> 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 na...@mips.inka.de

[Stefan Reuther]

Am 06.11.2023 um 20:11 schrieb Stefan Ram:

> Axel Reichert <ma...@axel-reichert.de> writes:
>> 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

[Stefan Möding]

Christian Weisgerber <na...@mips.inka.de> writes:

> 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.

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]

Christian Weisgerber <na...@mips.inka.de> wrote:
> On 2023-11-07, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>
>> 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.
>
> Eigentlich hat Unix genau zwei RE-Varianten:
> 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.

>> 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.

[Thomas Dorner]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
> 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]

Thomas Dorner <dcous2311...@spamgourmet.com> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>> 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.

> Ich halte sie in der Beziehung für unvollständig.

Nicht alle regular expression sind gleich maechtig.

> Wie schreibe ich damit z.B. "beliebig viele A"?

Das geht mit shell wildcards nicht, zumindest nicht mit bash oder ksh.

[Martin Vaeth]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> schrieb:

> Thomas Dorner <dcous2311...@spamgourmet.com> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>>> 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.

>> 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.

>> 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.

[Christian Weisgerber]

On 2023-11-07, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

>> Wie schreibe ich damit z.B. "beliebig viele A"?
>
> Das geht mit shell wildcards nicht,

Mit POSIX/sh-Globs nicht.

> 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.

[Thomas Dorner]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
> Thomas Dorner <dcous2311...@spamgourmet.com> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>>> 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 ;-).

[Peter J. Holzer]

On 2023-11-08 06:34, Martin Vaeth <mar...@mvath.de> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> schrieb:
>> Thomas Dorner <dcous2311...@spamgourmet.com> wrote:
>>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>>>> 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 ;-).

>>> 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.

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.)

>>> 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).

> Allerdings kann man WIMRE z.B. keine geklammerten Ausdrücke beliebig
> oft wiederholt suchen,

Doch, geht.

> und schon gar nicht Wiederholungen beliebiger geklammerter Ausdrücke.

Meinst Du Backreferences? Das geht soweit ich sehe wirklich nicht.

hp

[Martin Vaeth]

Peter J. Holzer <hjp-u...@hjp.at> schrieb:

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

Korrekt.

> (Aside: Sind nicht schon Backreferences eine Erweiterung?

Ja.

> 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.

>> 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.

>> Allerdings kann man WIMRE z.B. keine geklammerten Ausdrücke beliebig
>> oft wiederholt suchen,
>
> Doch, geht.

Du hast recht.

>> 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.

[Ulli Horlacher]

Christian Weisgerber <na...@mips.inka.de> wrote:

>> 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.

[Christian Weisgerber]

On 2023-11-08, Martin Vaeth <mar...@mvath.de> wrote:

>> 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:

Damit wird irgendwie zusammenhängen, dass zwar BREs Back References
haben, EREs aber nicht.

[Christian Weisgerber]

On 2023-11-03, Christian Weisgerber <na...@mips.inka.de> wrote:

>> 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.