Login
Newsletter
Werbung

Thema: Gawk 5.0 unterstützt Namensräume

18 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Gawk macht die Henne am Mi, 17. April 2019 um 12:44 #

Dieses Paradigma dass sich erst mal alles auf eine Zeile bezieht
ist vielleicht recht sinnvoll wenn man nur Textdateien durchnudelt.
Für was anderes ist es dann aber nicht zu gebrauchen bzw. wird schnell umständlich. Da ist eine normale Scriptsprache flexibler und auf Zeilen
greife ich dort auch einfach zu und bin Längen flexibler.

Und jetzt gibt es Namensräume, als wenn jemand damit extrem komplexe Scripte schreibt, da sind dann erst Namensräume sinnvoll verwendbar, bei Kleinkram hindern die mehr und für mehr als Kleinkram wird awk wohl auch nicht eingesetzt.

Wenn ich schon das lese:

Namespaces have been implemented! See the manual. One consequence of this
is that files included with -i, read with -f, and command line program
segments must all be self-contained syntactic units. E.g., you can no
longer do something like this:

gawk -e 'BEGIN {' -e 'print "hello" }'

Das war doch gerade die Stärke dieser primitiven Sprache. Jetzt soll das zu einer 'richtigen' Scriptsprache aufgeblasen werden, mit den Nachteilen von oben. Sowas braucht und will keiner, ausser die Entwickler von gawk als reiner Selbstszeck zum dran rumentwickeln.

  • 0
    Von Naja am Mi, 17. April 2019 um 13:43 #

    Sowas braucht und will keiner, ausser die Entwickler von gawk als reiner Selbstszeck zum dran rumentwickeln.

    Ungefähr so wie deine Kommentare: Braucht und will keiner, reiner Selbstzweck.

    0
    Von fork am Mi, 17. April 2019 um 15:01 #

    awk ist für text

    Ja. awk ist ein Textprozessor. Was anderes will man damit nicht unbedingt machen. Aber Texte verarbeiten, dafür ist es sehr gut.

    awk ist schnell

    Der zeilenbasierte Ansatz ist sehr performant - um Größenordnungen performanter, wenn man die sehr einfach zu verwendenden Sprachkonstrukte von modernen Sprachen verwendet.

    Den kann man auch in anderen Programmiersprachen umsetzen, aber in awk geht das so komfortabel wie in keiner (mir bekannten) anderen Programmiersprache.

    awk ist extrem kompakt
    Darüberhinaus kann mit awk extrem kurze und effektive Programme schreiben.

    Ich habe mal Ein Programm in lua geschrieben, das zugegebener Maßen auf Details geachtet hat. Es hatte 180 Zeilen. Anschließend habe ich noch mal eine awk Variante im Netz gefunden. Die hatte Netto 10 Zeilen.

    • 0
      Von Gawk-gawk gackert das Huhn am Mi, 17. April 2019 um 17:22 #

      Und in Perl gehts in 3 Zeilen.

      awk ist heutzutage einfach überflüssig.
      Jetzt werden Konstrukte reingeflickt die andere Sprachen längst drin haben, warum macht man das wohl? Weil awk einfach zu primitiv und beschränkt ist. Dadurch wird es auch nicht mehr attraktiver, der Zug ist längst abgefahren.

      • 0
        Von Brooke am Mi, 17. April 2019 um 17:55 #


        Ja so ist es richtig! Was ich nicht benutze ist schließlich überflüssig. Die ganzen Entwickler haben sowieso keine Ahnung hätten die mal besser mich gefragt. Diese ganzen Skriptsprachen braucht doch sowieso niemand. Aber warum bei Skriptsprachen aufhören. C reicht schon für alles was man braucht und alles andere ist sowieso nur Selbstprofilierung der Entwickler. Das merkt man daran dass Python & Co immer neue Funktionen entwickeln warum wohl? Weil die merken dass Ihre Sprachen im Vergleich zu C viel zu primitiv sind.Ist auch alles viel einfacher wenn die ganzen überflüssigen Programmiersprachen mal weg sind ist ja auch alles viel zu kompliziert.

        Nicht alles was du nicht nutzt ist gleich überflüssig. Unterschiedliche Sprachen/Programme werden für unterschiedliche Einsatzgebiete entwickelt und sind für diesen Einsatz super praktisch. Na klar kann man alles auch in Python oder sonst was machen was aber nicht heisst das es sinnvoll ist. Awk ist einfach genial zur schnellen Textverarbeitung und so mächtig wie kaum was anderes.

        • 0
          Von Anonymous Coward am Do, 18. April 2019 um 10:12 #

          Ja so ist es richtig! Was ich nicht benutze ist schließlich überflüssig.
          Das ist mal wieder ein Paradebeispiel für die dümmliche, verlogene Art von Argumentation, die heutzutage im Internet anscheinend üblich ist. Der OP hat awk nicht kritisiert, weil er es nicht benutzt, sondern weil der Funktionsumfang von awk schon seit vielen Jahren in anderen Sprachen enthalten ist, einschließlich dem Kram, der jetzt hinzugefügt wurde. Da stellt sich eben schon die Frage, warum man das noch brauchen sollte.

          Das merkt man daran dass Python & Co immer neue Funktionen entwickeln warum wohl? Weil die merken dass Ihre Sprachen im Vergleich zu C viel zu primitiv sind.
          Eigentlich ist es umgekehrt: C ist primitiv (und Python im Grunde auch, aber das ist wieder eine andere Geschichte).

          Unterschiedliche Sprachen/Programme werden für unterschiedliche Einsatzgebiete entwickelt und sind für diesen Einsatz super praktisch.
          Es gibt aber kein Anwendungsgebiet, das awk wesentlich besser abdeckt als beispielsweise Perl (oder Python, Ruby oder was auch immer). Und auf der anderen Seite stehen für diese Sprachen Tausende Module für jeden erdenklichen Zweck bereit (CPAN, PyPI etc.), während awk nichts vergleichbares zu bieten hat.

          Awk ist einfach genial zur schnellen Textverarbeitung und so mächtig wie kaum was anderes.
          Zeig bitte mal ein Beispiel, wo awk wesentliche Vorteile gegenüber Perl bietet.

          • 0
            Von klopskind am Do, 18. April 2019 um 18:27 #

            Das ist mal wieder ein Paradebeispiel für die dümmliche, verlogene Art von Argumentation, die heutzutage im Internet anscheinend üblich ist.
            Ich bin mir nicht sicher, ob Sie Brooke (s.o.) an dieser Stelle
            Ja so ist es richtig! Was ich nicht benutze ist schließlich überflüssig.
            richtig verstanden haben. Ich bin mir sicher, dass Brooke das sarkastisch meint, und das somit Kritik an der Argumentation des OP ist.
            Was ist daran "dümmlich" oder "verlogen"?

            OP stützt seine Argumentation nämlich im Wesentlichen darauf, dass er selbst keine Verwendung für Gawk oder anderen Implementierungen von AWK habe und sehe. Dabei schließt er von sich auf andere (siehe u.A. Titel des OP: "Braucht doch seit [sic] keiner mehr"). Deshalb ist es für eine Kritik seiner Argumentation an dieser Stelle unerheblich, wie er letzteres Argument begründet {mit der Existenz & Verwendung einer (für ihn) "flexibler"en und weniger "umständlich"en Alternative (Zitat: "normale Scriptsprache"}.

            Der OP hat awk nicht kritisiert, weil er es nicht benutzt, [...]
            Doch! OP schrieb (Hervorhebungen meinerseits):
            Dieses Paradigma dass sich erst mal alles auf eine Zeile bezieht
            ist vielleicht recht sinnvoll wenn man nur Textdateien durchnudelt.
            Für was anderes ist es dann aber nicht zu gebrauchen bzw. wird schnell umständlich. Da ist eine normale Scriptsprache flexibler und auf Zeilen greife ich dort auch einfach zu und bin Längen flexibler.
            Davon ausgehend schließt er von sich auf andere. So lautet die Überschrift des OP (bezogen auf den Artikel, d.h. Gawk oder AWK): "Braucht doch seit [sic] keiner mehr". Am Ende des Eingangskommentars schrieb er außerdem: "Sowas braucht und will keiner, ausser die Entwickler von gawk als reiner Selbstszeck zum dran rumentwickeln."

            Daher ist Brookes Kritik berechtigt.

            Unabhängig davon liegt der OP damit richtig, dass der beabsichtigte Haupteinsatzzweck von AWK hauptsächlich Einzeiler oder sehr kurze Programme waren/sind.

            Aber weiter:

            [...], sondern weil der Funktionsumfang von awk schon seit vielen Jahren in anderen Sprachen enthalten ist, einschließlich dem Kram, der jetzt hinzugefügt wurde.
            Das stimmt soweit. Aber ist das die einzige Metrik, auf deren Grundlage Entscheidungen über die Wahl der zu verwendenden Werkzeuge (z.B. Programmiersprache) getroffen werden (können/sollten)?

            Wie dem auch sei, betreffend der Kritik an der Argumentation des OP ist es nachrangig, womit der OP sein Argument begründet, wenn er gleichzeitig alle anderen Argumente, die für die Verwendung von Gawk/AWK statt möglicher Alternativen sprechen, unterschlägt, indem er fahrlässig von sich auf andere schließt.

            Da stellt sich eben schon die Frage, warum man das noch brauchen sollte.
            Eine Antwort auf diese Frage hängt von vielerlei Faktoren ab und ist äußerst anwendungsspezifisch. D.h. sie enthält stets eine Portion Subjektivität und ist quasi nie objektiv. Daher schlage ich vor, dass wir diese Frage besser denjenigen überlassen sollten, die eine konkrete Verwendung von Gawk/AWK erwägen oder umsetzen, ohne sie gleichzeitig zu einer Rechtfertigung zu zwingen.

            Es gibt aber kein Anwendungsgebiet, das awk wesentlich besser abdeckt als beispielsweise Perl (oder Python, Ruby oder was auch immer).
            Das ist eine Behauptung, die es zu beweisen gälte. Wer sollte diesen Beweis nun führen? Ich schlage vor, dass diejenigen Personen hierfür verantwortlich sind, die diese Behauptung aufstellen. In diesem Fall wären das Sie und der OP.

            Trotzdem halte ich Folgendes gegen diese Behauptung:
            1) AWK findet in der ein oder anderen Implementierung (z.B. Gawk) noch reichlich Anwendung. Nicht nur das, aber Entwickler auf der ganzen Welt schreiben auch heute noch Code in dieser Sprache oder passen bestehenden an, statt diesen zu ersetzen (siehe z.B. GitHub oder hier, Appendix B). Man denke auch an all' die weiterhin gepflegten und weiterentwickelten unixoiden Umgebungen (bzw. jede, die POSIX implementiert).

            2) In einigen Umgebungen, in denen keine geeigneten Alternativen zur Verfügung stehen, sind die Entwickler auf die Verwendung von AWK angewiesen. Das kann mehrere Gründe haben: Implementierungen von AWK (z.B. Gawk) sind vergleichsweise schlank (weniger Abhängigkeiten), portierbar (Initialaufwand), wartbar (laufende Kosten), ressourcensparend (kostensenkend, bspw. in Embedded-Produkten) etc.
            Perl ist bspw. nicht Teil des Basissystems von FreeBSD.

            3) Im Gegensatz zu Perl (seit 1987), Python (seit 1990) oder Ruby (1995) und vielen anderen Skript- oder Interpretersprachen, wie z.B. Tcl (1987), existiert AWK schon deutlich länger (seit 1977). Es fand mit Version 7 Unix (1979) erstmals Verbreitung. Nach grundlegenden Überarbeitungen der Sprache erschien das Buch The AWK Programming Language (1988), womit die Sprache de-facto vollständig spezifiziert und dokumentiert wurde. Seitdem blieb sie weitestgehend stabil (relativ gesehen zu den genannten Alternativen und deren Implementierungen). Direkt darauf folgte GNU awk aka gawk aka Gawk. Damit genoss es lange Zeit eine hohe Verbreitung und Popularität für Textverarbeitung.
            Ältere Entwickler sind also u.U. besser mit AWK vertraut als mit den Alternativen.

            4) Seit 1985 ist AWK zudem Teil eines Standards (POSIX), was die meisten Alternativen bis heute nicht von sich behaupten können (JavaScript ausgenommen). Diese Dinge können bei einer Wahl der Umsetzungssprache zum Ausschluss aller Alternativen führen.

            --
            Übrigens: Was heißt "wesentlich besser" in diesem Kontext, und wer darf das beurteilen?
            Ich schlage vor, dass die Bewertung und Entscheidung über die Eignung, Präferenz, Wahl oder Verwendung eines Werkzeugs (etwas anderes ist AWK oder eine andere Sprache - bzw. deren Implementierung - nicht) jedem Entwickler individuell obliegt. Die Entwickler sollten natürlich auch mit den Konsequenzen ihrer Entscheidungen, u.A. gerechfertigte Bewertungen des Ergebnisses und angemessene Kritik durch Dritte, rechnen.

            Daher denke ich, dass der Einsatz von AWK je nach Anwendungsfall auch heute noch sinnvoll im Sinne pragmatischer Lösungen führen kann und eingesetzt wird, was die Relevanz dieser Sprache, deren Implementierung und Erweiterungen auch weiterhin rechtfertigt.

            Es gibt aber kein Anwendungsgebiet, das awk wesentlich besser abdeckt als beispielsweise Perl (oder Python, Ruby oder was auch immer).
            Konkrete Beweise bitte!

            Und auf der anderen Seite stehen für diese Sprachen Tausende Module für jeden erdenklichen Zweck bereit (CPAN, PyPI etc.), während awk nichts vergleichbares zu bieten hat.
            Das kann man genauso als Vorteil werten. So ist AWK deutlich einfacher, kompakter und prägnanter (nicht so geschwätzig), weil bestimmte, für Programmbibliotheken nötige Konzepte, z.B. Module oder Linking, fehlen, und die Implementierungen von AWK sind deutlich simpler, portierbarer, schlanker, wartbarer und ressourcenschonender als die der erwähnten Alternativen.
            Es ist immer eine Abwägung einer Vielzahl an Faktoren und hängt vom Anwendungsfall ab.

            Zeig bitte mal ein Beispiel, wo awk wesentliche Vorteile gegenüber Perl bietet.
            Die Antwort darauf ist vielfältig, facettenreich und subjektiv.

            Neben den oben bereits erwähnten Beispielen kann ein möglicher Vorteil die Lizenzierung ggü. Perl attraktiver sein, jenachdem welche Implementierung von AWK wir betrachten; vergleiche bspw. Perls Lizenz(en) mit dieser Lizenz.

            Darüber hinaus wäre es hilfreicher, denke ich, wenn Sie etwaige AWK-Gurus einfach selbst fragen nach ihren Ansichten fragen.

            • 0
              Von AWK heisst mein Rollator am So, 21. April 2019 um 20:12 #

              Das Zeug ist einfach primitiv. So Trivialzeugs wie zeilenweise Texte einzulesen
              erschlage ich mit jeder anderen Scriptsprache die mehr kann und verbreiteter ist als awk.

              Also wozu brauche ich dann heute noch awk? Ob das Zeug auf FreeBSD läuft oder schlanker ist interessiert heute keinen mehr. Hört sich an als argumentieren hier Greise für awk als ob das etwas einfachere zeilenwerise einleisen von Textdateien für Trivialfälle heute noch ein Hammerargument sei. Leute wacht mal auf im Altersheim, wir haben 2019 nicht 1977.

              • 0
                Von klopskind am Mo, 22. April 2019 um 21:37 #

                Ich habe mein Bestes gegeben, Ihnen all' dies darzulegen; offenbar erfolglos.

                Zudem schreiben Sie hier Ihre subjektive Meinung und schließen von sich auf andere. Sie gehen in keiner Weise auf meine Argumente ein, oder versuchen diese zu entkräften.

                Auf dieser Grundlage werde ich diese Diskussion nicht fortführen.

              0
              Von Anonymous Coward am Mo, 22. April 2019 um 20:09 #

              Ich bin mir nicht sicher, ob Sie Brooke (s.o.) an dieser Stelle

              Ja so ist es richtig! Was ich nicht benutze ist schließlich überflüssig.
              richtig verstanden haben. Ich bin mir sicher, dass Brooke das sarkastisch meint, und das somit Kritik an der Argumentation des OP ist.
              Was ist daran "dümmlich" oder "verlogen"?
              Ich habe sehr wohl verstanden, was geschrieben wurde, Sie haben mich dagegen missverstanden. Was daran verlogen ist, dazu komme ich gleich.

              Der OP hat awk nicht kritisiert, weil er es nicht benutzt, [...]
              Doch!
              Ihr Zitat ist völlig aus dem Kontext gerissen. Das vollständige Zitat lautet:

              Der OP hat awk nicht kritisiert, weil er es nicht benutzt, sondern weil der Funktionsumfang von awk schon seit vielen Jahren in anderen Sprachen enthalten ist
              Ich bestreite also nicht, dass der OP awk kritisiert hätte, sondern ich bestreite, dass die Motivation für die Kritik der Nichtgebrauch von awk wäre. Und es gab auch keinen Grund, das anzunehmen, und deswegen ist es auch unehrlich und verlogen, ihn dafür zu kritisieren.

              Das stimmt soweit. Aber ist das die einzige Metrik, auf deren Grundlage Entscheidungen über die Wahl der zu verwendenden Werkzeuge (z.B. Programmiersprache) getroffen werden (können/sollten)?
              Wenn Werkzeug A alles kann, was Werkzeug B kann und noch mehr, und Werkzeug B in seinem Einsatzbereich gegenüber A keine wesentlichen Vorteile bietet, dann ist Werkzeug B überflüssig. Und ja, aufgrund von Synergieeffekten wäre es dann auch gut, wenn Werkzeug B baldmöglichst verschwinden würde.

              indem er fahrlässig von sich auf andere schließt.
              Hat er nicht getan (der Gebrauch des Wortes „ich“ steht dem nicht entgegen, genauso gut hätte er „man“ schreiben können).

              Das ist eine Behauptung, die es zu beweisen gälte. Wer sollte diesen Beweis nun führen? Ich schlage vor, dass diejenigen Personen hierfür verantwortlich sind, die diese Behauptung aufstellen. In diesem Fall wären das Sie und der OP.
              Man kann das sehr einfach am Funktionsumfang der Programmiersprachen festmachen. awk bietet schlichtweg keine Features, die es nicht auch in vergleichbarer Form in Perl gäbe.

              Ich schlage vor, dass die Bewertung und Entscheidung über die Eignung, Präferenz, Wahl oder Verwendung eines Werkzeugs (etwas anderes ist AWK oder eine andere Sprache - bzw. deren Implementierung - nicht) jedem Entwickler individuell obliegt
              Ich kann mich nicht erinnern, dass irgendjemand hier ein gesetzliches awk-Verbot befürwortet hätte.

              • 0
                Von klopskind am Mo, 22. April 2019 um 22:15 #

                Soweit, so gut!

                Ich kann allerdings Folgendes nicht ganz nachvollziehen:

                Wenn Werkzeug A alles kann, was Werkzeug B kann und noch mehr, und Werkzeug B in seinem Einsatzbereich gegenüber A keine wesentlichen Vorteile bietet, dann ist Werkzeug B überflüssig.
                Was heißt hier "alles"? Das ist mMn in jedem Fall anwendungsspezifisch also nicht rein objektiv zu verstehen.

                Die Formulierung dieses Sachverhalts und der dahinterstehenden Fragen ist mMn zu beschränkt.

                Tolle Sprachfeatures, Entwicklertools und Sprachökosysteme sind die eine Seite der Medaille. Es gibt aber noch andere Maßstäbe, die ein solches Werkzeug ggf. erfüllen müssen dürfte.
                Wie ich oben schon schrieb, kann es mitunter auch (oder gar vorrangig) um Abwägungen in anderen Dimensionen gehen, z.B.: vorhandene Kenntnisse (ggf. im Team), Größe des zusätzlichen Administrationsaufwands im Einsatz, Portierbarkeit, Minimalität und Ressourceneffizienz etc. pp.

                Meines Erachtens nach ist also die Komplexität einer solchen Abwägung (awk vs Alternative wie bspw. universelle Skript- o. Interpretersprache) deutlich höher als der OP mir zu verstehen gibt. Diese "Eindimensionalität" in der "Abwägung" des OPs kann ich demnach nicht teilen.


                Ich möchte mich an diesem Punkt nicht streiten, ob der OP von sich auf andere schließt. Da werden wir uns offenbar nicht einig.
                Für mich jedenfalls liest es sich eindeutig. Die einschlägigen Stellen hatte ich bereits zitiert.
                Eine schlüssige und gültige Argumentation auf so einer Grundlage aufzubauen, halte ich sachlich für äußerst gewagt und unprofessionell, sowie auf anderer Ebene sogar egozentrisch, ignorant und provokant.

                Man kann das sehr einfach am Funktionsumfang der Programmiersprachen festmachen. awk bietet schlichtweg keine Features, die es nicht auch in vergleichbarer Form in Perl gäbe.
                Das ist quasi das selbe Argument von oben.

                Was sind denn (Sprach-)Features für Sie? Zählen Verfügbarkeit mit extrem geringer zusätzlichem Administrationsaufwandes, Portierbarkeit, Leichtgewichtigkeit oder Ressourceneffizienz etwa nicht dazu? (Diese Faktoren können ggf. wichtig sein.) Falls nein, wieso nicht? Falls ja, welche Alternativen schlagen hier awk signifikant? Perl, Python oder Ruby sind es ja offensichtlich nicht, oder?

                Ich kann mich nicht erinnern, dass irgendjemand hier ein gesetzliches awk-Verbot befürwortet hätte.
                Ganz danach wirken die Kommentare des OP. Zitat: "Braucht doch seit keiner mehr" (Betreff) und "Sowas braucht und will keiner [...]"

        0
        Von fork am Mi, 17. April 2019 um 19:19 #

        Also wenn's Dir um's Recht haben geht, dann haben wir das ganz schnell:
        Du hast Recht. Sei glücklich damit!

        Es geht mir darum meine eigenen Erfahrungen mitzuteilen.

        Ich habe bereits selbst mal versucht awk mit Perl zu schlagen, vor allem in Sachen Kürze und Einfachheit. Ich habe es nicht geschafft.

        Wenn Du es selbst probieren möchtest, dann tue es: Im Forum von www.unix.com gibt es regelmässig Textverarbeitungsaufgabenstellungen, auch solche mit großen Datenmengen. Du kannst ja mal versuchen, in den alten Beiträgen solcher Probleme die awk-Lösungen mit ruby, python oder was auch immer zu schlagen hinsichtlich Geschwindigkeit, Einfachheit und Kürze.

        Ansonsten gibt es noch einen weiteren Punkt: Kompatibilität

        Wenn es um die Probleme geht, die man mit awk gut lösen kann, dann ist man hier mit allen verfügbaren Systemen kompatibel. awk gibt's überall. (Natürlich nicht gawk sondern nawk oder den originalen awk).

        Dieser Beitrag wurde 3 mal editiert. Zuletzt am 17. Apr 2019 um 19:22.
        • 0
          Von Anonymous Coward am Do, 18. April 2019 um 10:15 #

          Wenn es um die Probleme geht, die man mit awk gut lösen kann, dann ist man hier mit allen verfügbaren Systemen kompatibel. awk gibt's überall. (Natürlich nicht gawk sondern nawk oder den originalen awk).
          Sprich, es gibt x verschiedene Implementierungen, alle ein bisschen anders und ich habe keine Garantie, dass sich mein Script überall gleich verhält. Sorry, aber Perl und Python gibt's heute auch überall, mit dem Unterschied, dass die überall mehr oder weniger gleich sind.

          • 0
            Von 404namenotfound am Do, 18. April 2019 um 10:47 #

            Inwiefern ist "mehr oder weniger gleich" denn besser als "ein bisschen anders"? :x

            0
            Von fork am Do, 18. April 2019 um 12:05 #

            Sprich, es gibt x verschiedene Implementierungen, alle ein bisschen anders und ich habe keine Garantie, dass sich mein Script überall gleich verhält.

            Wenn man Kompatibilität möchte, dann kann man die haben. gawk unterstützt das durch die Optionen --traditional oder --posix. Das wäre die Garantie, die Du ansprichst.

            -c
            --traditional
            Run in compatibility mode. In compatibility mode, gawk behaves identically to Brian Kernighan's awk; none of the GNU-specific extensions are recognized. See GNU EXTENSIONS,
            below, for more information.

            -P
            --posix
            This turns on compatibility mode, with the following additional restrictions:

            · \x escape sequences are not recognized.
            · Only space and tab act as field separators when FS is set to a single space, newline does not.
            · You cannot continue lines after ? and :.
            · The synonym func for the keyword function is not recognized.
            · The operators ** and **= cannot be used in place of ^ and ^=.

            Dieser Beitrag wurde 3 mal editiert. Zuletzt am 18. Apr 2019 um 12:16.
            • 0
              Von Anonymous Coward am Mo, 22. April 2019 um 20:12 #

              Mit anderen Worten, wenn ich auf einem GNU-System ein Script entwickeln kann, muss ich immer mit dem -P-Flag testen, um zu verhindern, dass sich GNUismen einschleichen, und bevor ich das auf einem nicht-GNU-System deploye, muss ich daran denken, dieses -P-Flag wieder zu entfernen, weil dieses System vermutlich das -P-Flag nicht versteht. Na ganz toll.

              • 0
                Von klopskind am Mo, 22. April 2019 um 21:27 #

                Das Problem, das Sie hier beschreiben, besteht also auch bei Alternativen von (g)awk.

                Denn je nach System oder Plattform kommen verschiedenste Versionen der selben Sprache (oder ihrer nachgeladenen Erweiterungsmodule) zum Einsatz, sodass gewisse Features auf einer Plattform A möglicherweise nicht vorhanden ist, auf Plattform B hingegen schon.

                Als Ausweg bliebe auch hier nur ein Test der Version oder von Featureflags zur Laufzeit, oder aber die manuelle Installation der gewünschten Version.

Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung