On Thu, 31.05.12 10:44, Gergely Nagy ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
