Some terminal frustrations

https://jvns.ca/blog/2025/02/05/some-terminal-frustrations/

by aragilar • 1 year ago

273 311 1 year ago

gregjor7• 1 year ago

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_• 1 year ago

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.

skydhash4• 1 year ago

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.

gregjor7• 1 year ago

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.

eviks6• 1 year ago

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

gregjor7• 1 year ago

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.

follower3• 1 year ago

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"

gregjor7• 1 year ago

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.

spudlyo2• 1 year ago

A good catalog of mostly skills issues.

It's a good reminder to some of us that we are not in fact imposters.

atoav4• 1 year ago

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.

skydhash4• 1 year ago

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.

atoav4• 1 year ago

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.

fragmede6• 1 year ago

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.

ninkendo3• 1 year ago

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.

eviks6• 1 year ago

Wait, what do you mean not fixable when you can just change the keybind in the terminal app to use ctrl-c to copy?

p0w3n3d3• 1 year ago

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 )

mixmastamyk2• 1 year ago

You can edit text, at the prompt. Afterwards output is readonly and copyable. Doesn’t make much sense another way.

atoav4• 1 year ago

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.

Ferret74463• 1 year ago

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).

atoav4• 1 year ago

Those are two instances of text that should not be editable.

crabbone7• 1 year ago

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.

rcarmo2• 1 year ago

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

tonymet9• 1 year ago

Is this a bot?

fragmede6• 1 year ago

does it matter if it is?

rcarmo2• 1 year ago

Nope. Just someone who also submitted this earlier as well. I think HN’s dupe detection is off these days.

slightwinder3• 1 year ago

Detector seems a bit off when it also includes the item-id where it's posting.

tonymet9• 1 year ago

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• 1 year ago

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• 1 year ago

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.

kristopolous6• 1 year ago

second this. huge game changer. should be default.

lloeki6• 1 year ago

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

hiAndrewQuinn3• 1 year ago

`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• 1 year ago

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.

UltraSane5• 1 year ago

"Most of the legacy cruft, it would be great to have a green field implementation of the CLI interface."

This is very true.

tonymet9• 1 year ago

Check out powershell

UltraSane5• 1 year ago

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.

crabbone7• 1 year ago

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.

notsomeuser• 1 year ago

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...

Ferret74463• 1 year ago

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.

wpm2• 1 year ago

I couldn’t disagree more.

GoblinSlayer2• 1 year ago

TempleOS

oliviergg• 1 year ago

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• 1 year ago

Same

laktak• 1 year ago

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• 1 year ago

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• 1 year ago

(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

terminaltrove2• 1 year ago

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/

armanckeser2• 1 year ago

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

terminaltrove2• 1 year ago

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?

zxexz• 1 year ago

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!

quotemstr3• 1 year ago

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.

Ferret74463• 1 year ago

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.

zokier3• 1 year ago

In what universe is terminfo "foundational knowledge"

navi-desu• 1 year ago

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.

quotemstr3• 1 year ago

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.

spudlyo2• 1 year ago

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

kps2• 1 year ago

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.

kristopolous6• 1 year ago

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.

regnull3• 1 year ago

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

kristopolous6• 1 year ago

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.

scottyeager• 1 year ago

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• 1 year ago

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• 1 year ago

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

exmadscientist3• 1 year ago

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.

xboxnolifes2• 1 year ago

--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.

exmadscientist3• 1 year ago

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.

GoblinSlayer2• 1 year ago

--help isn't even the lowest common denominator. An incorrect argument list is.

--help being an incorrect argument does the right thing, yes.

crabbone7• 1 year ago

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).

pgwhalen2• 1 year ago

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• 1 year ago

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.

lucb1e2• 1 year ago

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

Arnavion3• 1 year ago

`--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• 1 year ago

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).

kps2• 1 year ago

`--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• 1 year ago

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.

f1shy4• 1 year ago

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• 1 year ago

Or database clients (e.g. psql) using `-h` for the host argument. I get it, but I don't like it.

viraptor• 1 year ago

-H is right there and available. But they chose to be slightly weird...

kccqzy• 1 year ago

On macOS the shutdown command uses `-h` to mean halt, i.e. an actual shutdown.

swiftcoder3• 1 year ago

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

ithkuil2• 1 year ago

It's probably fuzzy similarity search

idle_zealot• 1 year ago

Is it? It is helping you. Your first tip: here's what the argument syntax looks like, use it.

AStonesThrow4• 1 year ago

sorry, you've typed "[em][en]h[Cyrillic]lp", try again

toast02• 1 year ago

Likely they print that message for any unknown argument.

ljm• 1 year ago

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.

oxidant2• 1 year ago

`find` comes to mind. I consistently need to look up the syntax.

tdeck• 1 year ago

A lot of Java tools do this for some reason and I hate it.

kevin_thibedeau3• 1 year ago

Double dash for long args is a GNUism. One which even they don't adhere to uniformly as evidenced by GCC's options.

plagiarist• 1 year ago

This sets me off. Whenever I have any viable alternative to a single dash long arg tool I take the alternative.

somat2• 1 year ago

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

danudey7• 1 year ago

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.

scbrg4• 1 year ago

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).

exmadscientist3• 1 year ago

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.

blueflow6• 1 year ago

Its not "$command --help", its "man 1 $command". You should not invoke programs blindly, hoping "--help" causes them to do nothing else.

tenacious_tuna2• 1 year ago

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.

scubbo3• 1 year ago

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.

f1shy4• 1 year ago

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-423• 1 year ago

Agreed, but to be fair some of that comes from fuzzy searching the available parameters for close matches. Which is normally helpful.

nurumaik• 1 year ago

Just print help instead of any error during parsing

chasil• 1 year ago

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."

blueflow6• 1 year ago

And POSIX has man(1) instead of --help: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m...

danudey7• 1 year ago

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• 1 year ago

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• 1 year ago

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.

xk3• 1 year ago

sounds like Pharo

gossamer• 1 year ago

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• 1 year ago

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• 1 year ago

For categorising feedback like this, a card sorting exercise can work well, and then move go a spreadsheet.

oneeyedpigeon2• 1 year ago

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.

slightwinder3• 1 year ago

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.

oneeyedpigeon2• 1 year ago

  > $ 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: -?

gregjor7• 1 year ago

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

p0w3n3d3• 1 year ago

Am I the only one to whom the term _terminal frustrations_ sounds like things that frustrate you and then you die?

AStonesThrow4• 1 year ago

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

tonyedgecombe• 1 year ago

It's likely correct because I doubt these frustrations will be solved in our lifetimes.

maleldil4• 1 year ago

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

gkfasdfasdf2• 1 year ago

Thanks for the tip, another awesome tool from sharkdp.

efitz• 1 year ago

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.

xerox13ster2• 1 year ago

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.

zokier3• 1 year ago

https://learn.microsoft.com/en-us/powershell/scripting/insta...

jcranmer• 1 year ago

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.

Reasoning2• 1 year ago

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.

gregjor7• 1 year ago

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• 1 year ago

'I built a tool' no you didn't, you wrote a program. Stop larping

crabbone7• 1 year ago

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• 1 year ago

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• 1 year ago

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_clone2• 1 year ago

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• 1 year ago

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• 1 year ago

Are you backing up your command history?

reddit_clone2• 1 year ago

No. But I copy it over when I setup a new computer.

jillesvangurp• 1 year ago

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.

jimmaswell3• 1 year ago

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• 1 year ago

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.

knazarov2• 1 year ago

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• 1 year ago

Then how do you SIGINT?

mook• 1 year ago

What they're saying in Linux terms is that they map Super+C to Ctrl+Insert, so Ctrl+C still sends SIGINT.

pcthrowaway• 1 year ago

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.

einsteinx2• 1 year ago

I don't remember if I did any special config in iTerm or installed a nonstandard package (I don't believe I did)

You are remembering correctly, pbcopy (and it’s partner pbpaste) are preinstalled on all Macs as part of the OS.

monroewalker• 1 year ago

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• 1 year ago

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.

gkfasdfasdf2• 1 year ago

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...

jeffbee2• 1 year ago

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• 1 year ago

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• 1 year ago

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.

bawolff2• 1 year ago

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• 1 year ago

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.

db48x• 1 year ago

    if [[ "${TERM}" != "dumb" ]] || [[ $- == *i* ]]; then
        PROMPT_COMMAND='printf "⏎%$((COLUMNS-1))s\\r"'$'\n'"$PROMPT_COMMAND"
    fi

bawolff2• 1 year ago

Thanks! This has been life changing for me.

hiAndrewQuinn3• 1 year ago

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

lifefeed2• 1 year ago

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

hiAndrewQuinn3• 1 year ago

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.

jeffbee2• 1 year ago

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• 1 year ago

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/

lucb1e2• 1 year ago

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• 1 year ago

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• 1 year ago

Besides history sync, I'm pretty sure fish does all the same things

enriquto4• 1 year ago

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• 1 year ago

What if you can't use the mouse?

indigo945• 1 year ago

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• 1 year ago

… 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• 1 year ago

Selecting text with a mouse inside a tmux session absolutely honors splits so long as mouse support is enabled.

WD-423• 1 year ago

I think it was more common until Apple normalized the one button mouse.

jimmaswell3• 1 year ago

Where is that the case? Middle click copies the selection and right click pastes on every terminal emulator I use.

h3half• 1 year ago

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• 1 year ago

All terminals are judged by how far they stray from xterm's light.

Sharlin2• 1 year ago

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• 1 year ago

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• 1 year ago

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• 1 year ago

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• 1 year ago

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.

xp842• 1 year ago

In the "which keyboard shortcuts do you use" section I was sad that Ctrl-D was labeled just as "EOF" when i'd suggest "Disconnect" is just as important. Pressing ^D to close a shell, including say, a shell in a container, an SSH session, or just to end the whole terminal session, is my favorite keyboard shortcut and I'm always surprised to see people typing out "exit" and pressing Return.

Hopefully one person sees this and saves thousands of keystrokes over the next few decades ;)

teknopaul2• 1 year ago

RTFM. I have never met a shell user who has read `man bash` from top to bottom. It's not a hard document to read if you have been using bash for a while. People read bits of it, as you do with other man pages, and get frustrated navigating it. But man bash should be read top to bottom with intent to understand it before complaining about it. It should be given the same attention to details that you give any programming language, not any gui tool (that you can exct to be intuitive) bash is a very powerful language and deserves 1 hour of you time to read the man. It you want to write good scripts

Read Google bash coding guidelines.

Try to write shells scripts that don't fork. That approach really helped me write resilient scripts.

Use

x=`${...}`. Instead of

echo |...

Then you bash starts to improve every day, instead of accepting mediocre all your life.%

I have given the above lesson to a few folk who suddenly found bash fun and a highly productive programming language.

Like all languages get it working first, make it testable and refactor until it's good.

With bash that whole process can take 5 mins for a simple script: and scripts should only be simple

teknopaul2• 1 year ago

P.S. dont blame bash for sed. Once you grok bash, other tools make more sense. If you don't understand bashes escaping rules and options

echo x | sed "..."

Is doubly confusing.

darcwader• 1 year ago

is it possible in linux to map copy to WIN+C and paste to WIN+V. universally across entire X system. but not Ctrl+C sending, like in terminal if i press Win+C it should not send close signal.

Some terminal frustrations

Related Stories