[HN Gopher] Some terminal frustrations
___________________________________________________________________
Some terminal frustrations
Author : aragilar
Score : 231 points
Date : 2025-02-06 06:59 UTC (4 days ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| gregjor wrote:
| A good catalog of mostly skills issues.
|
| Many of the points raised point to real glitches, cruft, and
| frustrations with using the CLI. Those get more frustrating for
| people who only occasionally use the CLI, and less so for those
| of us who live in the shell.
|
| Many of the same kinds of problems exist in GUIs. I rarely use
| Windows so when I do I can't find or discover what I need.
|
| Over time you remember the commands and flags, write aliases, set
| up config files, and mostly it becomes second nature.
| Analemma_ wrote:
| This comment is a good distillation of my frustration with Unix
| ideologues. Unix and the CLI can never fail, they can only be
| failed; any possible unhappiness is a "skill issue"; it's
| _your_ job to memorize a thousand arcane and badly-systematized
| program names and flags, created in an era of RAM and disk
| space limitations which have no relevance today, etc. And going
| "many of the same problems exist in GUIs" is a "no u" tier of
| response.
| skydhash wrote:
| Do you expect to go inside a plane and fly it with no
| training? Or pick up a violin and play a sonata? The terminal
| have its flaws, but all other interactions models have their
| own. But when people don't try to learn the basic tenet and
| just ask why it can't be like
| $other_system_they've_learned_first, you bet that they're
| going to point you to the manual.
| fragmede wrote:
| I expect that pilots are allowed to have opinions about
| systems in the plane as being user unfriendly, like MCAS of
| 737 Max fame. I expect violinists to be allowed to complain
| when their bow is rosined wrong. Sure, we should expect
| users to at least read parts of the manual, but when
| billions of dollars have been spent so I can ask the
| computer to write me an ffmpeg invocation, haven't you got
| to ask to yourself that there's a chance we're making this
| unnecessary hard on ourselves for no reason?
| skydhash wrote:
| > _but when billions of dollars have been spent so I can
| ask the computer to write me an ffmpeg invocation_
|
| That was an unnecessary spend then. You should ask
| yourself why ffmpeg still exists if if it's that hard to
| use. There's a plethora of simpler tools that exists for
| simple uses (handbrake, XLD,...). The truth is that if
| you want versality, there's no better than ffmpeg and
| it's core usage is relatively simple. It's an input |
| filter | output pipeline, with various options to fine
| tune each one. If you don't have the domain knowledge, it
| will be hard, just like a layman inside a plane cockpit.
| But if you do, everything makes sense.
|
| Same with a lot of other software. There are bad design
| out there, but if something persists with no other
| incentive than its users, you should probably ask why
| first.
| eviks wrote:
| I expect a light switch button on a plane act like any
| other light switch button everywhere else - switching the
| light when pressed. The fact that the you can point to the
| terminal manual that states that you must use --- triple
| tap for that is irrelevant - that's still very bad design,
| and you've just dismissed a real issue with an bad analogy.
|
| > why it can't be like
|
| Here is another mistake: in many cases it be.
| follower wrote:
| > I expect a light switch button on a plane act like any
| other light switch button everywhere else
|
| Me too, which was why I was very surprised when I
| discovered light switches in the USA worked _backwards_
| [0]. :D
|
| (When I initially read your comment I didn't notice the
| use of "button" by which I guess you're referring to a
| push-button toggle style switch? But either way I still
| think light switches are an interesting example of non-
| obvious things that don't work the same way in all
| environments. (Even ignoring the "one light controlled by
| multiple switches" situation.))
|
| ----
|
| [0]
| https://en.wikipedia.org/wiki/Light_switch#Orientation
| eviks wrote:
| Yes, I was aware of the toggle switch ambiguity when
| describing a button... (not a perfect analogy anyway)
| gregjor wrote:
| Unix and the CLI tools represent a huge part of the
| foundation so much newer software sits on. No one can just
| change the commands and flags to make them less "arcane" or
| more "systematized" without breaking millions of lines of
| scripts and tools and workflows.
|
| Anyone can make their own tools if they have a better idea,
| and sometimes those take off and get adopted -- look at vim
| and now Neovim, rg (ripgrep), even Python pushing Perl and
| bash scripts out of the way. And plenty of people will call
| those things arcane too.
|
| If you manage servers you know that RAM and disk space and
| other limitations have lots of relevance today. I'll quote
| you the next time my boss or customer asks me to explain a
| huge AWS bill.
|
| If you don't like Unix or CLI tools, or don't want to spend
| the (admittedly signficant) effort to master them, no one
| will force you. I think the effort pays off. I have dodged
| more than one round of layoffs because I can work from the
| command line and keep legacy scripts and code working.
|
| Dismiss or make fun of us "Unix ideologues" if you want, but
| I don't worry about losing my job or customers like my
| friends who have "mastered" VSCode pasting in LLM-generated
| snippets of React.
| eviks wrote:
| You also forget commands and flags over time, leading to the
| responses you denigrated as a skill issue. And this is not from
| a "rarely use" crowd like in your Windows example
| gregjor wrote:
| Sure. That's why --help and man and info exist, along with
| the volumes of online and printed documentation. The
| Unix/Linux shell and command line tools have to rank near the
| top of most-documented software in use.
|
| When I wrote "skills issue" I had in mind the mentality that
| equates learning the standard tools, mastering the
| environment, and always improving skills with a waste of
| time, a few minutes or hours diverted from pasting together
| API calls or prompting an LLM. I have watched programmers
| spend _hours_ setting up color schemes and fonts in their
| IDE, and then complain that they can 't remember a flag for
| grep.
|
| Years ago I worked at a software company where everyone used
| the Eclipse IDE. I tried it but it felt too slow and buggy,
| so I fell back to my usual vim in the terminal. Every week or
| so the team came to a halt when Eclipse got an update to the
| Subversion SCM plugin (this happened before git took over).
| Eclipse would have a version of Subversion incompatible with
| the version on the servers, causing the team to stop to deal
| with that. I used svn from the command line, same version as
| the server, so I could keep working. Eclipse broke down so
| often I couldn't understand the team-wide devotion to it. And
| they made fun of my "arcane" and obsolete workflow. Now I
| work with teams who use VSCode and I see the same kind of
| thing play out -- plugin updates that break the whole
| environment, weird problems from the bowels of npm that no
| one can figure out. And they tell me they don't have time to
| learn vim.
| follower wrote:
| > A good catalog of mostly skills issues.
|
| Seems a bit harsh to call out the developers of all that
| software like that.
|
| But I do agree that software interface design and empathy are
| both skills that many software developers might benefit from
| developing further.
|
| In their defence, developers unfortunately often don't seem to
| have access to many resources for upskilling themselves in
| these areas either--people don't seem to realise that simply
| telling someone to, say, just "git gud" at empathy is actually
| a form of gate-keeping that doesn't really benefit anyone.
|
| Admittedly, if I was feeling snarky I might be tempted to say
| being able to create software interfaces that may take a person
| from four to twenty-one or more years[0] to learn could be
| considered a "skill" of sorts, I guess, but that wouldn't be
| very empathetic of me.
|
| ----
|
| [0] "40% of people answering this survey have been using the
| terminal for 21+ years / 95% of people answering the survey
| have been using the terminal for at least 4 years"
| gregjor wrote:
| I meant that people who struggle to use basic CLI tools have
| a skills issue. The tools date from decades ago, got embedded
| in millions of scripts and workflows, and so their UI won't
| change. Like it or not we have to accept those tools have
| become part of the background, so complaining about grep or
| awk or bash just goes nowhere.
|
| The people who wrote the shells and tools like vi(m) and awk
| didn't suffer from skills issues or lack of empathy. They
| wrote tools for themselves and other skilled programmers, in
| environments that no one under 50 can remember or imagine.
| Monochrome 80x24 displays, 8 MB of RAM, floppy disks (or
| worse) -- major hardware and software constraints. Blaming
| them for not anticipating modern hardware and software (and
| attention spans) seems like blaming Henry Ford for not
| inventing the electric Mustang.
| follower wrote:
| > I meant that people who struggle to use basic CLI tools
| have a skills issue.
|
| I very much understood that's what you meant.
|
| (And assumed you meant "skills issue" in the dismissive
| sense--if you _didn 't_, ummm, feel free to skip to the
| last line of this comment, I guess...)
|
| My comment was written in a manner to "humorously" imply I
| misinterpreted your comment as criticising presumably much
| older individuals rather than the actual intended targets
| of the criticism. This was in an attempt to prompt a
| possible reconsideration of the statement.
|
| Seeing as I obviously failed in my attempt, let me restate
| my point less delicately but more clearly:
|
| Unlike the tools from decades ago that can be & often are
| useful today--in spite of their less than perfect
| interfaces; attitudes that lead to shallow criticisms of
| people's skills _are_ outdated, should be deprecated &
| removed from use--because such gate-keeping serves no
| useful purpose. In fact, it never did.
|
| ----
|
| I mention this because I happen to care about our shared
| hobby/industry and those who have chosen to be part of it--
| because the technology is really fucking fun and/or
| fulfilling and/or frustrating.
|
| And if the technology can be really fun why _wouldn 't_ I
| want as many people who are interested in it to have some
| of that fun? Or, heck, earn a living with making it less
| frustrating?
|
| Humans are often already _fantastic_ at self-critique of
| their skills--they don 't need other people to shit on
| their skills too. (And I'm intentionally writing all this
| in case some of those humans are "in the room with us
| now".)
|
| ----
|
| Besides, these survey respondents were primarily people who
| have stuck it out with our imperfect technologies for at
| least four to _twenty_ or more years.
|
| Not only were they prepared to _admit_ that they didn 't
| know something (something _I_ personally find challenging
| to do, at times _*cough*_ ) they were _kind_ enough to do
| so in the context of a survey that would help Julia Evans
| create an effective targeted resource to help people
| _learn_ the very skills that are apparently of such
| importance!
|
| ----
|
| I would also note, for example, one might consider it
| reasonable if only ~7-10% of people might know to use `cmd1
| |& cmd2` for redirection of both stdout & stderr given it
| has apparently only existed since Bash v5.0, a mere six
| short years ago--and, _coincidentally_ , probably one of my
| favourite Bash tips I've learned in the past five years
| because I could never seem to remember which order the
| `2>&1` went in--and seems maybe I wasn't the only one?
|
| Why, if I was feeling petty, I might even point out that
| the existence of `|&` might even suggest that decades-old
| tools _can_ in fact change their UI and that even
| complaining about _bash_ might _not_ just go nowhere.
|
| Why, if I was feeling optimistic, I might even imagine that
| maybe _attitudes_ can change!
|
| ----
|
| On a _definitely_ related & probably incredibly
| condescending sounding note:
|
| What's a useful CLI tool tip you'd suggest would be
| valuable for people to know?
| spudlyo wrote:
| > A good catalog of mostly skills issues.
|
| It's a good reminder to some of us that we are not in fact
| imposters.
| atoav wrote:
| If I could change two things about terminals it was thesd:
| 1. Make text editable with a cursor and mouse selection like in
| any other modern text application 2. Make use of the
| normal and expected text shortcuts for copy, cut, paste, select
| all etc. Make ESC *escape* the current program.
|
| And I am a heavy terminal user who has no issues with how it
| currently is, but I also have to teach these things...
|
| I am aware that such a change would probably be 1000 times more
| complex to pull off than most people would think, but every time
| I have to explain to beginners they can't edit the text I die a
| little inside.
| skydhash wrote:
| The use of a terminal is to communicate with an application
| (the shell mostly, and other REPL software). The text shown is
| a log of that interaction, not the interaction itself. We could
| probably design a better interaction model (smalltalk, plan9)
| but the current one is the most simple.
| atoav wrote:
| I understand that. But there is _no reason_ (other than
| legacy cruft) why I shouldn 't be able to fix a typo mid-
| command with arrow keys instead of backspace before sending
| that command as a default.
|
| I am perfectly fine with having sent commands uneditable and
| responses uneditable as well.
| scbrg wrote:
| You... can? Perhaps I misunderstand you, but doesn't
| readline solve this problem?
| fragmede wrote:
| The frustrating thing is that the code for mouse move/selection
| already exists, but it's a total rathole to get it working, and
| I don't have the whatever to be a whatever maintainer across
| everywhere.
| ninkendo wrote:
| macOS's terminal app does #1 but you have to option-click. It's
| kind of a hack too, it just issues a bunch of right/left arrow
| key codes to the shell to move your cursor to the designated
| spot.
|
| Your second point is definitely my #1 issue, at least it is on
| Linux and Windows (macOS at least uses Cmd-c everywhere and it
| works.) I have to constantly remember to use ctrl-shift-c to
| copy in the terminal but ctrl-c to copy everywhere else, and I
| constantly forget and use ctrl-shift-c in a not-terminal
| program, and do something stupid like open dev tools in chrome,
| ugh. This is, unfortunately, not fixable. Not without rewriting
| every app on my system to use a different copy/paste combo.
| eviks wrote:
| Wait, what do you mean not fixable when you can just change
| the keybind in the terminal app to use ctrl-c to copy?
| ninkendo wrote:
| Ctrl-C is SIGINT, I don't want to change its definition of
| sigint just to make room for copy behavior.
|
| What I want is to make a different shortcut trigger
| copy/paste, everywhere, and _that's_ not fixable. Every app
| independently decides to make ctrl-c implement copy, so
| changing that is basically not possible.
| eviks wrote:
| You don't need to change the definition of sigint, just
| its shortcut!
|
| Though it's also possible to fix it everywhere - use a
| keyboard rebinding tool to make Ctrl-Shift-C send Ctrl-C
| key combo instead
| ninkendo wrote:
| > You don't need to change the definition of sigint, just
| its shortcut!
|
| That's what I mean? Changing sigint's shortcut isn't what
| I want to do.
|
| > Ctrl-Shift-C send Ctrl-C key combo instead
|
| Then ctrl-shift-C will send SIGINT too, and I'm back to
| where I started (SIGINT and copy having the same
| shortcut)
| eviks wrote:
| > That's what I mean?
|
| I'm sorry, I thought there might've been some confusion
| re. actual sigint definition based on some deeper history
| and ASCII codes (which didn't seem like it from cursory
| search)
|
| > ctrl-shift-C will send SIGINT
|
| You filter against your terminal app, where Ctrl+Shift+C
| will continue send Ctrl+Shift+C
| p0w3n3d wrote:
| Agree, MacOS terminal has this distinction between Control
| which is purely terminal modifier, and Command which is
| purely Mac modifier, hence when I work in terminal on MacOS I
| do CMD+C - CMD+V and this is consistent with all the other
| apps, while on Linux you have to either think of CTRL+C as a
| copy or as a SIGINT, depends on which app you are using.
|
| This was so good experience for me, that I reconfigured my
| Linux terminal to have Win+C, Win+V and Win+T (for new tab).
| However this is inconsistent with Linux window management.
| Since then I have been actively looking for a way to change
| the Linux OS manager to have default global hotkeys in the
| MacOS style. Anybody knows how to do that? (
| https://news.ycombinator.com/item?id=41439601 - suggested
| xmodmap is a key mapping way which will break my CTRL+C in
| terminal )
| p0w3n3d wrote:
| while writing this I found
| https://github.com/rbreaves/kinto - I need to give it a try
| as this (hopefully) is not simple overlay for xmodmap...
| mixmastamyk wrote:
| You can edit text, at the prompt. Afterwards output is readonly
| and copyable. Doesn't make much sense another way.
| atoav wrote:
| Yeah? Like in a normal text editor?
|
| Please write: echo "12345789"
|
| and insert the missing number without deleting the already
| existing numbers in a vanilla (non-emacs, non-vim) terminal.
| In nearly every other editable text field people know well in
| their lived (including the one you typed in for this comment)
| you can move your cursor to the middle of a sentence and
| insert text with a mouse click or the left/right arrow key.
|
| And before someone suggest some option to enable this: my
| comment was about changing the _defaults_.
| drcursor wrote:
| just use fc (fix command)
| skydhash wrote:
| The terminal model is just to display the text that the
| currently running software provides and send input to it.
| It's not a text editor. The prompt is a feature of the
| shell and other REPL programs, not the terminal. Bash and
| Zsh and others use readline which allows text editing like
| navigation [0]. And there's rlwrap for programs that lack
| these.
|
| [0]: https://readline.kablamo.org/emacs.html
| wpm wrote:
| Press left arrow four time and type "6".
| joh6nn wrote:
| Using the arrow keys to navigate the current input is well
| supported on most modern terminals, and has been for most
| of my adult life. If this isn't working properly in your
| terminal, then I'd recommend experimenting with the various
| settings available to you.
|
| Some terminals also support mouse navigation, so keep an
| eye out for that as well.
|
| I'm sorry that you've been dealing with this frustration
| for so long and under the impression that it was just
| supposed to be that way and not fixable. The good news is
| that it's NOT supposed to be that frustrating and you CAN
| fix it
|
| Edit: you edited your comment somewhere between my first
| seeing it and my reply posting. I haven't had to modify the
| default settings on my terminal to fix things like this in
| about 20 years. I've changed them to tweak various
| preferences like scrollback, cursor shape/size, etc. But
| arrow navigation has worked out of the box for me for so
| long that I literally can't remember when I last had to fix
| it. I don't know why our experiences have been so
| different, but I'm sorry that a tool that has been so
| useful for me has been so frustrating for you.
| crabbone wrote:
| I see this in situations when terminal relies on
| readline() to do this stuff, but that isn't installed.
| toast0 wrote:
| I've not had luck with selecting a position with my mouse
| in a terminal shell, but arrow keys is rarely a problem.
|
| Old enough terminal or old enough host, sure, there can be
| some fighting involved. Of course, working in those
| conditions, sometimes backspace doesn't work either and you
| have to hit ctrl-H like an animal.
|
| But I haven't had issues with that lately.
| mixmastamyk wrote:
| No option is needed, it's worked this way since the 90s at
| least. Mouse is not commonly enabled but would be
| inefficient to use as hands are already on the keyboard. I
| haven't missed it, but it could be set up with a script,
| no?
|
| If arrow keys not working for you, install a new distro.
| xboxnolifes wrote:
| You can do this in the default windows Terminal. Which is
| also how I interface with WSL, so it's also my Linux
| terminal.
| Ferret7446 wrote:
| You can already do this, in Emacs and possibly other terminals.
| It is pretty easy to implement. The problem is that this can
| also cause other problems, especially for newbies, because
| editing the text may not do what you think it will do (e.g.,
| editing the output of ls or editing a command after you started
| running it).
| atoav wrote:
| Those are two instances of text that should not be editable.
| crabbone wrote:
| 1. I probably don't care. On the list of things I want from a
| shell (what you are asking for isn't a function of the
| terminal, but of the program running in it) this is so low, I
| would never cared if it was added. I never wanted it to work
| like this, but as long as it doesn't actively get in the way,
| I'm OK with it.
|
| 2. What's "normal"? Do you mean CUA-style navigation? In that
| case, absolutely, no effing way! These keybindings are awful.
| And it's good that they are awful. It wouldn't be a good idea
| to often accidentally press C-c and kill whatever thing you are
| working with. But, it's not a convenient key chord for an
| operation as common as "copy". Now, you may say "in addition to
| already existing text editing key bindings": but then, again,
| no, because I want these keys for rare and dangerous
| operations. I don't want them to be duplicates of existing and
| better functionality.
|
| NB. Both of your improvements aren't about terminals. They are
| about programs run by terminals (eg. shells). But you probably
| knew that already. I realize that OP and the comments lump all
| these tools together under the same label. But it's still worth
| pointing out that these are separate issues at least in the
| sense that nothing you can do to the terminal will effect the
| change you want to see.
| rcarmo wrote:
| Previously:
|
| https://news.ycombinator.com/item?id=42970632
|
| https://news.ycombinator.com/item?id=42975816
|
| https://news.ycombinator.com/item?id=42959824
|
| https://news.ycombinator.com/item?id=42953869
| tonymet wrote:
| Is this a bot?
| fragmede wrote:
| does it matter if it is?
| wutwutwat wrote:
| It matters to the person above, which would be why they
| asked the question.
|
| That's generally how question asking goes...
| tonymet wrote:
| Isn't this the forum for the technically curious? So yes,
| it matters.
| fragmede wrote:
| and I'm curious on the technical details for why it
| matters for you.
|
| if it's, say, a chrome extension someone whipped up that
| makes it a button click to generate, or a script someone
| handcrafted, or somone had an LLM generate, or a fully
| automated bot doing it off a Cron job, or a billionaire
| is paying a human in the Philippines to do it by hand,
| some SV startup millionaire is bored with life and spends
| too much time here, a college student that has some free
| time between classes... the end result is a relatively
| simple post linking back to previous threads.
|
| in what manner does having a human in the loop for that
| specific post affect your broader feelings about this
| site?
| tonymet wrote:
| I'm merely curious.
| rcarmo wrote:
| Nope. Just someone who also submitted this earlier as well. I
| think HN's dupe detection is off these days.
| asicsp wrote:
| I think the dupe detection works only if there had been
| substantial discussion before, which none of the previous
| three had in this case.
| slightwinder wrote:
| Detector seems a bit off when it also includes the item-id
| where it's posting.
| tonymet wrote:
| I encourage users to log context switches and then find tools to
| address the context switch. Try to stay in your terminal whenever
| possible .
|
| For documentation context switches (e.g. stackexchange/googling)
| : install tldr, fabric , devdocs, sdk docs etc . And get
| comfortable searching man pages with "/" and man -K
|
| For job/task context switching (e.g. running multiple jobs like a
| transfer job and a measure-status job), get familiar with bash
| job control or tmux
|
| For history context switching (e.g. re-running an old command) ,
| set a long history like HISTFILESIZE=100000 and use ctrl-r. If
| you ever run out of history, make it bigger . Also dump helpful
| commands into a README.md with echo COMMAND ARG1 ARG2... >>
| README.md . Fzf is also helpful.
|
| For context-switches stemming from missing settings / dot files,
| set up "dotfiles bare git repo". You can push this repo around
| with SSH, so every fresh machine will have your settings on first
| login.
|
| The challenges in her survey are common, and I wish shells did
| better user onboarding and tutorials, the way games and consumer
| apps do. But each one can be addressed with the right
| preparation.
| staindk wrote:
| Some good points made in the article.
|
| If you use the terminal for any appreciable amount of time I
| heavily suggest getting fzf (even if just for the search).
|
| Tmux is great if you need any more than 1 terminal window open at
| once - just remap some of its hotkeys to stuff that make more
| sense for you (e.g. I use "Alt + |" to split vertically and "Alt
| + -" (minus) to split horizontally).
|
| Man pages are generally about 500 times longer than I need them
| to be (just help me do a basic curl/SSH copy/... please) - so I
| have cheat.sh aliased which helps a lot with simple "how do I use
| X".
|
| Aliases in general are insanely useful. If you're a fzf search
| whiz they may not help you as much but seeing people type common
| commands out multiple times a day... makes me happy knowing I
| have my alias bank.
| susam wrote:
| > Tmux is great if you need any more than 1 terminal window
| open at once - just remap some of its hotkeys to stuff that
| make more sense for you (e.g. I use "Alt + |" to split
| vertically and "Alt + -" (minus) to split horizontally).
|
| Nice tip! While I don't mind the default Tmux keybindings
| (<prefix> " and prefix % for horizontal and vertical splits),
| one thing that used to annoy me early on was how new panes
| would default to the directory where Tmux was originally
| launched, rather than inheriting the current working directory.
| Fortunately it was easy to fix with a few lines of code in
| ~/.tmux.conf: bind '"' split-window -c
| "#{pane_current_path}" bind % split-window -h -c
| "#{pane_current_path}" bind c new-window -c
| "#{pane_current_path}"
|
| This ensures that while splitting a pane with <prefix> " or
| <prefix> %, or while creating a new window with <prefix> c, the
| new shell inherits the working directory of the previous pane.
| This small tweak saved me countless unnecessary "cd" commands.
| kristopolous wrote:
| second this. huge game changer. should be default.
| lloeki wrote:
| > one thing that used to annoy me early on was how new panes
| would default to the directory where Tmux was originally
| launched
|
| Not just current dir, but the whole env:
| export SECRET=oops # could be silent if you use e.g direnv
| tmux # first one => start daemon
|
| Then another unrelated terminal: tmux
| env | grep SECRET # oops
| hiAndrewQuinn wrote:
| `fzf` is so universally useful I just recommend it by default
| to everyone I work with now who touches a terminal. The new
| fuzzy finding shortcuts it creates for shell history and
| switching directories alone makes it worth it, even if you
| never call `fzf` itself, as I recorded back in my tutorial eons
| ago. [1]
|
| [1]: https://andrew-quinn.me/fzf
| kalaksi wrote:
| I can relate to many of the frustrations. As years have passed,
| I've been trying to lessen the (repetitive) effort required for
| basic monitoring and maintenance over plain SSH. I felt that just
| the shell wasn't good enough, and large software stacks just
| increase maintenance burden.
|
| Ended up creating a GUI app called Lightkeeper
| (https://github.com/kalaksi/lightkeeper). Works over SSH,
| requires no daemons and is configurable. Still working on some
| unfinished features.
| UltraSane wrote:
| "Most of the legacy cruft, it would be great to have a green
| field implementation of the CLI interface."
|
| This is very true.
| tonymet wrote:
| Check out powershell
| UltraSane wrote:
| I've actually written many thousands of lines of Powershell
| for work and play. I first learned it because Vsphere used it
| for a CLI but I soon learned to love piping objects and
| filtering by property name. beat the hell out of bash that is
| for sure. And the ConvertTo-JSON command is amazingly useful.
| quotemstr wrote:
| Yeah. I also like the PowerShell model of cleanly
| separating the shell logic itself from various "shell
| hosts" (of which powershell.exe is just one). The Unix
| equivalent is the PTY interface, which is too low-level to
| be optimal.
| tonymet wrote:
| it deserves more advocacy
| crabbone wrote:
| It's so bad that I'd actually take the decades of cruft over
| it.
|
| It was made by people who don't know how to use existing
| tools and what the actual problems are. It's like people who
| keep creating "new" text editors, but they never learned well
| how to use existing ones. So they end up with crippled half-
| baked thing that's some concept from the 80s that was
| discovered to be a dead-end in the 90s, but with modern
| cosmetics.
|
| PowerShell is just incompetence and hubris of people working
| for a large company which can push their random garbage
| software on a lot of users and developers due to having huge
| market presence.
| ykonstant wrote:
| What are your specific criticisms of PowerShell?
| stackedinserter wrote:
| Not the OP, but everything requires tons of case
| sensitive typing. It's easier to just write python script
| instead of typing this
|
| (curl http://localhost:5555/log | grep -o -E
| "2025[0-9-]+") (Invoke-WebRequest -Uri
| "http://localhost:5555/log" -UseBasicParsing).Content |
| Select-String -Pattern "2025[0-9-]+" -AllMatches |
| ForEach-Object { $_.Matches.Value }
|
| or this (ps ax | grep ffmpeg) Get-
| Process | Where-Object { $_.ProcessName -match "ffmpeg" }
|
| Maybe it's good for scripting (why not python then?) but
| really sucks when you need to get things done in
| terminal.
| tonymet wrote:
| I agree. I use SetAlias ss Select-String or gm / Get-
| Member but you're right the language is too verbose.
|
| Auto complete is quite good though.
| zokier wrote:
| PowerShell is mostly case insensitive, `get-process`
| works as well as `Get-Process` or `GET-PROCESS`
| tolciho wrote:
| `ps ax | grep ffmpeg` sometimes will match grep itself,
| so either prevent the match from matching itself, or
| maybe instead use pgrep(1). $ ps ax |
| grep ffmpeg 66898 pe S+p 0:00.01 grep ffmpeg
| $ ps ax | grep '[f]fmpeg' $ pgrep ffmpeg $
|
| As for PowerShell, it does not seem useful, but then
| again I live mostly on OpenBSD and in the terminal.
| UltraSane wrote:
| Powershell has very good tab completion. It isn't a
| problem. And it is case insensitive.
| diflartle wrote:
| > or this (ps ax | grep ffmpeg) > > Get-Process | Where-
| Object { $_.ProcessName -match "ffmpeg" }
|
| The way to write that on the command line Powershell
| would be: ps ffmpeg
|
| Whereas your longer example is what you put in the PS1
| file.
| Reasoning wrote:
| curl and ps are both aliases in powershell for their
| respective posh equivalents. For some reason grep isn't
| though, I'll give you that.
|
| It also has positional parameters meaning you don't have
| to specify parameter names, though you might as well
| because tab completion is a thing. And if you're really
| keen on not using tab completion, it autocompletes
| parameter names for you meaning "get-help man -e" is
| equivalent to "get-help man -examples".
|
| Here are less verbose posh commands for your examples.
| (curl http://localhost:555/log -useb | select content |
| sls "2025[0-9-]+" -a).select.matches
|
| Still arguably a mess. Select-string not having a -o
| equivalent parameter is a big gripe of mine.
| (gps ffmpeg) or (ps ffmpeg)
|
| Get-Process has a name parameter. Why not use it?
| crabbone wrote:
| The criticism of Unix shell coming from the authors of
| PowerShell and those who like it says something to the
| effect:
|
| We want modern (and by that they mean C#-like)
| programming language in shell. We want user types, type
| checking, structured, modular code.
|
| And they forget that the reason Unix shell is _easy_ in
| some respects is precisely because it has none of that.
| Since everything is text, serialization is trivial. But
| serialization is vital if you need to work remotely
| between different shells.
|
| Structure will require a lot more operations for
| composing and decomposing it in order to transmit
| messages. Equality and identity become a problem.
|
| Custom types are similar to structure, but on top of it
| present a problem with serialization (somehow both shells
| need to have same type definitions, and what happens if
| they inevitably don't).
|
| The problems above not being addressed... what you get is
| another "scripting" language, of which there are already
| dozens, with no special benefits when it comes to it
| being used as shell, but with some problems. Just not
| worth it and illustrates lack of research and
| understanding of the problem space on the part of the
| authors.
| UltraSane wrote:
| " Since everything is text, serialization is trivial. But
| serialization is vital if you need to work remotely
| between different shells."
|
| Serialization is trivial in PowerShell but also much more
| powerful because you can pipe the output of any command
| to ConvertTo-JSON or ConvertTo-CliXML which gives you
| very nice STRUCTURED serialization that is much easier to
| consume.
| UltraSane wrote:
| This is the single worst take I have ever read on
| Hackernews. You didn't actually give a single concrete
| reason why PowerShell is bad. I will give a major reason
| why it is AWESOME:
|
| objects are piped instead of text. This single change makes
| a ridiculously huge improvement. You are no longer forced
| to perform incredibly tedious and fragile text
| manipulation. This also enables filtering on property names
| and the ConvertTo-JSON command which is amazingly useful.
| notsomeuser wrote:
| Yet there is one and its reference shell (2022) (
| https://www.youtube.com/watch?v=39ob0IO2Za0 ) is .. interesting
|
| https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
| Ferret7446 wrote:
| This is Chesterton's Fence.
|
| The problem with any terminal replacement is that you have to
| support all existing terminal applications. If you don't, then
| your replacement is going to be useless for half a century
| until everything gets re-implemented and installed everywhere
| (and this is assuming you can get buy-in from everyone on this
| speculative 50 year investment). If you do, then
| congratulations, you have all of the legacy terminal baggage.
| wpm wrote:
| I couldn't disagree more.
| GoblinSlayer wrote:
| TempleOS
| oliviergg wrote:
| Atuin.sh solved all my problems with history: history by project
| : check, history by session :check, global history: check. And if
| you want you can share history between computers. I just have to
| enter 2-4 letters and I can found complex command to rerun or to
| reuse as example.
| hoyd wrote:
| Same
| laktak wrote:
| I find the history much too unorganized to be useful. That's
| why I made playbooks https://github.com/laktak/tome
|
| ymmv but I prefer this to searching.
| pridkett wrote:
| Prior to using Atuin, I had some fun fish plugins that used fzf
| to search my history. I still find that I use that most often
| (it even searches my atuin history too), but when that fails -
| or becomes overly complicated, that's where atuin's native
| search comes in. It really is a game changer for working on the
| console and I can't recommend it enough. Here's some of the
| things that are really great about it:
|
| 1. As mentioned above, scope awareness when searching history.
| This can be exceptionally helpful when you know you're in the
| same directory where you previously ran a command.
|
| 2. Sync - this is why I started with atuin. It's pretty easy to
| run your own sync server if you're not big on send your
| commands to some random server somewhere.
|
| 3. Persistence - similar to sync, I love having my whole
| command history available when I stand up a new machine.
|
| 4. Secrets hidden - you can even set it so secrets are not
| persisted in your history. This is useful if you haven't yet
| migrated to using something 1Password to inject secrets. Also,
| as a side, it makes it really easy to find secret references
| you've used before too.
| ellieh wrote:
| (hey! atuin maintainer here!)
|
| Thank you for the kind words! Glad you find Atuin useful!
|
| > It's pretty easy to run your own sync server if you're not
| big on send your commands to some random server somewhere.
|
| We always intended to keep it easy to run a sync server! But
| also fwiw, sync is e2e encrypted, so we can't actually see
| anyone's commands
| terminaltrove wrote:
| > discoverability (55) There were lots of comments about this,
| which all came down to the same basic complaint - it's hard to
| discover useful tools or features! This comment kind of summed it
| all up:
|
| > How difficult it is to learn independently. Most of what I know
| is an assorted collection of stuff I've been told by random
| people over the years.
|
| This is all too true, the discoverability aspect is one of the
| reasons why we exist (0), and there is lots to improve here for
| discovering terminal tools, how to install and use them.
|
| Also thanks for running this survey Julia.
|
| Also, let us know on what we can improve on the site if you find
| Terminal Trove useful for you.
|
| (0) https://terminaltrove.com/
| armanckeser wrote:
| Cool site! Personally, I think the weekly highlight is nice and
| all, but the value of an aggregator comes from categorization
| and searching, and I didn't see either on the site. I would
| love to see it's focus to be like selfh.st
| terminaltrove wrote:
| Thanks for the feedback,
|
| We have categorization here:
|
| https://terminaltrove.com/categories/
|
| Is there anything we can improve here that can make this
| easier for you?
|
| We will consider searching on the website, what would you
| search by or search for if this feature existed?
| elashri wrote:
| > Is there anything we can improve here that can make this
| easier for you?
|
| No OP but it would be nice to include link to categories in
| the header bar. It would make it easier. the dynamic
| animation of the categorizes at the middle of the page is
| annoying. You have it in very small font in the footer but
| this isn't the best.
| armanckeser wrote:
| Ah , missed the link on grayscale. In any case, I think a
| datatable is a must in an aggregator. I would get a lot
| more value out of being able to filter and sort based on
| the language, categories, github stars, etc.
| zxexz wrote:
| I checked out your site (excellent content and very, VERY
| useful), and I came back comment with what I think is similar
| feedback that other commenters have.
|
| I would suggest a few things -
|
| 1. Less resource intensive site - I'm on my phone, and it took
| probably 5 seconds to load the front page, and then to actually
| get to the list, it took a few seconds more. I do not have a
| current gen phone, but I'd hazard a guess that my phone is
| about average in age as far as the potential user-base for this
| site goes! Do not discount mobile users, especially for a site
| focusing on CLI applications.
|
| 2. Maybe I care what language a CLI utility is written in
| sometimes (Albeit, I can't recall a time when I have). I'd add
| a search in the front page, if well thought out. Or, honestly,
| I'd just have the front page be the list. People are great at
| lists, and generally quite good at reading, and your list has
| very well-written descriptions.
|
| 3. Kinda related to the above, but I think the categories view
| is effectively useless. The categories already appear in the
| description (and if they don't, they probably should) - so why
| not just skip straight to the list? You could add a filter for
| the list if you want. Or, even better - a simple search box!
|
| I'm only giving these criticisms as a means to (subjectively)
| improve your site, because overall I think it is very well done
| and thoughtful, without a lot of fluff. There are hundreds more
| I'd not have criticized, but only because they felt like a
| waste of time and dead weight. Keep up the good work!
| quotemstr wrote:
| Part of the problem with colors is the recent trend of ignoring
| terminfo and TERM in favor of hard-coding escape sequences.
| Guilty packages include:
|
| * ipython/prompt_toolkit (https://github.com/prompt-
| toolkit/python-prompt-toolkit),
|
| * chalk (https://github.com/chalk/chalk),
|
| * linenose (https://github.com/antirez/linenoise), and
|
| * plenty of other random programs.
|
| Please, let's just stop doing things this way. I understand that
| talking to libterminfo is annoying, but it produces a better
| result for everyone than everyone maintaining obsolete and
| incomplete databases mapping TERM values to capabilities.
|
| That's not to say libterminfo is great either: we got into this
| mess partly because for (IIRC) ~10 years or so, the ncurses
| people stopped updating the terminal database with information
| about new capabilities like bracketed paste and 256 color
| support, forcing authors of programs wanting to use these
| features into using dirty hacks to detect or configure support
| --- and everyone has a different dirty hack!
|
| Also, terminfo in inconvenient when jumping between machines. Who
| among kitty users, for example, has never experienced weirdness
| after ssh because the target machine doesn't have a terminfo file
| for "xterm-kitty"?
|
| To fix this mess, we need to:
|
| 1. Define a new cross-terminal-emulator OSC sequence that
| instructs the terminal emulator to echo back THE WHOLE TERMINFO
| CAPABILITY STRING, _in_ -band. No "user agent sniffing" with
| TERM. We detect features directly from now on.
|
| 2. Stop hard-coding random "ANSI" escapes. Use a library. Ask
| that library, "What does this terminal support? What strings do I
| use to accomplish what I want?" and then use it.
|
| 3. By default, don't output escape codes if output isn't a tty.
|
| (#2 (by recognizing TERM=dumb) and #3 (because pipes) also
| address the problem of escape sequences ending up in the middle
| of output files and shell pipelines.
|
| The terminal world is a mess right now. Continuing to live in
| squalor is a choice.
| Ferret7446 wrote:
| A lot of people now don't know how terminals work or even that
| terminfo exists.
|
| Unfortunately due to the progression of technology and
| education, a lot of foundational knowledge is not being
| learned. Terminals are probably one of the biggest losers in
| this area. Even many technically knowledgeable people only know
| of terminals as "that box that pops up where you can type
| commands". They cargo cult/copy-paste the common escape
| sequences. Most things work "good enough" now that they never
| have any reason to learn more.
| zokier wrote:
| In what universe is terminfo "foundational knowledge"
| quesera wrote:
| The Unix universe obviously.
| navi-desu wrote:
| > 1. Define a new cross-terminal-emulator OSC sequence that
| instructs the terminal emulator to echo back THE WHOLE TERMINFO
| CAPABILITY STRING, in-band. No "user agent sniffing" with TERM.
| We detect features directly from now on.
|
| XTGETTCAP does that (kindof), it's implemented by xterm, kitty,
| and foot.
|
| xterm allows querying keyboard caps, plus a few others
|
| kitty adds to that querying all integer and string caps
|
| foot adds to that bools caps, meaning in foot you can query all
| of terminfo via it.
|
| what we need to do is bring other terminal emulators up to par
| with foot's XTGETTCAP, and then we can finally ditch
| libterminfo for good.
| quotemstr wrote:
| > XTGETTCAP does that (kindof), it's implemented by xterm,
| kitty, and foot.
|
| Oh, cool. Agreed we need to bring other terminal emulators up
| to speed. I might as well do Emacs's.
| spudlyo wrote:
| I'd like to re-emphasize point #3. FOR THE LOVE OF GOD, if you
| _are_ going to spew random ANSI escape sequences to stdout,
| please, please, please, ensure[0] that it 's a goddamn tty!
|
| [0]: https://www.man7.org/linux/man-pages/man3/isatty.3.html
| kps wrote:
| One related: If you are a terminal emulator, and you default
| your TERM to xterm-somethingorother, it is on you to _actually
| support_ xterm control sequences.
| kristopolous wrote:
| My current secrets:
|
| * cht.sh is a great way to avoid a lot of this stuff - there's a
| commandline tool as well
|
| * usable cli ai setup: simonw's llm
| (https://github.com/simonw/llm) + openrouter
| (https://github.com/simonw/llm-openrouter) + free models
| (https://openrouter.ai/models?max_price=0) + glow
| (https://github.com/charmbracelet/glow) + adding this to your .rc
| file: function lm { local
| input="$*" llm -s 'Answer as short and concise as
| possible' ${input} | glow }
|
| Here's an example, $ lm "ssh command to forward
| the port 5050 on user@remote to my localhost:7001" ssh
| -L 7001:localhost:5050 user@remote
| $
|
| Now for a sophisticated use-case I have a small tmux program
| where I can capture what's on the pane, enter a prompt and it
| will query an llm so I can say things like "How do I fix this
| error" or "what debian package do I need to get this to run
| right?" ... both these are recent patterns I've started and
| they've been real game changers
|
| Some lesser game-changers:
|
| * tmux extrakto - opens an "fzf" like search of all the text on
| the screen. So after a "git status", I can do git add (run
| extracto - enter partial path, press tab) and continue:
| https://github.com/laktak/extrakto
|
| * mcfly history: https://github.com/cantino/mcfly just watch the
| demo, you'll see
|
| * ugrep: grep with a powerful tui:
| https://github.com/Genivia/ugrep - I became an instant convert.
|
| * batcat: https://github.com/sharkdp/bat ... you really need to
| use some of its other features to leverage it. It's really nice.
| regnull wrote:
| I did a similar thing, where you describe what you want to
| achieve and it gives you the command and (optionally) executes
| it for you:
|
| https://github.com/regnull/how.sh
| kristopolous wrote:
| I see you did some prompt engineering:
| https://github.com/regnull/how.sh/blob/main/how.sh
|
| I think the real sweet-spot flow is to take this and use
| bindkey to do inline replacement. Let me fork it and see what
| I can do.
| regnull wrote:
| Yeah I tweaked the prompt to make it work reasonably well.
| There is also an experimental mode where it can reason and
| correct the command if it fails. Feel free to sent a PR!
| kristopolous wrote:
| Alright, done.
|
| It's a re-invention really.
|
| Essentially you do (assuming zsh) $
| source how.sh
|
| Then you type your thing at the shell $
| add a user bob using modern homectl methods
|
| Then you (in the default, CTRL+X+H) and it does this
| $ add a user bob using modern homectl methods ... (name
| of your default model) ... a few seconds pass ...
| $ sudo homectl create-user bob
|
| Then you can choose to press enter and run it.
|
| https://github.com/kristopolous/how.sh
|
| This is a much more one-and-done approach but 99% of the
| time I just forget invocation syntax - I'm not actually
| exploring things deeply.
|
| If you want a "proper" pr, it'd really be a rewrite with
| two "frontends" - your conversational edit flow and my
| keystroke invoke.
|
| Honestly they're probably different things.
| regnull wrote:
| Interesting approach, thanks for sharing!
| ddworken wrote:
| I actually made a CLI tool
| (https://github.com/ddworken/hishtory) that automatically
| binds to Control+R to support both history searching and AI
| queries (by prefixing queries with `?`).
|
| Here's the prompt engineering I did: https://github.com/ddw
| orken/hishtory/blob/master/shared/ai/a...
| kristopolous wrote:
| Ah this is a far more significant effort. I'm glad to see
| that there's so much consensus that default shell history
| is broken (I used to use logrotate because it would
| always truncate regardless of how many ways I told it to
| not ever, under no conditions, ever, do that).
|
| Nice to see there's so many options these days. Someone
| else mentioned "https://atuin.sh/" in this thread - which
| is also new to me. Keeping up with things is seemingly
| impossible
| porridgeraisin wrote:
| Here's how I think I make sure it doesn't truncate:
| shopt -s histappend shopt -s cmdhist export
| HISTCONTROL=ignoreboth export HISTFILESIZE=-1
| export HISTFILE=~/.bash_eternal_history export
| HISTSIZE=-1 export HISTTIMEFORMAT="%d/%m/%y %T "
| export HISTIGNORE="history:ls:l:ll:pwd:exit:clear"
|
| It's almost a megabyte now... By when did it start to
| truncate for you?
| kristopolous wrote:
| somewhere around a few thousand lines. I want it to
| support tens of millions. I have a fast enough computer,
| storage is effectively free. I've tried all those things
| - everything short of doing a bunch of bpf filters and
| setting breakpoints on the binary myself.
|
| honestly, with these modern systems this shouldn't be a
| problem any more. I look forward to it.
| porridgeraisin wrote:
| Yeah i have lots. Try my solution might work for you
| also.
| scottyeager wrote:
| Here's my take on an LLM based shell helper for command
| suggestions and more: https://github.com/scottyeager/Pal
|
| It features an integration with the abbreviation feature in
| fish and zsh (via plugin) to expand the suggestions for
| editing, if needed, and execution.
|
| There's stdin support, which can be used to pipe in error
| messages, for example. I've thought about something like your
| tmux setup to capture and pass some history to the model, but
| in practice redirecting stderr handles most of the potential
| use case.
| thwarted wrote:
| > Here's an example, $ lm "ssh command to forward the port 5050
| on user@remote to my localhost:7001" ssh -L 7001:localhost:5050
| user@remote
|
| Was this a real example of the input and output generated,
| because it seems wrong.
|
| -L 7001:localhost:5050 listens on port 7001 locally and
| forwards connections to 5050 on the remote host.
|
| Based on the request, you want -R 5050:localhost:7001, which
| listens on port 5050 at the remote end and forwards connections
| to a server listening on localhost:7001 on the local end.
| __s wrote:
| For colorsheme allow me to suggest
| https://github.com/savq/melange-nvim
|
| Has configs for multiple programs, is warm (low blue light),
| avoids too many colors / clown vomit
|
| I was considering giving up on colors with zenbones before I
| found this
|
| For copy/paste I'm using a 36 key keyboard, ctrl is on a thumb
| key hold, while holding , is shift-ctrl. But that's probably not
| as generally useful to others
| exmadscientist wrote:
| > inconsistent command line arguments: is it -h or help or -help?
|
| I've said it before and I'll say it again: the error "Option
| `--help` not understood, did you mean `-help`? Use `-help` to
| display program options." is one of the most insulting things a
| program can say to me. `--help` is the lowest common denominator.
| You have to support it. I don't care what your program has to
| special case in its parsing, just do it. If I knew your program's
| preferred syntax, _I wouldn 't be asking it for help_.
| xboxnolifes wrote:
| --help isn't even the lowest common denominator. An incorrect
| argument list is. The program knows it was given incorrect
| arguments, it should show help.
| exmadscientist wrote:
| Many programs prefer to be concise when their arguments are
| wrong, perhaps on the assumption that it's probably a simple
| typo rather than a request for screenfuls of help
| information. This sometimes is and sometimes isn't an
| ergonomic choice. (I usually prefer conciseness.)
|
| But asking for `--help` is unambiguous, and is in fact the
| lowest common denominator way to be explicit about it.
| dfox wrote:
| -? should be lowest common denominator, because that is
| exactly equivalent to passing incorrect argument list when
| using getopt(). Whether that should produce concise help of
| the kind "usage: foo -abcdeEf <file>" or full help is
| another question.
| lloeki wrote:
| `?` is a glob for one character so it would work only if
| you:
|
| a) use bash-like behaviour of an unmatched glob turning
| into a bare word, e.g with zsh have `setopt NULL_GLOB`.
|
| AND
|
| b) don't have a file named, say, `-a` in the current
| working directory.
|
| Try this: touch ./-l ls -?
|
| The common denominator for getting help would be man(1).
| maleldil wrote:
| > The common denominator for getting help would be
| man(1).
|
| That's... not what a common denominator means. It's far
| easier to check for `--help` or `-h` and print
| _something_ than write a whole document in a weird markup
| language for man.
| lloeki wrote:
| "common denominator" is the thing that is _guaranteed_
| common for all commands.
|
| man(1) is, provided that people produce man pages. It's
| also orthogonal and composable without interference: one
| can write a man page for commands that don't have man
| pages.
|
| Flags are not, because commands parse their arguments in
| whatever way; all commands can accept arguments but
| arguments are also part of the operational interface
| contract. man(1) is decoupling all possible problems out.
|
| It is also extremely obvious than `man foo` is side-
| effect free, whereas `foo whatever`, whether `whatever`
| can be `--help` or anything else, has unknown effects
| when the command is unknown.
|
| Some argue that man pages are too rich; well the man
| pages can just also start with a summary identical to
| what a hypothetical `--help` flag would output.
|
| Turns out this is the conventional `SYNOPSYS` title of
| section 1 man pages, and possibly the `OPTIONS` one; if
| these are absent or badly written then one could
| reasonably posit that a hypothetical `--help` flag output
| would be just as unhelpful; cue the wads of commands that
| "--helpfully" output `foo [-4236xXksirtTgsdv]` as help,
| which tells you nothing really helpful.
|
| `info(1)` can burn in hell though.
| maleldil wrote:
| My understanding is the opposite: man pages are much more
| difficult to produce than plain help text, so it's
| unreasonable to expect they'll always be available, while
| help is easy enough to (almost) always be there. If you
| use any CLI library at all, it will automatically be
| generated. If you don't, the equivalent of `argv[1] == "
| --help"` is good enough.
|
| These days, I'm positively surprised when I find man
| pages for a program, whereas I'm annoyed when one doesn't
| support --help.
| lloeki wrote:
| > man pages are much more difficult to produce than plain
| help text
|
| They're absolutely trivial to generate these days, gone
| are the days of having to deal with roff, you can write a
| quite dumb markdown file and produce a man page out of it
| in short order.
|
| https://github.com/sunaku/md2man/blob/master/EXAMPLE.mark
| dow...
|
| https://github.com/rtomayko/ronn/blob/master/man/ronn-
| format...
| TeMPOraL wrote:
| > _Some argue that man pages are too rich_
|
| There are people arguing that? My feeling is that man
| pages are usually so thin as to be useless in 50%+
| scenarios I need them. I really wished the culture
| defaulted to expecting all software to come with Info
| pages.
| TeMPOraL wrote:
| > _b) don 't have a file named, say, `-a` in the current
| working directory._
|
| Rather:
|
| b) don't have a file with a _single letter name_ in your
| CWD, like `a`
|
| Try this: touch a ls -?
|
| And yes, it's even more damning; you don't generally find
| legitimate files named `-a` or similar - rather, it's
| clear indication of someone invoking some CLI command
| wrong (`cp` comes to mind). However, single-letter files
| and folders are a relatively frequent thing to see.
| lloeki wrote:
| Haha true, I missed the most obvious of all!
| linsomniac wrote:
| Very few things grind my gears like having to search
| through a wall of "--help" output and lengthy list of
| arguments to find the error that describes the problem.
| Screenfulls of text when the error is "Option 'b' unknown"
| isn't helpful.
| AStonesThrow wrote:
| Oh it's worse than that. Some classes and even
| supervisors I've had, forced me to read documentation,
| over and above actually doing stuff
| Thorrez wrote:
| If you need to learn something (e.g. you're taking a
| class or your supervisor wants you to learn something),
| then reading the documentation is a good idea.
|
| If you already know the content, but accidentally made a
| typo and are trying to debug it, then reading the
| documentation isn't going to help. An error message
| pointing out the problem will help.
| linsomniac wrote:
| I had a teacher like that in High School. "I made a
| mistake in this proof, but I'm not sure what it is." "You
| have the book for the course, the answer is in there."
| kevin_thibedeau wrote:
| Would you expect a sports referee to manage a match
| without knowing the rules of the game?.
| gerad wrote:
| lol how the sarcasm was lost on hackernews
| sbuk wrote:
| Reading techical documentation is a skill. It's one that
| is sorely lacking in IT from develpers to ops. RTFM when
| learning is a valid lesson in and of itself.
| gknoy wrote:
| This seems like it would be solved completely by printing
| the error message ("option b unknown"), and then also
| printing the "--help" stuff. You can see the error inthe
| first line(s), so `head` will make that easy to see, but
| anyone trying to print the help text will get it.
| GoblinSlayer wrote:
| >--help isn't even the lowest common denominator. An
| incorrect argument list is.
|
| --help being an incorrect argument does the right thing, yes.
| crabbone wrote:
| Sometimes, arguably, you can do better. For instance, some
| CLI tools try to guess what the user was trying to
| accomplish, and show a more specialized message. Eg. kubectl
| will tell users that a particular kind of resource they were
| looking for doesn't exist, but there are some with similar
| names.
|
| This is especially useful in situations where the help text
| is enormous (dozens and dozens of options).
| pgwhalen wrote:
| I agree with this, but would also point out that many junior
| engineers I've worked with completely give and ask for help
| if the program doesn't do what they want it to and prints out
| many lines of help. Even if there is a clear message at the
| top of the large output, they get overwhelmed.
| immibis wrote:
| An incorrect argument list should concisely tell me what is
| wrong with the argument list, and that I can use --help to
| explain the whole thing. I don't want to scroll up 20 pages
| to fix a typo - assuming the program even printed a specific
| error before it printed 20 pages of help.
| lucb1e wrote:
| Oh god please no, I hate the rare program that poops my
| terminal full of seven pages of output and I have to use like
| shift+pgup or the mouse to get back up to see the only four
| useful words of output: "option --anakyze not recognized".
| This also confuses the heck out of beginners.
|
| MariaDB also doesn't print the entire manual when it goes
| "syntax error at ' OR 1=1". It makes no sense.
|
| You can include "See --help for more information" at the end
| of every error to make sure everyone knows where to find
| that, though, since indeed not every program uses the same
| syntax for usage. 90% of the time I don't need a copy of a
| program's manual in my scrollback when I, say ,typo something
| or forgot that two options are incompatible. There is a
| reason scrollback exists and I use it for that purpose. I'll
| look up the manual or run --help in another terminal
| tab/window, or choose to run it in the current one at my own
| discretion thank you
| danudey wrote:
| Just to throw this out there: let's also hate on programs
| that give you seven pages of output for --help but print it
| to stderr so you have to jump through shell redirection
| hoops to pipe it to a pager to be able to read or search
| through it.
| Arnavion wrote:
| `--help` is a GNU convention, which is why it's not as
| universal as you want it to be. Of course these days most Linux
| users interact with GNU tools and thus go on to develop their
| own tools with the same convention, but it's the reason why
| non-GNU things like BSD utils or old `openssl` don't have it.
| hylaride wrote:
| The GNU/BSD conventions are a lot of fun when you have some
| automation scripts that are used by people who are split
| between MacOS and Linux (or WSL on Windows).
| kps wrote:
| `--long` options started with GNU (I think) but were soon
| adopted more widely. One of the really nice things about ksh
| that bash has neglected to copy is that its `getopts` easily
| handles long options and has built-in `--help`.
| jerf wrote:
| It's 2025, not 1995. I'm about as sympathetic to this as
| "POSIX doesn't have it." For something like this, I don't
| care.
|
| I don't care how it's done. Heck, dump the help if you see
| any option with two dashes, if you're offended about long
| options. I don't care what other things dump help out too as
| long as --help does. But both -h and --help should always
| produce help, no matter what, no matter where you are, and
| I'd really like -help too, even if that is a bit more
| complicated. Though since I also want "a -h or a --help in
| the parameter list reliably makes it so that help is printed
| and NOTHING ELSE happens", "-help" should generally work as
| "-h" and "extra stuff that won't happen because -h is in
| play". It is an error for a program to both print the help
| and take any other action; should always do one XOR the
| other.
| benatkin wrote:
| What about programs with such simple CLIs that they don't
| have help?
|
| How about non English speakers who might be inclined to
| type --ayuda or something?
|
| In 2025 I think it should be more obvious that the shell is
| just running a program and programs have a variety of entry
| points and the same program can be distributed in different
| forms and that they might not all be self documenting.
| f1shy wrote:
| Personal opinion ahead, please don't be offended:
|
| > What about programs with such simple CLIs that they
| don't have help?
|
| It is crapware
|
| > about non English speakers who might be inclined to
| type --ayuda or something?
|
| Come on... really?! Most utilities use heavily english
| for option names. Even the names of the utilities. Should
| we have "buscar" instead of "find", or "schneiden" for
| "cut"? What about iger instead of "grep"?
|
| That is just ridiculous! Please stop!
| benatkin wrote:
| I'm not offended hehe. I like small processes, and am
| into language learning, so my bias is showing. I think
| how things are, with most supporting --help, but not all,
| makes sense.
|
| I think what some are going for perhaps is that all
| programs to be run in the shell support --help. I think
| it could be normalized further by having a shell function
| get help for a command. For most it could pass --help,
| but it could handle the exceptions. So instead of running
| "foo --help" you could run "help foo", and it would run
| "foo --help" or "foo -h" or whatever, and it would be
| like man except instead of meaning show a manual page it
| could mean ask a program to document itself.
| Arnavion wrote:
| >I think it could be normalized further by having a shell
| function get help for a command.
|
| See PowerShell commandlets for a related precedent:
| https://learn.microsoft.com/en-
| us/powershell/scripting/devel... Commandlets (shell
| functions) can annotate themselves and their parameters
| in a standard way, and then the shell's builtin help
| command parses that and presents it in a standard way.
| Though unfortunately this kind of integration only works
| for the commandlets, not arbitrary executables, because
| there's no standard for executables to expose such
| metadata to the shell.
| Y_Y wrote:
| I'm interested in how you've translated "grep".
|
| I would guess you chose something like mapping "Global
| Regular Expression Print" to "Imprimir Globalmente
| Expresion Regular". But of course "grep" isn't really an
| acronym, but a contraction of the ed (and ex) command
| "g/re/p". Surely you don't mean to alter the syntax along
| with the words!
| Arnavion wrote:
| To be clear, the point of my comment was to give the reason
| that `--help` isn't universal, not to present any opinion
| on whether it should or should not be. (I myself am in the
| "go on to develop their own tools with the same convention"
| camp.)
| f1shy wrote:
| If I'm working in Ubuntu, a GNU/Linux system, I expect to be
| pretty universal.
|
| I'm BSD and Solaris guy, but when I'm in linux, I spect
| linux. It should be part of PORTING a program, if the option
| is not supported.
| bouke wrote:
| Or database clients (e.g. psql) using `-h` for the host
| argument. I get it, but I don't like it.
| viraptor wrote:
| -H is right there and available. But they chose to be
| slightly weird...
| kccqzy wrote:
| On macOS the shutdown command uses `-h` to mean halt, i.e. an
| actual shutdown.
| swiftcoder wrote:
| The fact that they _already_ special-cased the parser to let
| you know that you used the wrong help option, but didn 't just
| forward to the right one, is just incredibly pedantic
| ithkuil wrote:
| It's probably fuzzy similarity search
| TeMPOraL wrote:
| If you can bother writing a fuzzy similarity search, you
| can just short-circuit it on "--help". Most software I see
| with such problems do _neither_.
| ithkuil wrote:
| I think the idea is that fuzzy search makes it easier for
| users to spot typos and this is a general feature of the
| flag library not something specific for --help.
|
| Short-circuit any typo may be dangerous.
|
| Now, an argument can be made for including as many
| aliases for "help" and "version" as possible but that's a
| different story
| pgwhalen wrote:
| You can of course - I think the point here is it's
| different people with different goals writing the CLI lib
| vs the application.
|
| So it's often not the case that a single person who made
| the decision to have a message that says "you asked for
| help, but you did it wrong; before I give you help you
| have to ask correctly."
| swiftcoder wrote:
| "this dependency I picked at random from CPAN doesn't
| support that" is a pretty weak excuse for shipping a poor
| user experience
| WD-42 wrote:
| I don't think people bother to write them, more likely
| it's built in to whatever cli lib they happen to be using
| and they enable it.
| idle_zealot wrote:
| Is it? It _is_ helping you. Your first tip: here 's what the
| argument syntax looks like, use it.
| swiftcoder wrote:
| It's "helping" in an incredibly pedantic and unhelpful way.
| The developer has opted to add explicit support for the
| common option, but only as a means to tell the user that
| they are "holding it wrong" (in the immortal words of
| Apple)
| danudey wrote:
| When I was a kid, I was playing Beyond Zork, and one
| night when I was very tired I came across a pterodactyl.
| Unfortunately, I kept making typos.
|
| >> aim wand at perodactyl
|
| > I see no perodactyl here.
|
| >> aim wand at pterodacyl
|
| > I see no pterodacyl here.
|
| Frustrated at my continuing mistakes, I decided to try to
| short-circuit their logic. Despite knowing the
| difference, I typed this:
|
| > aim wand at bird
|
| And the game replied:
|
| > a pterodactyl is not a bird
| kstrauser wrote:
| I LOLed at that, thank you. Infocom games were amazing.
| montag wrote:
| Haha. "The developers thought of everything" (not really
| though)
| AStonesThrow wrote:
| sorry, you've typed "[em][en]h[Cyrillic]lp", try again
| toast0 wrote:
| Likely they print that message for any unknown argument.
| ljm wrote:
| Also, single dash for long args and not just short args. I
| think mostly Go tools do this, and whatever purism is used to
| justify the choice, I can't think of many CLI apps that don't
| use a single dash for short args (and combining a sequence of
| flags) and a double dash for long ones.
| oxidant wrote:
| `find` comes to mind. I consistently need to look up the
| syntax.
| idunnoman1222 wrote:
| Use fd instead
| danudey wrote:
| In case people were curious:
| https://github.com/sharkdp/fd
| Daneel_ wrote:
| If it's not installed by default on server-oriented
| flavours of Linux then it's dead to me, unfortunately.
| Most orgs aren't going to agree to roll it out across
| tens of thousands of machines on a whim.
|
| My entire Linux experience is dictated by what's
| installed by default on rhel and/or ubuntu.
| tdeck wrote:
| A lot of Java tools do this for some reason and I hate it.
| kevin_thibedeau wrote:
| Double dash for long args is a GNUism. One which even they
| don't adhere to uniformly as evidenced by GCC's options.
| codesnik wrote:
| it's a simple to learn gnuism that most good tools follow
| but (mostly) java apps for whatever reason disrupted it and
| added a lot of mess.
| layer8 wrote:
| The Java tools predate the GNU convention (or at best
| were developed at the same time, unbeknownst to each
| other). Golang uses single-dash as well (but also accepts
| double-dash), as do PowerShell and Unix commands like
| _find_. In early Unix, there wasn't a clear convention to
| use a dash for options at all (dd, tar, ps).
| kevin_thibedeau wrote:
| GNU was established 10 years before Java.
| layer8 wrote:
| GNU double-dash long options were devised only after
| POSIX disallowed using the plus sign in 1992:
| https://blog.djmnet.org/2019/08/02/why-do-long-options-
| start...
|
| Java was already two years in development at that time.
| camel-cdr wrote:
| It is, but combining a sequence of flags is POSIX.
| plagiarist wrote:
| This sets me off. Whenever I have any viable alternative to a
| single dash long arg tool I take the alternative.
| somat wrote:
| Personally, I dislike gnu style double dash and actively
| despise the double dash equals variant( --arg=value ). I just
| think it adds a lot of unnecessary noise to the command line.
|
| And after a bit of shower thinking, you know that alone time
| with nothing better to do but ponder the mysteries of the
| universe, things like black holes, the nature of light and
| the ascetic of the command line. I decided that single dashes
| were also sort of ugly and hindered readability, but there
| was a better way as hinted by the single most screwball
| command in the standard unix installation.
|
| Yes it is I ( evil laugh ), that misanthrope actively making
| new cli scripts what use dd style arg=value
|
| http://nl1.outband.net/extra/remv.txt
|
| Actually the real epiphany was when I was doing some work
| with "megacli" the tool for lsi hardware raid management. I
| noticed that sometimes I could forget to add a dash to an
| argument. A little experimentation showed that no arg
| actually required a dash and the capitalization was ignored.
| it was like a huge weight was lifted from my shoulders, much
| better this way. MegaCli -PdReplaceMissing
| -PhysDrv [1:1] -Array2 -row1 -a1 MegaCli
| pdreplacemissing physdrv [1:1] array2 row1 a1
| danudey wrote:
| Does MegaCli still ship with its own copy of libc5 because
| it's so old and disgusting that they can't bring themselves
| to upgrade it? Or did they figure out how to resolve that
| eventually?
| danudey wrote:
| It's most common in Go's own tooling (e.g. `go build
| -buildmode`) but is also present in older tooling like e.g.
| GNU findutils (e.g. `find . -name something`).
|
| The go tooling also has the irritating tendency to take a
| command like `go build --help` and say "oh, run `go help
| build` for details" instead of just printing out a list of
| possible options. Also: the details page doesn't always
| present you with a list of possible options, so you have to
| read each paragraph to see if there's an option relevant to
| your interests.
| scbrg wrote:
| I find it helpful. If it's a program that generally supports
| single dash options only, having it respond to --help will
| falsely make me believe that it's one that expects double dash
| options.
|
| Letting me know that the proper way to ask for help is `-help`
| also communicates that GNU style double dash long opts is not
| the way to go with this particular program.
|
| Then I suppose you could argue that GNU style double dash
| options _should_ be supported. Meh, I dunno. _They_ were the
| ones that invented the fifteenth standard (xkcd /927).
| exmadscientist wrote:
| I mean, it's perfectly fine if the way `--help` communicates
| that you shouldn't be using double-dash options is by...
| giving the help text that has all single dash options. That
| seems like pretty solid communication?
|
| I don't care at all which type the program likes. I just
| can't remember which programs like which styles. So I ask
| them. And I prefer if they don't insult me when I do.
| scbrg wrote:
| Heh. Fair enough :-)
|
| I just don't really see how that one, single, extra three
| second step is much to get upset about, and I think it's
| just welcome that it rubs me in the face that I got it
| wrong. It makes me not gloss over the help text and start
| double dashing my way into the next to command.
|
| But sure, I see your point. I just wished K&R had had the
| forethought to establish a proper standard. I don't
| particularly care what it would have been.
| blueflow wrote:
| Its not "$command --help", its "man 1 $command". You should not
| invoke programs blindly, hoping "--help" causes them to do
| nothing else.
| tenacious_tuna wrote:
| this works great on systems where programs are largely
| installed via package manager, but in plenty of environments
| is an unreasonable expectation. There's many many times I've
| gotten "no manual entry for $program" but there's extensive
| online help available in the program itself.
|
| Expecting there to be a safe invokation for "how do I use
| this damn thing" is 100% fair.
| blueflow wrote:
| > Expecting there to be a safe invokation for "how do I use
| this damn thing" is 100% fair.
|
| Are you on debian? Do an `/usr/sbin/e2scrub_all --help`.
| danudey wrote:
| Okay. $ e2scrub_all --help
| e2scrub_all must be run as root $ sudo
| e2scrub_all --help [sudo] password for dan:
| /usr/sbin/e2scrub_all: illegal option -- - Usage:
| /usr/sbin/e2scrub_all [OPTIONS] -n: Show what
| commands e2scrub_all would execute. -r: Remove
| e2scrub snapshots. -A: Scrub all ext[234]
| filesystems even if not mounted. -V: Print
| version information and exit.
|
| (Checking for being root before checking for --help is
| also frustrating)
| scubbo wrote:
| I genuinely can't tell if this is a joke or not. I've only
| _once_ in my life encountered a tool that didn't have
| `--help` support (and that was a script written by the worst
| coworker I've ever suffered), but plenty of times I've
| encountered tools that have no manpage entries.
| enriquto wrote:
| > I've only _once_ in my life encountered a tool that
| didn't have `--help` support
|
| Never heard of echo? What do you expect this to do?
| echo --help
| jancsika wrote:
| _display the help message and exit_
|
| https://www.man7.org/linux/man-pages/man1/echo.1.html
| blueflow wrote:
| $ echo --help --help $ type echo echo
| is a shell builtin
| f1shy wrote:
| Amen!
|
| Some programs give a short help message when options are not
| understood. A good thing.
|
| That said, in GNU/Linux a program that does not have --help is
| shitware.
| WD-42 wrote:
| Agreed, but to be fair some of that comes from fuzzy searching
| the available parameters for close matches. Which is normally
| helpful.
| nurumaik wrote:
| Just print help instead of any error during parsing
| chasil wrote:
| POSIX doesn't have any of that.
|
| https://pubs.opengroup.org/onlinepubs/9799919799/utilities/
|
| "I got used to fish and vi mode which are not available when I
| ssh into servers, containers."
|
| POSIX does mention vi mode as an optional feature.
|
| "Allow shell command line editing using the built-in vi editor.
| Enabling vi mode shall disable any other command line editing
| mode provided as an implementation extension. This option shall
| be supported if the system supports the User Portability
| Utilities option."
| blueflow wrote:
| And POSIX has man(1) instead of --help: https://pubs.opengrou
| p.org/onlinepubs/9699919799/utilities/m...
| danudey wrote:
| Don't forget when a program _only_ accepts short-form
| arguments:
|
| `cmd --help`
|
| Error: option - not understood. Use `cmd -h` for help.
|
| Or this pattern that we find everywhere in golang-written
| tools:
|
| $ helm --version
|
| Error: unknown flag: --version
|
| $ helm version
|
| version.BuildInfo{Version:"v3.17.0",
| GitCommit:"301108edc7ac2a8ba79e4ebf5701b0b6ce6a31e4",
| GitTreeState:"clean", GoVersion:"go1.23.4"}
|
| (The reason for this one seems to be that, in your CLI-parsing
| library, you have verbs that define what you want and flags
| that pass options to those verbs; 'show me the version' is a
| verb, so it can't be a flag instead. Without a verb, the
| program doesn't know what to do.
|
| It's still infuriating, though, but at least it reduces the
| frequency with which -- is substituted for an em-dash (e.g.
| when sending commands to coworkers from your iPhone via Slack).
| ggm wrote:
| Iterm grabbed text highlit under mouse immediately for paste. Mac
| terminal. It's mac norms which means cmd-c
|
| A very minor annoyance.
|
| I dropped iterm to reduce my surface of dependency on complex
| systems. Somewhat confusingly un reductionist, xquartz and xterm
| would be the logical endpoint.
| smackeyacky wrote:
| I have often thought it would be fun to have a Smalltalk like
| interaction screen, where you could leave snippets of code lying
| around and a "do it" menu item.
|
| Kind of like how most of the SQL systems like dBeaver work. I
| have a scratchpad of SQL in a file I use for fiddly jobs, and a
| file like that for shell commands would be good if it had all the
| flags for awk or grep or whatever handy.
|
| Would also be cool for the AWS and azure cli tools. I had
| something half working as an old VisualWorks experiment that
| implemented an AWS service on one side and a scratchpad in the
| middle but I feel like it might be a very cool vscode extension
| instead.
| gossamer wrote:
| My biggest terminal frustration would be lack of access to
| Terminal. I have loved terminal windows since about 1981 or so. I
| was a big DOS fan and would only use Windows up until the Mac
| switched to OS X. I switched and never looked back.
|
| Every day I use zsh on my Mac and bash on all the servers I use
| (almost all are Ubuntu).
|
| My biggest peeve is the difficulty with formatting output in an
| elegant way when writing shell scripts. I have wrangled it for
| the most part, but all the solutions that I have found seem a bit
| janky.
| InfinityByTen wrote:
| Making command line tools at work really made me appreciate the
| work it takes to make a good one.
|
| Do you have a good `--help`? Did you catch the common mistakes
| and return a helpful error message? Did you put reasonable
| defaults? Do you have enough examples on how to actually use it:
| not just one running example, but actually one that uses at least
| _some_ of the options.
|
| Your UX instincts do get tested in this.
| stuaxo wrote:
| For categorising feedback like this, a card sorting exercise can
| work well, and then move go a spreadsheet.
| oneeyedpigeon wrote:
| Whatever version of find I have installed, it's an incredibly bad
| actor: > $ find --help > find: illegal
| option -- - > > $ find -help > find: illegal
| option -- h > > $ find -h > find: illegal
| option -- h
|
| I say "whatever version" because I cannot find that out either. A
| bare `find` doesn't tell me and I get similar non-support for
| --version / -v.
| slightwinder wrote:
| Have you tried finding its path and looking into the file
| itself? Maybe it's a wrapper or alternative version somewhere
| in your $PATH you installed and forgot?
|
| And to add some mor efor testing: you can try "find /help",
| "find /?" and "find -?", in case it's using dos-style
| parameters.
| oneeyedpigeon wrote:
| > $ file `which find` /usr/bin/find: Mach-O universal
| binary with 2 architectures: [x86_64:Mach-O 64-bit executable
| x86_64] [arm64e:Mach-O 64-bit executable arm64e] >
| $ find /help find: /help: No such file or directory
| > $ find /? zsh: no matches found: /? > $
| find -? zsh: no matches found: -?
| achierius wrote:
| If you have brew you can install findutils to get gfind
| which behaves more like you'd expect
| slightwinder wrote:
| Is this MacOS? As I remember, they are using the tools from
| freebsd, and according to man-pages I randomly found on the
| internet it has indeed no help-parameter. I guess, their
| culture is to use "man" instead of flavors of --help.
| gregjor wrote:
| You have a manky version or an alias over find somewhere.
|
| On my system Ubuntu 24.04: $ find --version
| find (GNU findutils) 4.9.0 $ find --help works
| $ find -help works $ man find then /help
| works
| p0w3n3d wrote:
| Am I the only one to whom the term _terminal frustrations_ sounds
| like things that frustrate you and then you die?
| AStonesThrow wrote:
| Headline editors gonna edit
|
| You could also think about sitting at a train station trying to
| code, or that feel when you lick a battery
| maleldil wrote:
| I like vivid[1] for managing colours in the terminal. It sets
| LS_COLORS to configure colours for many tools in one command.
|
| [1] https://github.com/sharkdp/vivid
| gkfasdfasdf wrote:
| Thanks for the tip, another awesome tool from sharkdp.
| efitz wrote:
| Learning command line options is like learning hundreds of DSLs.
| It gets worse when you have to learn more, or different, sets for
| different platforms, like Linux vs MacOS.
|
| Unices, by design, intend for you to compose many of these, so
| you not only need to learn the DSLs but you also have to learn
| the input and output formats, and learn even more DSLs to "glue"
| the commands together.
|
| Finally, you need to learn yet another language (typically bash)
| to compose these together.
|
| So using the CLI either slows productivity greatly as you have to
| look up everything, or requires years and years of time
| investment to become proficient, much of which investment is non-
| transferable.
|
| I think that Microsoft PowerShell makes many of these problems
| much better, but aliasing for brevity re-introduces some of the
| toil involved, and afaict psh has not gained traction anywhere
| but Windows.
| xerox13ster wrote:
| Powershell is so asinine I don't know why you would bring it up
| unless you're a blue badge crypto posting for Microsoft.
|
| Do you want to talk about portability and transferability? It
| is the epitome of non-transferable and non-portable.
|
| It is a domain specific shell language built for the Windows
| operating system win32 only. It does not work on Mac. It does
| not work on Linux. If you somehow managed to replace the Win32
| shell with something else, it doesn't work.
|
| Bash or at least the shell script in UNIX has been going for 50
| years. Power shell was shit out of Microsoft's ass in 2007 and
| reached "usability" in 2013.
|
| It broke compatibility with batch scripting, you have to call
| cmd to get batch scripts to behave. It broke compatibility with
| W scripting, or rather, justified to MS that abandoning script
| host was a worthy goal. It does not follow any of the same
| conventions as the Shell scripts and terminal commands that
| windows had used for decades at that point. If I want to
| accomplish something in powershell, I have to go look it up or
| I have to trust some command that somebody's written on stack
| overflow will do what they say it does because I don't have the
| time or the energy to go through and look up every single
| aspect of the command for a domain specific shell language that
| only works for a single operating system & that is worthless
| with any other system.
|
| I spent probably about a decade of my life from 11 years old to
| 21 years old learning to use the Windows command line and W
| script.
|
| To the degree that I literally automated myself out of my first
| tech job.
|
| So therefore, my decade of time investment to become proficient
| with Windows scripting is non-transferable and Microsoft
| decided to throw it out.
|
| If I had spent that time learning UNIX I would have been able
| to immediately go and use any other UNIX system and probably
| would've been able to get a much higher paying job at the start
| of my career.
| zokier wrote:
| https://learn.microsoft.com/en-
| us/powershell/scripting/insta...
|
| https://learn.microsoft.com/en-
| us/powershell/scripting/insta...
| jcranmer wrote:
| The problem with shell scripts are that they are objectively
| badly designed. And I do mean objective--there is no reason
| to accept that "accidentally delete your home directory" is a
| sane default behavior for "oops I forgot to set a variable".
| Any project that attempts to make shell scripts not broken
| is, by design, going to have break compatibility, because
| compatibility is insane.
|
| Powershell is interesting because it's attempting to
| introduce a different modality into shell scripts--rather
| than marshalling data as streams of bytes, you can actually
| represent the output as, well, data. So that a producer
| program can say "I'm outputting a list of files" and the
| consumer can actually handle it as a list of files and easily
| deal with the fact that maybe files have weird names like "
| ". A task that, for all the 50 years of experience on UNIX,
| still requires you to jump through hoops in every other shell
| script.
| Reasoning wrote:
| > If I had spent that time learning UNIX I would have been
| able to immediately go and use any other UNIX system and
| probably would've been able to get a much higher paying job
| at the start of my career.
|
| You'd probably be on here complaining about systemd and
| iproute2.
| gregjor wrote:
| Not transferable? In the context of the most widely-used server
| operating system? I have transferred Unix skills for decades,
| from one job and project to the next. Even Windows can run a
| Linux subsystem now.
|
| Having learned Unix/Linux and many of the tools myself I
| challenge the "requires years and years of time investment to
| become proficient." You missed that the knowledge and skills
| grow incrementally, so while you get to proficiency your skills
| constantly improve at the same time. You don't have to stop
| everything, study Unix for years, and then go back to doing
| something "productive" once you've memorized it all.
|
| Unix has one file format: plain text. The tools all compose
| around that. You can of course find exceptions -- you can't
| express everything in plain text -- but you can get remarkably
| far with simple single-purpose tools redirecting their output
| to the input of another tool.
|
| The core tools have more consistency than you give them credit
| for, describing them as hundreds of DSLs. They all have man
| pages, they more or less follow the same conventions with I/O
| and flag names. Plenty of exceptions, sure, but no more than
| you find in any large legacy system that has grown and adapted
| over time.
| matthewmorgan wrote:
| 'I built a tool' no you didn't, you wrote a program. Stop larping
| crabbone wrote:
| I didn't realize until now how many problems I avoided by using
| Emacs and ansi-term (and usually tmux running in it). Stuff like
| struggling with color schemes or remembering key bindings... I
| just solved them once many years ago and don't even remember
| anymore how I did it. Same for copy and paste.
|
| A lot of problems mentioned in the survey aren't really problems
| with the terminal, but, I guess, respondents didn't care about
| that kind of precision. Like... AWK syntax isn't a problem with
| terminals at all.
| sevensor wrote:
| It's quite remarkable that the whole stack works as well as it
| does. I'm using a terminal emulator, which is running a shell,
| which launches an ssh connection, which opens a remote shell,
| which I use to attach a tmux session where another shell is
| already running, which I use to open a file in a text editor,
| which displays a cat emoji correctly.
| hatthew wrote:
| Works well because almost all interaction is low-bandwidth low-
| latency duplex text streams. You can make a _lot_ of
| assumptions based on that.
| reddit_clone wrote:
| I use zsh history and fzf as my second brain. I can recall
| complicated, long winded commands I executed years ago with a few
| key strokes.
|
| This makes 'remembering' syntax and flags less stress inducing.
| You only have to figure it out once. Fzf will pull it up for you
| in a second. I also add #comments at the end of the commands to
| serve as search tags..
| IggleSniggle wrote:
| I have 100% same process, including the adding of comments at
| the end to tag commands for future fzf searchability (although
| in practice I find the need for this pretty rare).
|
| Of course it does also presume keeping an appropriately long
| history, which from some of the comments in the article make me
| believe that I have long since forgotten that I needed to
| change that setting.
| trallnag wrote:
| Are you backing up your command history?
| reddit_clone wrote:
| No. But I copy it over when I setup a new computer.
| jillesvangurp wrote:
| I think there are at least two different issues here:
|
| 1) the general UX of terminal emulators. Which as the wording
| suggests is about emulating some severely obsolete, at least half
| a century old hardware, including weird limitations that came
| with those. Most modern terminal emulators work hard to undo some
| of that. But it is weird that we stick with these being emulators
| for stuff most people here would never have touched in their life
| because they are not at retirement age yet. I just turned 50 and
| I remember having some slightly less fancy terminal emulators to
| work with (xterm basically) on hpux, sgi, and some sun
| workstations we had at university in the nineties. Even then the
| whole notion was basically obsolete. All those came with
| xwindows, xterm and some basic shells and other command line
| tooling.
|
| 2) the general UX of cli software that you would use from a
| terminal. Which is a bit all over the place and generally not
| great.
|
| If you use something reasonably modern, the terminal environment
| is not completely horrible. I use iterm2 on a mac, which is
| pretty nice. There are a few competing products. What I like
| about iterm2 is that I can use cmd+c and cmd+v for copy paste so
| I don't have to think about having to hit the shift key just
| because I'm in a terminal window (like on the Gnome terminal).
| Also nice is that two finger scrolling works. Even when using
| less/bat/more/whatever. There are a few other nice things that
| they solved but that solves a few basic UX issues.
|
| The second issue is harder to address because it basically
| involves fixing a lot of tools that have been around for decades,
| which is just not going to go down well with those that have used
| those tools for a few decades. There are some nice modern
| replacements for some of those tools. For example, I use eza
| instead of ls (via an alias of course). And there are a few
| similar rewrites of classic cli tools that offer some nice
| features and performance. But mostly those aim to be drop in
| replacements.
| jimmaswell wrote:
| > But it is weird that we stick with these being emulators for
| stuff most people here would never have touched in their life
| because they are not at retirement age yet.
|
| It's a standard that works, keeps a massive trove of software
| from being obsolete, and gives you backwards compatibility for
| free.
|
| Case in point, I recently installed Gentoo on my desktop from a
| VT320 terminal given to me by a friend. After a simple config
| line to tell the init system to put a shell on my serial port
| with the right options, I was working with modern Linux tools
| in 2025 on hardware from 1987.
|
| https://jimm.horse/img/vt320.jpg
|
| It's a testament to the value of maintaining standards and
| emulation that this terminal can be saved from e-waste.
| Everything mostly "just worked" once I got the TERM/environment
| set up right. Oddly seems like you need to set options to
| vt300, not vt320, for the best compatibility.
|
| It's a joy to use. The keyboard feels very nice to type on,
| very good for rubber dome. The amber light is easy on the eyes.
| I find working on the terminal makes me less prone to
| distractions, and it's also prompted me to get back into
| learning vim better. Any cases where I had trouble with control
| codes etc. were a good opportunity to learn more about the
| ecosystem - helps that that was my mindset going into
| installing Gentoo in the first place.
| stared wrote:
| Do you know any nice copilots working in the terminal?
|
| "remembering exact commands" (vide https://xkcd.com/1168/) and
| "getting context for a given instruction" are precisely things at
| which LLMs excel.
| knazarov wrote:
| For copy-pasting text to/from the terminal, I prefer to use Mac
| shortcut Cmd+C. It doesn't work out of the box on Linux (you have
| to use Ctrl+Shift+C, because Ctrl+C sends SIGINT). But there's a
| simple way to make Cmd+C work universally across all apps by
| rebinding Cmd+C to send Ctrl+Insert and Cmd+V to send
| Shift+Insert. It turns out these alternative keybindings work
| everywhere (browsers, GUI apps, terminal, etc). I use keyd to do
| that in software, but some QMK keyboards can do that rebinding on
| the keyboard itself.
|
| This is my keyd config: [ids] *
| [main] capslock=overload(control, esc)
| leftalt=layer(meta_mac) leftmeta=layer(alt)
| [meta_mac:M] c=C-insert v=S-insert
| schindlabua wrote:
| Then how do you SIGINT?
| mook wrote:
| What they're saying in Linux terms is that they map Super+C
| to Ctrl+Insert, so Ctrl+C still sends SIGINT.
|
| See also IBM CUA:
| https://en.m.wikipedia.org/wiki/IBM_Common_User_Access
| knazarov wrote:
| Right. Ctrl+C is still mapped as usual.
| pcthrowaway wrote:
| I don't remember if I did any special config in iTerm or
| installed a nonstandard package (I don't believe I did), but in
| Mac I often find it easier to just pipe a result I want copied
| into the `pbcopy` command in order to capture it in the
| clipboard, rather than trying to highlight what may be a long
| output.
| monroewalker wrote:
| Anyone else have their zsh history get truncated occasionally?
| Not sure where in my setup the issue is but sometimes the history
| file will just be recreated. I have all the histsize and other
| env vars set correctly and I haven't been able to correlate it to
| anything in particular I'm doing when it happens
| radicality wrote:
| Occasionally happens to me too. I believe I researched the
| cause being some kind of history corruption (eg bad control
| characters mistakenly pasted/output), and zsh will just make
| new history file if it detects corruption.
|
| Now, I made myself a cron script that once a day just copies
| the history file to a backup folder, so that I can bring it
| back if it ever corrupts.
| gkfasdfasdf wrote:
| For remembering CLI args, I now often turn to command line AI
| tools like 'llm' [0] or 'gh copilot suggest' [1]. They work
| remarkably well.
|
| [0] - https://llm.datasette.io
|
| [1] - https://docs.github.com/en/copilot/using-github-
| copilot/usin...
| jeffbee wrote:
| For real, this is one of the things that LLMs are
| unconditionally great at doing. They are like lossy compression
| algorithms that store Stack Overflow threads and retrieve
| manual pages. Or, with a fair probability of success, you can
| ask them to write the command.
| KerrickStaley wrote:
| > Half of the comments on keyboard shortcuts were about how on
| Linux/Windows, the keyboard shortcut to copy/paste in the
| terminal is different from in the rest of the OS.
|
| On Linux I rebind SIGINT to Ctrl+Shift+C and similarly Ctrl+V ->
| Ctrl+Shift+V. This has never caused problems, except when a
| friend/coworker is trying to use my machine.
|
| GNOME Terminal makes this easy; if you map Ctrl+C to copy, it
| will automatically remap SIGINT to Ctrl+Shift+C.
| encom wrote:
| I don't mind Ctrl+Shift+C so much, except that I mess it up
| several times a day, and that combo opens dev tools in Chrome,
| which takes several seconds to load on my work machine, messes
| up what I was doing and is a general nuisance. I wish there was
| a way to NOOP that combo in Chrome.
| bawolff wrote:
| My most frustrating thing is when you use a command that doesn't
| output a newline and the next prompt becomes messed up when you
| use line editing commands.
|
| Its not clear what the solution would be. My pet solution would
| be to have a control character that is only a newline if the
| previous character was not a newline, which you could put un
| $PROMPT
| scintill76 wrote:
| I believe fish shell solves this by inserting a visible "[?]"
| character at the end of the line and moving to the beginning of
| the next line for the prompt.
| hiAndrewQuinn wrote:
| One of the highest ROI things I ever did was just write a few
| bash scripts which can be run out of the box on a fresh copy of
| Ubuntu, and set me up with everything I want there to be. [1]
|
| As a result, most of the non-memory issues listed here are things
| I solved once in those scripts and rarely have to think about
| again. Most of the simple memory issues can be solved by running
| `cheat x` and/or `tldr x`, where x = the program I'm struggling
| to remember the basic usecase of, both installed by those scripts
| of course. Most of the more obscure memory issues I can deal with
| with either ChatGPT or Anki these days.
|
| I originally considered writing my scripts as a `host: localhost`
| Ansible playbook instead, but then I remembered that whatever I
| might gain in idempotency I would lose tenfold in hackability. I
| am guaranteed to be doing shell for the rest of my life; I am
| decidedly not guaranteed to be doing Ansible, or any other config
| management tool for that matter.
|
| [1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
| lifefeed wrote:
| I did the same. I have a little dotfiles repo[0] on github that
| I clone on a new machine, then I execute a setup.sh file that
| installs a messy set of aliases and functions to set up my cozy
| unix world.
|
| [0]: https://github.com/jmcguire/dotfiles
| hiAndrewQuinn wrote:
| I always enjoy seeing people still using Perl out in the
| wild. Lynx, too. I use chezmoi for dotfiles management myself
| but honestly it's kind of overkill, I should probably just
| start tracking ~ like this.
| jeffbee wrote:
| This is a mishmash of things people don't like about keyboards,
| windowing systems, terminals, shells, and unix CLIs. All of which
| are completely valid, of course, but it's a mix. I would say my
| biggest issue is discoverability. Many of the tools I use daily
| are ones that I wish I knew earlier. This holds for both newer
| tools, such as "rush", and ancient ones, like "paste".
| thesurlydev wrote:
| Shout out to atuin [1] which helps a lot with the "remembering
| syntax" problem especially if you're using several different
| commands over and over.
|
| [1] https://atuin.sh/
| lucb1e wrote:
| Saving others a click: it syncs terminal history between
| systems
|
| How does this help to memorize syntax if you repeatedly use the
| same commands?
| shawabawa3 wrote:
| Has better search for history so you can find the arguments
| you used last time so you don't have to remember
|
| Also the fact it syncs between machines means even if the
| last time you used that command was on your old laptop 2
| years ago ctrl+r still finds it
| yonatan8070 wrote:
| Besides history sync, I'm pretty sure fish does all the same
| things
| enriquto wrote:
| All these complains about "shortuts for copy-paste" are so
| confusing...
|
| COPY: select text with the mouse
|
| PASTE: middle click
|
| don't people use that? No need for the keyboard at all! It works
| across all programs since forever (except inside jupyter
| notebooks on firefox, for some weird reason).
|
| If I had to single out a unique feature that makes linux
| worthwhile (as compared to windows or macos) it would be that
| one! Way ahead of anything else.
| samspot wrote:
| What if you can't use the mouse?
| indigo945 wrote:
| This does not work in a vertically split window inside a tmux
| session, for example. (Same with split buffers in vim, and so
| on.)
| deathanatos wrote:
| ... selection absolutely does work with a vertically split
| vim?
|
| If the desired selection is large and spans multiple lines,
| yeah, you're going to have a bad time doing it via the
| terminal emulator (but that has little to do with the split,
| other than splits make it more likely to wrap), but you can
| then just fall back asking vim to copy it to the selection.
|
| (This _does_ get back at the complaint in TFA, though, that
| they 're not the same, the moment we have to switch from the
| terminal to vim's command.)
|
| (All of this probably applies directly to tmux too, but I
| don't use tmux.)
| Henchman21 wrote:
| Selecting text with a mouse inside a tmux session absolutely
| honors splits so long as mouse support is enabled.
| WD-42 wrote:
| I think it was more common until Apple normalized the one
| button mouse.
| jimmaswell wrote:
| Where is that the case? Middle click copies the selection and
| right click pastes on every terminal emulator I use.
| h3half wrote:
| I don't know the details for I am but a simple engineer. But
| using a government RHEL system a couple years ago, middle
| clock universally pasted whatever I had highlighted with the
| cursor. Didn't matter what program I was copying into or out
| of.
|
| I mostly used this to copy paste from a terminal into a COTS
| GUI tool, or from that tool into the OpenOffice (or maybe
| LibreOffice, I don't recall) spreadsheet program whatever
| that's called.
|
| Honestly it was incredibly useful and probably saved me
| collective hours over the few years I worked there
|
| Obviously this thread is about terminals, but the
| functionality does exist in some places
| tedunangst wrote:
| All terminals are judged by how far they stray from xterm's
| light.
| Sharlin wrote:
| Middle click to paste the most recently selected text is how
| the PRIMARY selection works in X Window [0], it's not
| specific to terminals.
|
| What terminals have middle-click-to-copy, right-click-to-
| paste? Sounds alien to me.
|
| [0]
| https://en.wikipedia.org/wiki/X_Window_selection#Clipboard
| dare944 wrote:
| I think these same core frustrations have been voiced literally
| for decades, and certainly since the birth of the Unix and what
| evolved to be the modern shell (Ritchie's /bin/sh). As an
| example, the frustrations I experience when moving between modern
| MacOS and Linux/GNU command lines exactly mirrors that of
| switching between System V and BSD Unix back in the 80s. I
| distinctly remember how annoyed I was at having to relearn even
| basic commands when forced to move between my primary development
| machine (a VAX running 4.3Tahoe) and the target machine for a new
| product (a 386 running an early version of Xenix). Eventually GNU
| came along to hide many of the incompatibilities, but it still
| represented yet a third set of command-line patterns for me to
| understand/remember. Similarly, I remember the differences in
| keybindings between my VT-220 compatible terminal and the PC
| keyboard on my 386 as frustrating as hell.
|
| These frustrations seem inevitable given the diversity of systems
| people need to interact with. But I think a lot of them could be
| eased with better help systems; in particular, with help systems
| that focus on learning by example rather than enumerating an
| exhaustive list of features (like most current man pages). AI
| clearly has a role to play here, but most tools I've seen seem
| focused on simply providing the answer rather than building
| proficiency in the user.
| MyOutfitIsVague wrote:
| > help systems that focus on learning by example rather than
| enumerating an exhaustive list of features (like most current
| man pages)
|
| I almost always prefer exhaustive lists of features. Examples
| don't really teach you what each flag being used does, so you
| end up just memorizing combinations of flags without knowing
| what they actually do. I suspect learning solely by example is
| exactly why so many people have a ton of trouble learning how
| to use tools like tar, and the common refrain of "I have to
| look it up every single time".
|
| Examples are useful, but not sufficient on their own for
| learning.
| adelpozo wrote:
| I think I remember swyx had compiled some thoughts on CLIs:
| https://github.com/swyxio/cli-cheatsheet. I particularly liked
| this part, where it starts by collecting examples of CLI apps
| like by the the authors: https://clig.dev/#the-basics.
|
| Beyond that, I am enjoying a little bit too much customizing
| Fish, bobthefish, FZF, and replacements for established CLI apps
| (e.g., find/fd). I spend too much time asking Claude how to do
| various things. And I am the happiest with my current setup--
| until I have to SSH into the barren lands of a production host.
| Fnoord wrote:
| Can I just say I loved reading the comments here. Some great
| suggestions!
|
| > keyboard shortcuts for tmux, text editing, etc
|
| tmux -> zellij has good discoverability of shortcuts. Since
| written in Rust, it can be installed with cargo
|
| For vi, I don't have an alternative, the first thing I do on a
| machine without vi is get neovim, or vim, or vi. I mean, I don't
| know how good emacs is these days, and nano is limited but back
| when I started to use pico (which nano is a successor for) it had
| good discoverability.
|
| My very first text UI editor was a DOS text editor called Q&A.
| All the F-keys were mentioned on the bottom. But once you know
| them, that information becomes redundant. Especially on a low
| resolution. So nowadays, given we hardly ever use 80x24 anymore,
| yet stuff looks good on high resolution (due to good DPI) it is
| only a minor sacrifice.
___________________________________________________________________
(page generated 2025-02-10 23:00 UTC)