Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't know why, but three systems make me google the correct command line options every time I need to use them:

1. OpenSSL

2. Systemd

3. PGP

I have no idea why, but their command line interface is just somehow confusing.



I would argue that core systemd CLI interface is fairly compact and memorizeable (systemctl start-stop-restart, simple journalctl invocations). Some obscure directives still result in a trip to manpages though.

Openssl, PGP and (mentioned in the thread) ffmpeg are often run on one-off basis with changing inputs and outputs and thus almost always require searching the Internet for the correct flags.


so they're like prepared SQL statements in a sense?


IMHO bringing SQL in is a bit of a stretch; I believe prepared statements are generally strict about their n-arity. Key systemctl commands accept lists of units as subjects of the command.

If we were using the SQL analogy, I'd say stored procs were closer.


Systemd is a weird one, because I do feel like the user experience is fairly well managed, things makes sense when I read them and use them, yet next week, completely gone.

As someone else pointed out, perhaps it's not entirely fair to critic the OpenSSL commandline tool too much, it is in some sense a catch-all reference implementation. On the other hand, Curl have a million options as well, but seems really well put together. Maybe because you only really need a small subset of Curl most of the time, but the same is true for OpenSSL.


I realized why. Systemd splits journalctl and systemctl into two utilities. With journalctl having impenetrable command line options that put `tar` to shame.

If systemctl had something like `systemctl logs -f service`, it would have been much more welcome. Also something like `systemctl start --logs --follow service` would be great.

I'm going to file a ticket for them.


Huh. That's exactly my experience.

I suspect that its a combination of three things: first, they are not frequently used, second, their CLI is very complex, third, their design violates normal CLI conventions in weird ways.

I don't have the same problem with things like docker or git, which are arguably more complex.


Pro (Newbie) tip: use a GUI for git (like lazygit or VS Code Source Control). Git is one of the few complicated CLI tools that actually works well as a GUI, so take full advantage of it.


Very interesting! I was on another thread where the user stated that they preferred the git CLI to using a git GUI, because the GUI imposed another layer of conceptual complexity on top of an already complex tool.

May I ask what git GUI you use? lazygit?


I used IntelliJ and emacs' magit. I don't know what "extra layer of conceptual complexity" they're talking about, it's very straightfoward to me (admitedly, I knew the CLI well enough before I started using GUIs so maybe I had already internalized whatever concepts they're think about).


I use navi cheatsheets for that. You can store commands with descriptions and easily execute them. This is where I put all the "will need only once a year" commands.

What I do google is ffmpeg, but not before every online editor/converter on the internet completely betrays my expectations and makes me reconsider my life choices.

[0] https://github.com/denisidoro/navi


And FFmpeg. :)


4. Git


Git has entered the chat




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: