[linux-l] Re: Mac und Linux

[Oliver Bandel]

On Tue, Aug 08, 2006 at 11:19:00AM +0200, Peter Ross wrote:
> Hi Oliver,
> 
> Oliver Bandel wrote:
> 
> > Ansonsten hat man das Problem, daß man *garnix* steuern kann und beim M
> > igrieren
> > der eigenen Skripte u.U. auf die Nase fällt (rewrite from scratch;
> > Portierungsaufwand; Irritation der Benutzer (und der Programmierer)).
> 
> wie ich schon erwaehnte, hast Du eher etwas Undokumentiertes bemerkt und
> benutzt. Haettest Du mit der Manpage angefangen, dann waer's Dir nicht
> passiert.

Ach ja, stimmt. Habe eben mal auf der ls-manpage auf nem Linux-System nachgeschaut.
Da steht das auch so drin, wie Du sagst (ist dann quasi genauso wie unter OS-X,
zumindest, was den Punkt angeht.)

Als User wundere ich mich. Da war es mir erst mal wurscht, wieso das
so ist. (Müsste ich da wieder was programmieren, würde ich dann nochmal
genauer schauen. Aber aus User-Sicht ist es jedenfalls angenehm, dieses
undokumentierte Feature. Und doof, wenn es nicht geht. OK, muss es ja laut
Doku nicht, dann darf ich mich da wohl nicht drüber aufregen ;-) )


> 
> Ich verstehe Deine Argumentation schon, halte es aber fuer wichtiger, dass
> Skripte, die Programme entsprechend ihrer Dokumentation benutzen, _immer_
> und zuverlaessig funktionieren, statt andersrum eher "missbraeuchlich"
> diese verwendende portierbar gemacht werden.

OK, das habe ich übersehen; habe Deinen Beitrag zwar gelesen, aber erst jetzt sackt es. ;-)
War zu viel Bier die letzten Tage und zu wenig Schlaf. ;-(

> 
> Einer der Gruende fuer meine eher traditionell "#!/bin/sh" verwendenden
> Skripte, das macht mich habwegs sicher gegen die Featuritis der bash. Wer
> weiss, wer da demnaechst irgendwelche glorreichen neuen Ideen
> verwirklicht, so dass mein Skript nicht mehr funktioniert, wenn ich nicht
> den neueingefuehrten Schalter "FEATURE_OFF" setze (weil vielleicht auch
> noch von irgendjemand "FEATURE_ON" in einem rc-File systemweit gesetzt
> wurde).

Ist die Bash so dermassen konfigurabel?
(Wie gesagt, was die Shell-Argumente von mir anging, war das ja eher
 vermutend und fragend gemeint. Die Beiträge zu den Libs müsste ich noch
 lesen, da hatte ich im Moment keinen Nerv drauf, da ich das aus purer
 User-Sicht betrachtete. (Aus "verwöhnter User"-Sicht ;-)) )


> 
> Stell Dir vor, es gibt eine versehentlich angelegte Datei "-rf" und Deine
> Shell sortiert das zu den Optionen, bevor ich alle Dateien mit rm
> loesche:-(

Naja, war ja kein Design-Vorschlag, der umbedingt gemacht werden müsse,
sondern Gedanken zu den Dingen, wie sie mir durch den Kopf gingen, frisch
entstanden, womöglich etwas unausgegoren.
Heute hatte ich mal etwas im Park gesessen und etwas Sonne getankt, und dann
ging mir das nochmal durch den Kopf.... Wenn man Args hat, wo man z.B.
$ programmname -o outfile -i infile 
hat, dann dachte ich: "Oh weh, und was dann?!", aber auch das würde ja passen:
==> argv: "programmname", "-o", "-i", "outfile", "infile"
geht also. Darf man nur nicht alphabetisch sortieren ;-)
Und wie das mir anderen Args ist habe ich mir noch nicht ausgeknobelt.

War halt ne Idee.
Eigentlich fände ich eine Shell, die Typprüfungen macht ganz gut,
aber ich weiss nicht, ob es so eine auch gibt.

Egal, wie man's nimmt, das letzte mal wo ich mit getopt() gearbeitet habe ist schon
lange her, müsste da also nochmal in der Manpage suchen; aber ich fand es
zwar hilfreich, aber so richtig toll nicht.


> 
> Eine leichte Analogie: Vor etlichen Jahren habe ich mal beim
> C-Programmieren unter einem Unix die schoensten Fehler bekommen, als
> LC-Variablen systemweit auf deutsche Locale umgestellt wurden. Der
> Compiler wollte nun Zahlen mit "," statt ".". Schoen fuer ein interaktives
> Programm beim Eingeben, fuer meinen Raytracing-Algorithmus, der
> standardisierte Inputfiles verwendete, aber eher toedlich.
> 
> Natuerlich laesst sich auch das programmiertechnisch beheben, aber
> haettest Du es erwartet?
[...]

Hattest Du das umgestellt mit den Locales?

Naja, egal... ich glaube, ich hätte mich auch gewundert.
Ich verstehe auch nicht ganz, was sich da geändert hatte.
Wieso hat der *Compiler* andere Zahlen erwartet?
Meinst Du den Compiler der Sprache, in der der Raytraycer geschrieben war?
Oder war da irgend eine Library am Werke?

Ich finde manche Effekte der Locales auch nervig.
Andererseits können die sicherlich auch recht hilfreich sein.
Mit dem Zeugs habe ich mich nicht so sehr beschäftigt.
Ich lasse es meist eh auf englisch. Die deutschen Fehlermeldungen
finde ich irgendwie gestelzt. ;-)

OK, ich war auf dem Pfad der Untugend, da ich nicht der Doku gefolgt bin...
mea culpa. ;-)

Aber was solls, hat ein paar Gedanken angeregt, mal zu überlegen,
ob man das als Features nicht überall anbieten sollte. Aber
wenn das eh kein offizielles Feature ist.... hmhh, ok,
dann ist es Schuld-Eigen, wenn man dann solche Skripte baut
und die dann nicht funktionieren. ;-)
Dann nehme ich also die Forderung nach dem Feature zurück,
freue mich aber dennoch manchmal, daß es geht.

Ne Typprüfung der Args fände ich aber garnicht so schlecht. :)
Dann würden alnums nicht akzeptiert, wenn man ein int haben will
usw.
Dann muss man das als Programmierer nicht machen, sondern
die Opt-Parse-Lib macht das, oder es gibt Regeln, anhand derer
die Shell erkennen kann, welche Args welchen Typ haben/haben dürfen,
und würden das entspr. Programm garnicht erst aufrufen.

( Aber das ist auch wieder erst ma nur ne Idee. Ob sich das als sinnvoll
  erweist, wenn das die Shell macht, weiss ich nicht; kann ich mir aber
  schon denken. Aber vielleicht ist das auch zu viel Featuritis und das
  jew. Program macht das besser selbst? Aber wenn jedes Programm eh einen
  festgelegten Typ hat, dann könnte doch die Shell die Typprüfung doch
  übernehmen....
    ...OK, OK, genug Ideen-Wirrwarr... ;-) )


Gruß,
   Oliver