Hi!
Seit ueber einem Jahr hacke ich nun an "dmd", einer Software die die Verwaltung von Diensten besser regeln soll als System V Init (und besser als alle bisherigen Alternativen). Mich wuerden nun Meinungen interessieren zu einem ganz bestimmten Aspekt der Benutzer-Schnittstelle.
Um Aktionen durchzufuehren wie das Starten von Diensten, aber auch Dienst-spezifische Dinge wie "reload-modules" bei Apache, wird das Kommando "deco" verwendet:
# deco start apache
# deco reload-modules apache
Weitere Argumente koennen danach angegeben werden:
# deco load dmd foo.scm
# deco doc apache list-actions
Nun stellt sich mir die Frage, ob es dabei nicht weniger irritierend waere, die Reihenfolge von AKTION DIENST zu aendern auf DIENST AKTION:
# deco apache start
# deco apache reload-modules
# deco dmd load foo.scm
# deco apache doc list-actions
Der Nachteil ist, dass es in einfachen Faellen weniger natuerlich wirkt ("start apache" entspricht genau dem, was man meint, waerend ich "/etc/init.d/apache start" immer furchtbar fand); der Vorteil ist, dass es logischer erscheint, wenn die weiteren Argumente direkt nach dem Namen der Aktion kommen (und jetzt schlage mir bloss keiner vor, "deco load foo.scm dmd" zu verwenden <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> ).
Was faendet ihr sinnvoller?
Cheers,
GNU/Wolfgang
Kommandozeilen Interface
-
Andreas B.
Re: Kommandozeilen Interface
also ich würde soetwas wie "deco start apache" vorziehen, unter der Voraussetzung, dass
deco, wenn es nur mit "deco" aufgerufen wird, eine Pseudoshell, ähnlich der Packetauswahl des Installers
von Rocklinux(1) Serie 1.4, zur Verfügung stellt, in der dann ein "status" den Status aller Dienste anzeigt
,
ein "deco status" würde es dann direkt auf der Shell ausgeben, wäre also der nicht Wiedereintrittsweg.
ein DiensteGlobbing wäre auch noch eine feine Sache.
(1) <a href="http://www.rocklinux.org" target="_blank"><!--auto-->http://www.rocklinux.org</a><!--auto-->
deco, wenn es nur mit "deco" aufgerufen wird, eine Pseudoshell, ähnlich der Packetauswahl des Installers
von Rocklinux(1) Serie 1.4, zur Verfügung stellt, in der dann ein "status" den Status aller Dienste anzeigt
,ein "deco status" würde es dann direkt auf der Shell ausgeben, wäre also der nicht Wiedereintrittsweg.
ein DiensteGlobbing wäre auch noch eine feine Sache.
(1) <a href="http://www.rocklinux.org" target="_blank"><!--auto-->http://www.rocklinux.org</a><!--auto-->
-
tut
Re: Kommandozeilen Interface
Ich finde deco DIENST AKTION sinnvoller.
Es gibt nicht soviele DIENSTe, aber man kann wie es aussieht sehr viele AKTIONen durchführen, die jeweil von dem DIENST abhängen.
Hierarchisch gesehen würde also deco DIENST AKTION mehr Sinn machen: Von der Wurzel zu den Blättern(details).
Ein anderes Beispiel:
bash completion würde bei deco <TAB> die Liste der möglichen Dienste vorschlagen und gegebenenfalls vervollständigen. Wenn deco apache <TAB> gedrückt wird könnte die Liste der Aktionen für den Apache gelistet werden.
Auch wenn deco start apache in der Denk- und Leseflussrichtung ist, meine ich das es hier ziemlich fehl am Platz wäre.
Vom allgemeinen zu speziellen ist die bessere Variante.
HTH
Es gibt nicht soviele DIENSTe, aber man kann wie es aussieht sehr viele AKTIONen durchführen, die jeweil von dem DIENST abhängen.
Hierarchisch gesehen würde also deco DIENST AKTION mehr Sinn machen: Von der Wurzel zu den Blättern(details).
Ein anderes Beispiel:
bash completion würde bei deco <TAB> die Liste der möglichen Dienste vorschlagen und gegebenenfalls vervollständigen. Wenn deco apache <TAB> gedrückt wird könnte die Liste der Aktionen für den Apache gelistet werden.
Auch wenn deco start apache in der Denk- und Leseflussrichtung ist, meine ich das es hier ziemlich fehl am Platz wäre.
Vom allgemeinen zu speziellen ist die bessere Variante.
HTH
Re: Kommandozeilen Interface
Hi!
Ganz klar, ich fände AKTION DIENST sinnvoller. Erstens ist es logischer, wenn die Argumente für den Dienst direkt hinter DIENST kommen (AKTION ist ein Argument von deco), und zweitens kann man dann schreiben:
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">alias start='deco start'</font><hr></pre></blockquote>
Gruß,
hjb
Ganz klar, ich fände AKTION DIENST sinnvoller. Erstens ist es logischer, wenn die Argumente für den Dienst direkt hinter DIENST kommen (AKTION ist ein Argument von deco), und zweitens kann man dann schreiben:
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">alias start='deco start'</font><hr></pre></blockquote>
Gruß,
hjb
Pro-Linux - warum durch Fenster steigen, wenn es eine Tür gibt?
-
Wolfgang
Re: Kommandozeilen Interface
Hi!
Andreas B. schieb:
> also ich würde soetwas wie "deco start apache" vorziehen, unter der Voraussetzung, dass deco, wenn es nur mit "deco" aufgerufen wird, eine Pseudoshell, ähnlich der Packetauswahl des Installers von Rocklinux(1) Serie 1.4, zur Verfügung stellt,
Wird implementiert. Wobei ich denke, dass man das selten brauchen wird, wenn es Runlevel und automatisches Aufloesen von Abhaengigkeiten gibt.
> in der dann ein "status" den Status aller Dienste anzeigt, ein "deco status" würde es dann direkt auf der Shell ausgeben, wäre also der nicht Wiedereintrittsweg.
Da habe ich zwei Einwaende gegen: Erstens waere das inkonsistent und wuerde die Struktur des Interface komplizierter machen, zweitens ist es auch nicht vollkommen logisch, denn fuer die Verwaltung der Dienste letztlich zustaendig ist der Daemon "dmd", daher sollte das Anzeigen des Status aller Dienste eine Aktion des Dienstes "dmd" sein (und ist es gegenwaertig auch), womit die Konsistenz gewahrt ist.
> ein DiensteGlobbing wäre auch noch eine feine Sache.
Welchen praktischen Nutzen haette das? Ist "deco restart tty*" wirklich so nuetzlich? Wenn mehrere Dienste zusammengehoeren, wuerde ich das eher anders loesen, etwa ueber eine Service-Group (was nicht wirklich ein eigenstaendiges Konzept ist, sondern nur ein normaler Dienst, der quasi alles an mehrere Dienste weiterreicht).
tut schrieb:
> Ich finde deco DIENST AKTION sinnvoller.
> Es gibt nicht soviele DIENSTe, aber man kann wie es aussieht sehr viele AKTIONen durchführen, die jeweil von dem DIENST abhängen.
> Hierarchisch gesehen würde also deco DIENST AKTION mehr Sinn machen: Von der Wurzel zu den Blättern (details).
Wie viele Dienste es gibt, haengt von der Installation ab. Auf meinem Debian 3.0 System hier gibt es fast 50 in /etc/init.d/ obwohl ich ein relativ minimalistisches System habe. Das sind wohl mehr Dienste als je ein Dienst Aktionen haben wird. Abgesehen davon, dass dies alleine ohnehin kein sehr ueberzeugendes Argument waere.
> bash completion würde bei deco <TAB> die Liste der möglichen Dienste vorschlagen und gegebenenfalls vervollständigen. Wenn deco apache <TAB> gedrückt wird könnte die Liste der Aktionen für den Apache gelistet werden.
Das ist allerdings richtig. Ich bin zwar der Ansicht, dass Bash-Completion nur eine 80% Loesung ist, da nicht das Programm selbst nach Moeglichkeiten gefragt wird (um so etwas umzusetzen ist Unix wohl nicht monolitisch genug), doch praktisch ist es ja dennoch.
hjb schrieb:
> Ganz klar, ich fände AKTION DIENST sinnvoller. Erstens ist es logischer, wenn die Argumente für den Dienst direkt hinter DIENST kommen (AKTION ist ein Argument von deco),
Moment mal! Die AKTION kann "start", "stop" etc. sein, was von dmd auf spezielle Weise gehandhabt werden muss, oder etwas vom Dienst frei Spezifizierbares, was dann eher ein Argument fuer den Dienst waere (und in der Tat waren das die Faelle, in denen mir intuitiv DIENST AKTION richtiger vorkam). Loesen liesse sich das rein logisch wohl durch "deco action apache reload-modules". Das ist aber umstaendlich und fuer Benutzer wohl kaum einsichtig.
> und zweitens kann man dann schreiben:
> alias start='deco start'
Schon, allerdings wird dann die Bash-Completion nicht mehr so gut funktionieren, wie Andreas anmerkte. Ich neige dazu, einem solchen Alias eine geringere Bedeutung zuzumessen, weil sich das gleiche auch relativ leicht auf andere Weise erreichen laesst.
Ok, ich bin mir wohl jetzt ueber das genaue Problem klar geworden, was schonmal ein wichtiger Schritt ist (beim letzten Problem benoetigte ich allein fuer diesen Schritt mehrere Monate!). Eine eindeutig ueberlegene Loesung sehe ich aber im Augenblick noch nicht.
Cheers,
GNU/Wolfgang
Andreas B. schieb:
> also ich würde soetwas wie "deco start apache" vorziehen, unter der Voraussetzung, dass deco, wenn es nur mit "deco" aufgerufen wird, eine Pseudoshell, ähnlich der Packetauswahl des Installers von Rocklinux(1) Serie 1.4, zur Verfügung stellt,
Wird implementiert. Wobei ich denke, dass man das selten brauchen wird, wenn es Runlevel und automatisches Aufloesen von Abhaengigkeiten gibt.
> in der dann ein "status" den Status aller Dienste anzeigt
, ein "deco status" würde es dann direkt auf der Shell ausgeben, wäre also der nicht Wiedereintrittsweg.Da habe ich zwei Einwaende gegen: Erstens waere das inkonsistent und wuerde die Struktur des Interface komplizierter machen, zweitens ist es auch nicht vollkommen logisch, denn fuer die Verwaltung der Dienste letztlich zustaendig ist der Daemon "dmd", daher sollte das Anzeigen des Status aller Dienste eine Aktion des Dienstes "dmd" sein (und ist es gegenwaertig auch), womit die Konsistenz gewahrt ist.
> ein DiensteGlobbing wäre auch noch eine feine Sache.
Welchen praktischen Nutzen haette das? Ist "deco restart tty*" wirklich so nuetzlich? Wenn mehrere Dienste zusammengehoeren, wuerde ich das eher anders loesen, etwa ueber eine Service-Group (was nicht wirklich ein eigenstaendiges Konzept ist, sondern nur ein normaler Dienst, der quasi alles an mehrere Dienste weiterreicht).
tut schrieb:
> Ich finde deco DIENST AKTION sinnvoller.
> Es gibt nicht soviele DIENSTe, aber man kann wie es aussieht sehr viele AKTIONen durchführen, die jeweil von dem DIENST abhängen.
> Hierarchisch gesehen würde also deco DIENST AKTION mehr Sinn machen: Von der Wurzel zu den Blättern (details).
Wie viele Dienste es gibt, haengt von der Installation ab. Auf meinem Debian 3.0 System hier gibt es fast 50 in /etc/init.d/ obwohl ich ein relativ minimalistisches System habe. Das sind wohl mehr Dienste als je ein Dienst Aktionen haben wird. Abgesehen davon, dass dies alleine ohnehin kein sehr ueberzeugendes Argument waere.
> bash completion würde bei deco <TAB> die Liste der möglichen Dienste vorschlagen und gegebenenfalls vervollständigen. Wenn deco apache <TAB> gedrückt wird könnte die Liste der Aktionen für den Apache gelistet werden.
Das ist allerdings richtig. Ich bin zwar der Ansicht, dass Bash-Completion nur eine 80% Loesung ist, da nicht das Programm selbst nach Moeglichkeiten gefragt wird (um so etwas umzusetzen ist Unix wohl nicht monolitisch genug), doch praktisch ist es ja dennoch.
hjb schrieb:
> Ganz klar, ich fände AKTION DIENST sinnvoller. Erstens ist es logischer, wenn die Argumente für den Dienst direkt hinter DIENST kommen (AKTION ist ein Argument von deco),
Moment mal! Die AKTION kann "start", "stop" etc. sein, was von dmd auf spezielle Weise gehandhabt werden muss, oder etwas vom Dienst frei Spezifizierbares, was dann eher ein Argument fuer den Dienst waere (und in der Tat waren das die Faelle, in denen mir intuitiv DIENST AKTION richtiger vorkam). Loesen liesse sich das rein logisch wohl durch "deco action apache reload-modules". Das ist aber umstaendlich und fuer Benutzer wohl kaum einsichtig.
> und zweitens kann man dann schreiben:
> alias start='deco start'
Schon, allerdings wird dann die Bash-Completion nicht mehr so gut funktionieren, wie Andreas anmerkte. Ich neige dazu, einem solchen Alias eine geringere Bedeutung zuzumessen, weil sich das gleiche auch relativ leicht auf andere Weise erreichen laesst.
Ok, ich bin mir wohl jetzt ueber das genaue Problem klar geworden, was schonmal ein wichtiger Schritt ist (beim letzten Problem benoetigte ich allein fuer diesen Schritt mehrere Monate!). Eine eindeutig ueberlegene Loesung sehe ich aber im Augenblick noch nicht.
Cheers,
GNU/Wolfgang