Aufgeblähter Echo-Befehl

In ihrem Artikel "Programm Design in der UNIX-Umgebung", Pike & amp; Kernighan diskutieren, wie das cat -Programm Kontrollargumente anwendete. Irgendwo, obwohl nicht dieser Artikel, gab es einen Kommentar über ' cat kam von Berkeley zurück, winkende Fahnen'. Dies ist ein ähnliches Problem mit dem Problem mit echo Entwicklungsoptionen. (Ich fand einen Verweis auf den relevanten Artikel in der BSD (Mac OS X) man-Seite für cat : Rob Pike, "UNIX-Stil oder Katze-v als schädlich" , USENIX Summer Conference Proceedings , 1983. Siehe auch Ссылка )

In ihrem Buch 'The UNIX Programming Environment' haben Kernighan & amp; Pike (ja, diese beiden wieder) zitieren Doug McIlroy zum Thema, was "Echo" ohne Argumente (ca. 1984) tun sollte:

  

Eine weitere Frage der Philosophie ist, was echo tun sollte, wenn keine Argumente angegeben werden - speziell, ob es eine Leerzeile oder gar nichts ausgibt. Alle aktuellen echo Implementierungen, die wir kennen, drucken eine leere Zeile, aber frühere Versionen nicht, und es gab große Debatten zu diesem Thema. Doug McIlroy hat in seiner Diskussion über das Thema die richtigen Gefühle der Mystik vermittelt:

Das UNIX und das Echo

  Es wohnte im Land von New Jersey, der Unix, einer schönen Magd, die die Gelehrten weit gereist waren, um sie zu bewundern. Von ihrer Reinheit geblendet, versuchten alle, sie zu unterstützen, einen für ihre jungfräuliche Gnade, einen anderen für ihre geschliffene Höflichkeit, noch einen für ihre Beweglichkeit bei der Ausführung anspruchsvoller Aufgaben, die selbst in viel reicheren Ländern selten erreicht wurden. Sie war so großherzig und entgegenkommend, daß die Unix alle unerreichbarsten ihrer Bewerber annahm. Bald wuchsen und blühten viele Nachkommen und breiteten sich bis an die Enden der Erde aus.

     

Die Natur selbst lächelte und antwortete dem UNIX eifriger als anderen sterblichen Wesen. Bescheidene Leute, die wenig von höfischen Manieren kannten, freuten sich an ihrem Echo, so klar und kristallklar, dass sie kaum geglaubt hatten, dass sie von den gleichen Felsen und Wäldern beantwortet werden konnte, die ihre eigenen Schreie in die Wildnis verstümmelten . Und das konforme UNIX musste mit dem perfekten Echo von allem, was sie verlangte, mithalten.

     

Als ein ungeduldiger Schwager die UNIX, 'Echo nichts' fragte, öffnete der UNIX bereitwillig ihren Mund, wiederholte nichts und schloss ihn wieder.

     Was meinst du ?, verlangte der Junge, den Mund so zu öffnen? Von nun an öffne niemals deinen Mund, wenn du nichts wiederholen sollst! Und das UNIX verpflichtet.

     "Aber ich will eine perfekte Aufführung, selbst wenn du nichts widerspielst", flehte ein sensibler Jüngling, "und aus einem geschlossenen Mund können keine perfekten Echos kommen." Da er keins beleidigen wollte, erklärte sich das Unix bereit, für die ungeduldige Jugend und die unsensible Jugend andere Dinge zu sagen. Sie nannte das sensible Nichts ' \n '.

     

Aber jetzt, als sie ' \n ' sagte, sagte sie nicht wirklich nichts, also musste sie zweimal den Mund aufmachen, einmal ' \n ' sagen und einmal nichts sagen, und so gefiel ihr das nicht sensible Jugend, die sofort sagte: "Das \n klingt für mich wie ein perfektes Nichts, aber das zweite ruiniert es. Ich möchte, dass du einen von ihnen zurückholst. Also stimmte der Unix, der nicht beleidigen konnte, einige Echos auf und nannte das " \c ". Jetzt konnte die sensible Jugend ein perfektes Echo von nichts hören, indem sie gemeinsam nach ' \n ' und ' \c ' fragte. Aber sie sagen, dass er an einem Übermaß an Notation gestorben ist, bevor er jemals einen gehört hat.

Die Korn-Shell hat einen printf -Befehl eingeführt (oder zumindest enthalten), der auf der Funktion printf() der C-Sprache basiert und eine Formatzeichenfolge verwendet, um zu steuern, wie das Material aussehen soll. Es ist ein besseres Werkzeug für komplizierte Formatierungen als echo . Aufgrund der im Zitat angegebenen Geschichte echo echo jedoch nicht mehr. es interpretiert, was es gegeben wird, um zu widerhallen.

Und die Befehlszeilenargumente zu echo zu interpretieren, erfordert zweifellos mehr Code als sie nicht zu interpretieren. Ein Basis-Echo-Befehl ist:

Es gibt andere Möglichkeiten, das zu erreichen. Aber die komplexeren Versionen von echo müssen ihre Argumente überprüfen, bevor sie etwas drucken - und das erfordert mehr Code. Und verschiedene Systeme haben entschieden, dass sie unterschiedliche Interpretationen ihrer Argumente durchführen wollen, was zu unterschiedlichen Mengen an Code führt.

Sie werden bemerken, dass es nicht wirklich so viel Aufblähung gibt.

1. Die meisten Codezeilen sind Kommentare.
2. Die meisten Codezeilen, bei denen es sich nicht um Kommentare handelt, sind Nutzungsdokumentationen. Wenn also jemand 'echo --help' tut, wird etwas unternommen.
3. Code außerhalb des oben Angezeigten scheint hauptsächlich mit den Argumenten umzugehen, die echo annehmen kann, sowie der "speziellen" Erweiterung für Symbole wie \ n und \ t, um ihre äquivalenten Zeichen zu sein, anstatt sie wörtlich zu wiederholen.

Außerdem führen Sie meistens gar nicht den echo-Befehl aus, meistens ruft echo eine eingebaute Shell auf. Zumindest auf meinem Rechner müssen Sie /bin/echo --help eingeben, um alle erweiterten Funktionen / Dokumentationen zu erhalten, da echo --help lediglich echos --help

Führen Sie dies für ein gutes Beispiel in Ihrer Shell aus.

Dann führe das aus:

Und Sie werden sehr unterschiedliche Ergebnisse bemerken.

Erstere wird nur die Eingabe wie sie ist ausgeben, aber letztere wird hello rot drucken.

Ein anderes Beispiel, das den 'hex' Code verwendet:

Sehr unterschiedliches Verhalten. Die openbsd-Implementierung kann dazu nicht =).

Ich bin mir nicht sicher, ob mir die erste Implementierung gefällt: Sie hat eine Option zu viele!

Wenn eine -n -Option erforderlich war, dann wäre auch das Hinzufügen einer -- -Option zum Stoppen der Optionsverarbeitung hilfreich. Auf diese Weise erhalten Sie kein inkonsistentes Verhalten, wenn Sie ein Shellskript schreiben, das Benutzereingaben liest und ausgibt, wenn der Benutzer -n eingibt.