Changes between Version 4 and Version 5 of skripte-als-webservice

Timestamp:

Aug 8, 2011, 1:27:50 PM (13 years ago)

Author:

Wolfgang Schmidle

Comment:

--

skripte-als-webservice

@@ -15 +15 @@
 Ich verwende jetzt Getopt::Long (und Pod::Usage). Dadurch ergibt sich recht natürlich folgendes Format, das auch für Textfilter funktioniert:
 
- perl Filter_insert-reg [options] [file]
+ perl script [options] [file]
 
 Wahrscheinlich ist dieses Format auch pipe-tauglich, aber das habe ich bisher nur sehr oberflächlich getestet.
@@ -40 +40 @@
 Parameter --dir besser mit / am Ende? Bisher: wenn es $dir gibt, hänge $dir/ vorne an den Dateinamen dran. Mit / könnte ich $dir einfach auf Verdacht ohne Änderungen dranhängen. Oder: Wenn $dir ungleich "" ist, aber nicht mit / endet, hänge / dran? Was ist üblich?
 
-Input und output sind immer UTF-8. Der input wird im Skript wie bisher mit "while(<>)" ausgelesen. Das funktioniert mit STDIN und Dateinamen. Ich verwende jetzt doch nicht "input=", weil alles, was nicht eine Option ist, als Dateiname interpretiert wird. (Mehr als ein Dateiname ist eigentlich bei keinem Skript sinnvoll, aber es ist nicht verboten). Ich verwende auch kein "output=", weil die defaults STDOUT für Text und STDERR für Fehlermeldungen eigentlich gut genug sind. Falls nötig, kann ich in die Fehlermeldungen auch noch Fehler-Codes hineinschreiben.
+Input und output sind immer UTF-8. Der input wird im Skript wie bisher mit "while(<>)" ausgelesen. Das funktioniert mit STDIN und Dateinamen. Ich verwende jetzt doch nicht "input=", weil alles, was nicht eine Option ist, als Dateiname interpretiert wird. (Mehr als ein Dateiname ist eigentlich bei keinem Skript sinnvoll, aber es ist nicht verboten). Ich verwende auch kein "output=", weil die defaults STDOUT für Text und STDERR für Fehlermeldungen eigentlich gut genug sind. Umleitungen kann man dann auf der Commandline mit Unix-Mitteln machen. 
+
+Error conditions: Wenn ein Skript nach STDERR schreibt, wird die Verarbeitung des Skripts oder der pipe abgebrochen. Falls nötig, kann ich in die Fehlermeldungen auch noch Fehler-Codes hineinschreiben.
 
 == Wo nach Optionen gesucht wird
@@ -72 +74 @@
 Ob das Skript als Textfilter als Textfilter aufgerufen wird, erkennt es daran, dass die runtime environment variable $ENV{'BB_DOC_NAME'} existiert. Das ist BBEdit-spezifisch. Für Textwrangler oder andere Editoren wäre es anders. 
 
-Wenn man bereits Parameter in <parameters> angegeben hat, werden deshalb trotzdem auch noch die Parameter aus der zusätzlichen Datei eingelesen. Alternative wäre, zum Beispiel zu prüfen, ob in Schritt 1 und 2 irgendwelche Optionen gesetzt wurden. Dann würden beim Aufruf auf der Commandline ohne jeden Parameter die Standard-Parameter aus der zusätzlichen Datei verwendet werden, aber sobald man irgendeinen Parameter setzt, wird die zusätzlich Datei nicht mehr eingelesen. Welche Variante führt zu möglichst wenig Verwirrung?
+Wenn man bereits Parameter in <parameters> angegeben hat, werden deshalb trotzdem auch noch die Parameter aus der zusätzlichen Datei eingelesen. Der Aufruf auf der Commandline ohne Parameter 
+ perl script file
+wäre dann nicht identisch mit dem Aufruf als Textfilter.
+
+Alternative wäre, zum Beispiel zu prüfen, ob in Schritt 1 und 2 irgendwelche Optionen gesetzt wurden. Dann würden beim Aufruf auf der Commandline ohne jeden Parameter wie bei der Verwendung als Textfilter die Standard-Parameter aus der zusätzlichen Datei verwendet werden, aber sobald man irgendeinen Parameter setzt, wird die zusätzlich Datei nicht mehr eingelesen. Welche Variante führt zu möglichst wenig Verwirrung?
 
 Nachbilden der Möglichkeit, den Textfilter mit einem Ausschnitt einer Datei aufzurufen: Optionen wie "startzeile" und "endzeile" oder gar die genauen Spalten haben wir ja erstmal verschoben. Vielleicht könnte man das auch sowieso besser im Webservice-Wrapper machen. Dann muss es nicht in jedem Skript einzeln stehen. (BBEDIT übergibt übrigens runtime environment variables für Startzeile und -spalte etc. an den Textfilter).