Ermitteln aller Parameter eines Kommandos

[Romulus1689]

Hi Leute,
Ich bräuchte eine Möglichkeit um zu einem Kommando alle Parameter zu ermitteln. Am besten in einer Liste oder sowas. Die Sprache ist mir so ziemlich wurst.

Danke für eure Hilfe.

Romulus1689

 

[Gast1]

War die Frage ernst gemeint?

man Befehl

dürfte in > 99% hinhauen.

 

[Romulus1689]

Ich meine ein Liste von Parametern und nicht die gesamte Manpage oder der Schrott den man bei dem Parameter -h oder --help bekommt. Sonder zu tar z.B. eine Liste -x -z -f -v usw.

Gruß
Romulus1689

 

[Gast1]

Immer noch man, Abschnitt "SYNOPSIS".

 

[Romulus1689]

Also, ich hätte das gerne sofort in einer Form in der ich das direkt in ein Array oder eine Liste packen kann. Ohne Beschreibungen zu den Parametern oder sonst was. Einfach nur die Liste der Parameter. Im Abschnitt SYNOPSIS steht hinter jedem Parameter noch ein Kommentar dazu und außerdem ist der unter manchen Betriebsystemen bei bestimmten Kommandos nicht vorhanden (man perl)

 

[rikola]

Das ginge nur, wenn der Autor des Programmes so eine Ausgabe miteinprogrammiert haette. In der Regel wird das nicht der Fall sein.

 

[slackfan]

Das geht nicht, wie soll es auch. Du kannst höchstens die Manpage parsen oder per Brute Force Parameter gegen die Anwendung testen und die Rückgabe auswerten.

Wofür brauchst du das denn?

 

[Gast1]

Ich frage jetzt einfach mal aus echtem Interesse nach dem Sinn des Vorhabens, denn er erschliesst sich mir wirklich nicht.

Entweder kenne ich einen Parameter und dessen Bedeutung oder ich kenne ihn oder seine Bedeutung nicht, dann brauche ich beides.

Da könnte ich mir auch eine Zufallsliste mit 15 oder 20 "Parametern" bestehend aus "-" und einem Buchstaben [a-z,A-Z] generieren lassen und das als Ausgabe nehmen, das dürfte nicht nur einfach zu scripten sondern vom wirklichen Nutzen vergleichbar sein.

 

[Romulus1689]

Der sinn ist der, dass ich automatisierte Testszenarien mit Fuzz schreibe und da muss ich halt jedes Programm mit all seinen Parametern testen. Dazu brauche ich das.
Habe gehofft das ich mich darum drücken kann die Manpage mit Perl zu parsen aber es geht scheinbar nicht anders..

Danke für eure Hilfe

 

[slackfan]

Es gibt Testszenarien, in denen geprüft wird, ob ein Parameter akzeptiert wird? Wofür soll das denn gut sein? Es ist doch höchstens interessant, ob der Parameter tut, was er soll. Und was ist, wenn die Manpage fehlerhaft oder nicht aktuell ist? Pflegen musst du es so oder so...

 

[Gast1]

Der sinn ist der, dass ich automatisierte Testszenarien mit Fuzz schreibe und da muss ich halt jedes Programm mit all seinen Parametern testen. Dazu brauche ich das.

Akzeptiert, aber dann noch eine weitere Frage (vielleicht nutzt sie Dir ja auch etwas).

Was machst Du, wenn ein Parameter noch (ein) weitere(s) Argument(e) braucht?

Das dürfte dann ziemlich schnell beliebig kompliziert werden.

 

[Romulus1689]

Ich bin Informatiker, also versuche ich erstmal einen Teil meines gesamten Problemes zu lösen ;-)
Aber danke für die Anmerkung :-)

 

[pyropeter]

ich finde die vorgehensweise extrem seltsam. des sinn eines automatisierten tests ist doch, die richtige funktion eines tools zu prüfen, indem man es mit vordefinierten argumenten aufruft und das ergebnis mit einem, ebenfalls vorgegebenen, vergleicht.

( Wobei beispielsweise bei pulseaudio schon viele segfaults durch simples aufrufen mit zufälligen argumenten entdeckt werden könnten :-P )

 

[saeckereier]

Genau, was bringt es ein Programm mit allen möglichen Paramtern aufzurufen? Zumal ich mal behaupten würde, dass das nicht zielführend sein kann, bei der Anzahl möglicher Parameter. Dazu kommt noch, dass oft ein Parameter bestimmt, ob andere überhaupt Sinn machen.

Und dann zuletzt: Wie soll der Test prüfen, ob das gewünschte Ergebnis eintrifft, schliesslich weiss das Testprogramm nicht, was der Parameter aus irgendeinem Array bewirken soll. Ich kann mir bei allem guten Willen kein Szenario, wo das sinnvoll sein könnte vorstellen..

 

[bytepool]

Hi,

ich finde die vorgehensweise extrem seltsam. des sinn eines automatisierten tests ist doch, die richtige funktion eines tools zu prüfen, indem man es mit vordefinierten argumenten aufruft und das ergebnis mit einem, ebenfalls vorgegebenen, vergleicht.

du meinst Unit Tests, er sprach aber von Fuzzing: http://de.wikipedia.org/wiki/Fuzzing.

Genau, was bringt es ein Programm mit allen möglichen Paramtern aufzurufen? Zumal ich mal behaupten würde, dass das nicht zielführend sein kann, bei der Anzahl möglicher Parameter. Dazu kommt noch, dass oft ein Parameter bestimmt, ob andere überhaupt Sinn machen.

Und dann zuletzt: Wie soll der Test prüfen, ob das gewünschte Ergebnis eintrifft, schliesslich weiss das Testprogramm nicht, was der Parameter aus irgendeinem Array bewirken soll. Ich kann mir bei allem guten Willen kein Szenario, wo das sinnvoll sein könnte vorstellen..

Auch wenn einige der Argumente Sinn machen, wuerde ich auch dir anraten einen Artikel ueber Fuzzing zu lesen, das sollte deine Fragen beantworten.

Allerdings habe ich auch meine Zweifel ob es Sinn macht, eine allgemeine Loesung fuer Programmaufrufe zu schreiben. Denn wie R_M und saeckereier ja schon voellig zu Recht anmerkten, macht die Geschichte sofort keinen Sinn mehr, wenn weitere spezielle Parameter gebraucht werden. Ausserdem sind viele Parameter ja auch nur "switches" die gar keine Eingaben erwarten.

Also entweder schreibst du ein Fuzzing Tool/Skript das auf ein bestimmtes Programm zugeschnitten ist, was mit Abstand am effektivsten sein sollte, oder du nimmst wieder R_Ms Hinweis, und gehst wirklich der Reihe nach das Alphabet durch, und probierst einfach alles aus. Ich denke wenigstens fuer einstellige Parameter koenntest du da ein gewisses Mass an sinnvollem Fuzzing betreiben, auch wenn du ohne Ende Fehlermeldungen wegen falschem Programmaufruf bekommen wirst.

mfg,
bytepool

 

[saeckereier]

Gelesen und nicht für gut befunden :-)
Ich teile die Auffassung immer noch nicht, dass gerade fuzzing so sinnvoll ist. Insbesondere nicht im vorgestellten Fall. Kleiner Tipp: Bitte nicht rm fuzzen, sonst kommt noch rm -rf .* raus :-) Aber zur Ursprungsfrage: Ich sehe da keine Möglichkeit.