[systemd-devel] WISHLIST: systemd git-like CLI/ui/command interface

[Lennart Poettering]

On Thu, 22.11.12 13:45, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> >> When I see
> >> systemctl status ...
> >> systemd-journalctl
> 
> This is now just called "journalctl" since systemd v45
> 
> There is also "loginctl" (which used to be called "systemd-loginctl".
> 
> >> systemd-analyze ...
> 
> This is quite a specialist tool, not really used on a day-to-day basis
> by admins.
> 
> >> systemd-cgls
> 
> As is this.
> 
> >> it looks like a messy version of what git does (git ls, git add, git
> >> clone, etc).
> >> Git started that way too, and eventually brought sanity to the
> >> git-world with the top-level cli-ui as we have today.
> >>
> >> I suggest systemd ought do the same, preferably sooner rather than
> >> later (it is still early days for many distros, eg such as Debian
> >> which I am on).
> 
> I don't think this really applies here. The day-to-day commands are
> really systemctl, journalctl and loginctl (although the last one is
> likely not often used).
> 
> The other commands are really not often used which is very unlike git
> when I regularly use the different commands.
> 
> So I don't think this kind of wrapper command is really needed IMO.

Yes, I agree with Colin here. We currently have the following policy:

a) If the user never really calls it directly, it belongs in
/usr/lib/systemd/ and is prefixed with "systemd-", so that it appears
nicely in "ps" if it is running.

b) If it is a more exotic command but sometimes invoked by the user, and
required in early boot, it is prefixed with "systemd-", and stored in
$rootbindir.

c) If it is a more exotic command but sometimes invoked by the user, and
only need during runtime or late boot, it is prefixed with "systemd-",
and stored in $bindir.

d) If it a frequently used command, it is not prefixed with "systemd-"
and stored in $rootbindir. These commands are usually suffixed with
"ctl" or "adm".

So, in summary, we have three different places to store binaries in and
try to have a simpler naming scheme for the most frequently used
commands. This all is kinda incompatible with the "git" scheme of having
a single frontend command you invoke. (Well, or at least not obviously
compatible...)

I am not convinced that following the git scheme in this regard makes
sense...

(We get a lot of inspiration from git otherwise, such as autopaging, or
the date syntax for --until= and --from= in journalctl, but we should
only pick things where we are convinced that they make sense for us, and
not blindly copy the whole scheme...)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.