[linux-l] Webanwendungen per Kommandozeile ansteuern

Volker Grabsch vog at notjusthosting.com
So Dez 4 10:51:00 CET 2005


On Sun, Dec 04, 2005 at 06:53:52AM +0100, olafBuddenhagen at gmx.net wrote:
> > > > Kenne httptool nicht, denke aber (Deinem bischen Code entnehmend)
> > > > lautet die Antwort "nein".
> > > 
> > > Das war ne Erfindung. Genau wie dein "docfind". Nur eben
> > > allgemeiner.
> > > 
> > > 	httptool http://www.google.de/search --q="Suchstring"
> > > 
> > > würde dann an "http://www.google.de/search" per HTTP-GET oder -POST
> > > den entsprechenden CGI-Parameter übermitteln. So war meine Idee.
> 
> Ich hoffe Dir ist bewusst, dass wget, lynx und Konsorten entsprechende
> Optionen haben.

Es ging mir vorallem darum, dass man
1. Kommandozeilen-Optionen hat, die besser lesbar, besser tippbar, und
   vorallem viel gewohnter sind.
2. einem das Escaping abgenommen wird. Okay, die Shell hat auch ihre
   Sonderzeichen, aber das muss man nicht nochmal extra verschlimmern.

> > > Wenn die Ausgabeseite dann durch "w3m", "lynx" oder "w3m -dump"
> > > gejagt wird, wäre das IMHO ein sehr nettes allgemeines Tool für
> > > Remote- Zugriffe und -Suchanfragen, genauso wie du es haben
> > > wolltest.
> 
> Wieso so umständlich? GET-Anfragen zu generieren ist trivial. Ein
> 
>    w3m google.com/serach?q=foo
> 
> oder
> 
>    w3m dict.leo.org?search=bar
> 
> tut's wunderbar, wenn man nicht gerade nach Sonderzeichen suchen will.

Ähhm ... bei URLs gehören sogar Leerzeichen zu den Sonderzeichen. Ich
meine, mit der Shell soll man ordentlich arbeiten können.

Stattdessen sind dann entsprechende Shell-Scripts, die sowas machen
(z.B. surfraw) so aufgebaut, dass dort entsprechende Escaping-Routinen
aufgerufen werden. Genau diesen Dreck wollte ich vermeiden, denn auf
*diese* Weise werden die Shell-Scripte komplizierter, unsauberer
(fehleranfälliger), etc.  Es ist auch so schon schwierig genug,
Shell-Scripte zu schreiben, bei denen es nicht gleich knallt, wenn
ein Parameter mal ein Leerzeichen o.Ä. enthält.

> (Wobei tatsächlich nur sehr wenige Zeichen Probleme machen, die in URLs
> eine spezielle Bedeutung haben.)

Aber eben diese Zeichen braucht man öfters. Wenn ich nach

	site:de.wikipedia.org "Das ist das Haus vom Nikolaus"

suche, dann kann ich das ohne Probleme in der Shell escapen:

	sr google 'site:de.wikipedia.org "Das ist das Haus vom Nikolaus"'

bzw. mit dem imaginären "httptool":

	httptool http://www.google.de/search \
		--q='site:de.wikipedia.org "Das ist das Haus vom Nikolaus"'

Willst du dafür die entsprechende URL zusammenfrickeln? Viel Spaß.
Sonderzeichen sind unter anderem:   ':', ' ' und '"'
Wenn diese (sehr, sehr gängigen) Zeichen gegen %xx ersetzt werden,
sieht kein Schwein mehr auf Anhieb, was das zu bedeuten hat. Ich
würde von niemanden verlangen, so etwas an der Kommandozeile direkt
einzutippen, und dann behaupten, es wäre irgendwie "einfach" oder
gar "benutzerfreundlich" oder wie du es nennst: "trivial".  Auf diese
Sorte von "trivialem Shellcode" kann die Welt verzichten.


Außerdem finde ich es gar nicht gut, wie das in Shell-Scripten und auch
PHP-Scripten allgemein läuft: Statt z.B. in PHP ne Funktion zu haben,
die mehrere Argumente entgegen nimmt, einen für das Programm und die
anderen für die Parameter (wie die exec*()-Funktionen in C), ruft man
das Zeug im Stile einer Kommandozeile auf, und muss alle kritischen
Leerzeichen etc. erstmal durch Escaping-Funktionen jagen. Das ist viel
umständlicher und außerdem unsicherer, weil man schnell mal was doppelt
escaped oder das Escaping vergisst, oder nicht mehr genau weiß, welches
Unterprogramm was schon escaped hat und was nicht.

Das surfraw arbeitet genauso, zwar nicht in PHP aber in Shell-Script.
Auch da gibt es keine gescheite Funktion, die den URL-Aufruf mitsamt
Quoting übernimmt. Nein, lediglich das Escaping ist eine extra Funktion,
und damit werden dann solche Hampeleien gemacht:

	escaped_args=`w3_url_of_arg $w3_args`
	[...]
	w3_browse_url "http://www.google.com/${SURFRAW_google_search}?q=${escaped_args}&num=${SURFRAW_google_results}"

[aus: /usr/lib/surfraw/google]

Und auch hier die Frage: Ganz sicher, dass alle Variablen sauber escaped
wurden? Nicht, dass ich dem Autor Schlampigkeit unterstellen möchte, ich
finde es einfach nur ein Unding, dass es diese mögliche Fehlerquelle
überhaupt gibt, und dass man in dem gesammten Programm an jeder Stelle
darauf achten muss.


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR



Mehr Informationen über die Mailingliste linux-l