Hacker News Reader

Hacker News

Comment by nickysielicki | Hacker News Reader

Full thread

nickysielicki

This is maybe pedantic, but something that irks me about systemd is the way that systemctl commands are composed.

I find myself doing this frequently

> systemctl status someservice

> systemctl stop someservice

> systemctl edit someservice

> systemctl daemon-reload

> systemctl start someservice

> systemctl status someservice

> systemctl enable someservice

Why make the operation the middle parameter? I understand that "systemctl start foo" more closely resembles the English sentence, "SystemD, please start the foo service", but I couldn't give two shits about that, and it's a dumb design decision. Any time that I am entering a systemctl command, I'm probably entering a series of 3 or more of them, and they're probably all related to the same service.

Instead of being able to press <Up Arrow>, <C-Backspace>, and type my operation, I'm instead having to position my cursor to the second argument. It's a mess!

View on HN

So that it's easier to bring up/down a number of related service units with single actions.

Example: systemctl stop smbd nmbd ; systemctl start smbd nmbd

It isn't that the operation is the /middle/ parameter, it's that you have invocation action //LIST//

The point of OP's link is that the novelty of systemd is that you can compose chains of dependencies and how that saves time and effort.

So why should it be a common operation for the enduser to start and stop a list of related services? Instead of having to type and remember them individually, I should add a BindTo line in my service files and let systemd handle it. It's like the frontend for systemd is optimizing for a situation that it is supposed to prevent.

And anyway, there's no unixy reason the variadic argument couldn't be in the middle. cp, for example, has

    <command name> <options> <variadic list of files to copy> <single dir to copy to>

Because it's the pattern far more Unix tools use. Command name, then flags, then a file/set of files.

I felt exactly the opposite way when I used Debian (not for any justifiable reason other than "that's not the way it's supposed to beeeee") because Debian does it in the way you describe.

Theoretically, you could put on your hacker gloves and write a script that shifts the arguments for you. That might be a fun exercise!

It seems you are using bash and need to up your shell game, allow to suggest zsh which allow for thing such as:

!!:s/status/stop/

This will recall the last command and substitute status with stop.

!-2:s/status/edit/

Will recall two commands back from history and substitute status with edit.

See http://reasoniamhere.com/2014/01/11/outrageously-useful-tips...

For added awesomeness have a look into history-substring-search[1], zsh-autosuggestions[2], zsh-syntax-highlighting[3].

[1]: https://github.com/zsh-users/zsh-history-substring-search [2]: https://github.com/zsh-users/zsh-autosuggestions [3]: https://github.com/zsh-users/zsh-syntax-highlighting

By the way, are you aware of the keypresses that move the cursor by a word at a time? In particular, <M-Left Arrow> and <M-B> should each move backward by a word. You should be able to go <Up Arrow> <M-Left Arrow> <C-W> [type operation] <Space> <Return>. You might have to enable alt as meta key on an OS X terminal (which is obviously not the case here), or disable alt as referring to file menus on Linux (which may be the case here). Prefixing a command with ESC also works as a meta key, though I'd find it ergonomically intolerable.

Try doing ^status^stop for instance moving between the first and second command.

One-liner lists are handy:

    for service in <list> do; systemctl <action> <service>; done

E.g.,

    for system in foo bar baz; do systemctl stop $system; systemctl start $system; done

... will stop and start each of your named services.

(This clearly extends far beyond systemd.)

But it accepts a list, so rather than write the loop:

systemctl stop foo bar baz; systemctl start foo bar baz

With the caveat that yours and the version above are not the same. With properly written systemd units (e.g. using the notification API to signal when it's actually operational) the former will have fully started foo again before stopping bar (ignoring the lack of error handling in both examples..). Which may or may not matter.

True. It's just that in most cases when I write a loop like that it's to work around the fact that the restart command didn't take a list, not because I need to serialize the service restarts.

In Debian I use "service X action" which I also find preferable for the exact same reason you mention.

> Instead of being able to press <Up Arrow>, <C-Backspace>, and type my operation, I'm instead having to position my cursor to the second argument.

Maybe not as neatly, but you can do this in 5 blind keystrokes (instead of 3):

    Up; Alt-<b; b; Backspace>

Thanks for the tip, I didn't know about alt-<b>.

I should try using emacs for a month, if only for the sake of getting to know readline better.

It's not a big deal, since all modern shells have move commands (e.g. "shell-backward-word" in bash) that allow you to jump to the second-to-last argument with a simple key stroke.

What's the default keystroke for bash/dash?

https://www.gnu.org/software/bash/manual/html_node/Commands-...

same as emacs: alt+b

Ctrl-left/right (on comptible terminals) or Alt-b/f (or even Esc+b/f).

I use:

"systemctl stop foo" then "stop^start"

Which will substitute stop with start in the previous command (in bash, not sure about other shells)

That wouldn't really make sense at all.

Can you name any commands or interfaces that take the variable before the argument?

/etc/init.d/<variable> <command>

Those aren't variables though, you are referencing specific files.

How about egrep, then?

Depending on what you're looking for, grep may or may not.

    grep <pattern> <file>

Convenient when you're looking for <pattern> in a bunch of <file> (and for some reason cannot glob or list them). Less so if you're looking for a bunch of <pattern> in some one <file>.

I've been known to write one-liner shell functions to put the variable component of a list of commands at the end of the commandline for easy editing.

cp, rm, rsync, scp tar...

    cp [list of a great many items] [here]

or service

    service [item] [action]

whereas systemd is

    systemctl [action] [list of great many items]

There appears to be no hard and fast rule, though - argument ordering is different to flag ordering (-f -z etc). I never see anyone put flags at the end, though plenty of tools work fine that way.

My problem with systemctl is that it's so woeful to tab-complete. At 'syst[TAB]c[TAB]', you may as well just type out the whole thing, because tabbing only saves you two characters. Why not just take 'ctl', that doesn't seem to be taken by anyone?

GNU toolset:

    cp -t [here] [list of a great many items]

And there is one area outwith Unix but still at the command line where one does sometimes see people putting flags at the end (even though this is not the documented syntax):

    dir *.txt /s

Be wary of the service command, incidentally.

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

As for "ctl": Bear in mind that there are a lot of "ctl" commands. initctl (from upstart), netctl (from Arch), rcctl (from OpenBSD), pfctl (from OpenBSD), ip6addrctl (from FreeBSD), ntpctl (from OpenBSD), hastctl (from FreeBSD), swapctl (from 4BSD), rctl (from FreeBSD), pppctl (from FreeBSD), smartctl, journalctl, bootctl, localectl, busctl, coredumpctl, hostnamectl, machinectl, timedatectl, loginctl ...

Pick unadorned "ctl" for the systemd one, and one begs the question of why systemd alone is special enough not to require its name in the command.

The "-t" switch in "cp" exists to support the use with xargs, e.g.

  find /some/directory/ -name *.txt | xargs cp -t all-the-textfiles/

The systemctl interface has the same useful property:

  systemctl --failed | awk '/.service/{print$1}' | xargs systemctl restart

Tab completion has its limits. Using zsh and some added awesomeness from fish: sys<alt+f> and it completes to systemctl sys<ctrl+e> and it completes to the full last systemctl command I used

https://github.com/zsh-users/zsh-history-substring-search

https://github.com/zsh-users/zsh-autosuggestions

https://github.com/zsh-users/zsh-syntax-highlighting

Reply on news.ycombinator.com