[systemd-devel] [PATCH] systemctl: Implement "info" and "doc" commands, similar to "man"

[Lennart Poettering]

On Thu, 31.05.12 10:44, Gergely Nagy (algernon at balabit.hu) wrote:

> > Similar to systemctl man, implement the info and doc commands. The
> > former will open the appropriate info page, the latter will open any
> > http (or https) documentation via xdg-open.
> 
> FWIW, that patch was only compile-tested, but it should work.
> 
> Nevertheless, I was thinking that 3 different commands to display docs
> might be a bit too much. Perhaps it could be condensed into a single
> "doc" command, with --info, --man and --http or similar flags to select
> what kind of documentation to display? (And by default, will prefer http
> over info over man)
> 
> I can probably cook that up in a lunch break or so, but would rather
> have other opinions before I do that, to see if it's worth the effort.

Yes, I definitely would like to have one command only for this. I
intended this to be "systemctl man" even though it admittedly might be a
bit misleading in that it also starts info pages. 

I am not convinced we should try doing this for http/https
though. Firstly, all terminal programs recognize these kinds of URLs, so
it's probably easier to just have people click on them, and have the
right thing happen? In contrast to man URLs everybody and every program
understands http/https URLs. Then, http/https works from any machine,
while man/info really tend to work only on the machine your service is
installed on (simply because info/man pages come with the respective
RPMs/DEBs). So I'd claim that man pages you actually want to read on the
host that you are inspecting while web sites you want to browse on the
client machine you are logging in from. Or in other words: if I log in
remotely I don't want to end up with lynx in the ssh window to read
documentation, and I'd be annoyed if that happens just because I tried
to find the man page for a service. Thirdly, the semantics of xdg-open
really are too losely defined: is it synchronous or is it async? We'd
want synchronous operation here (i.e. wait until the user closed the
documentation before we show the next page), but it tends to be async
(i.e. the script just tells the running firefox to open the new page and
immediately returns) -- and that for a reason: sync behaviour would be
kinda broken with modern browsers. Summary: I myself would be really
annoyed if "systemctl man" would try to open web sites, regardless if
locally on the client or remote on the SSH host. So I'd just skip
http/https handling in "systemctl man". People can just click on the
links in "systemctl status" and more likely the right thing happens.

I am happy to add info support to "systemctl man" though, as that this
really is the same thing mostly as man pages.

I'd be open to rename "systemctl man" to "systemctl doc" too, if people
want this, if we make it cover both man and info. Not sure I like "doc"
too much though. Maybe we can find another name? Suggestions? The reason
I picked "man" in the first place is that it is kinda an obvious choice
and man is much more ubiquititous than info.

And I don't think we need the additional --man or --info switches. I
doubt anybody would bother using that. After all this is a command that
will never be scripted, it exists only to make things easy for the user.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.