18 ms·

Some terminal frustrations

273 points by aragilar 2y ago

gregjor 2y 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.
- eviks 2y 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
  - gregjor 2y 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.
- Analemma_ 2y 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.
  - skydhash 2y 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.
    - fragmede 2y ago
      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 2y ago
        > 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.
- follower 2y 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"
  - gregjor 2y 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.
    - follower 2y ago
      > 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 2y ago
  > A good catalog of mostly skills issues. It's a good reminder to some of us that we are not in fact imposters.
rcarmo 2y ago
Previously: https://news.ycombinator.com/item?id=42970632 https://news.ycombinator.com/item?id=42970632 https://news.ycombinator.com/item?id=42975816 https://news.ycombinator.com/item?id=42975816 https://news.ycombinator.com/item?id=42959824 https://news.ycombinator.com/item?id=42959824 https://news.ycombinator.com/item?id=42953869 https://news.ycombinator.com/item?id=42953869
- tonymet 2y ago
  Is this a bot?
  - fragmede 2y ago
    does it matter if it is?
    - wutwutwat 2y ago
      It matters to the person above, which would be why they asked the question. That's generally how question asking goes...
    - tonymet 2y ago
      Isn’t this the forum for the technically curious? So yes, it matters.
      - fragmede 2y ago
        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?
atoav 2y 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.
- skydhash 2y 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.
  - atoav 2y 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.
    - scbrg 2y ago
      You... can? Perhaps I misunderstand you, but doesn't readline solve this problem?
- fragmede 2y 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.
- ninkendo 2y 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.
tonymet 2y 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 2y 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 2y 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.
  - kristopolous 2y ago
    second this. huge game changer. should be default.
  - lloeki 2y 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
kalaksi 2y 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 https://github.com/kalaksi/lightkeeper). Works over SSH, requires no daemons and is configurable. Still working on some unfinished features.
UltraSane 2y ago
"Most of the legacy cruft, it would be great to have a green field implementation of the CLI interface." This is very true.
- tonymet 2y ago
  Check out powershell
  - UltraSane 2y 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.
    - quotemstr 2y ago
      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 2y ago
      it deserves more advocacy
  - crabbone 2y 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.
oliviergg 2y 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 2y ago
  Same
- laktak 2y ago
  I find the history much too unorganized to be useful. That's why I made playbooks https://github.com/laktak/tome https://github.com/laktak/tome ymmv but I prefer this to searching.
- pridkett 2y 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 2y 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
terminaltrove 2y 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/ https://terminaltrove.com/
- armanckeser 2y 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
  - terminaltrove 2y ago
    Thanks for the feedback, We have categorization here: https://terminaltrove.com/categories/ 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 2y ago
      > 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 2y ago
      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.
quotemstr 2y 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 https://github.com/prompt-toolkit/python-prompt-toolkit), * chalk (https://github.com/chalk/chalk https://github.com/chalk/chalk), * linenose (https://github.com/antirez/linenoise 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 2y 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.
kristopolous 2y 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 https://github.com/simonw/llm) + openrouter (https://github.com/simonw/llm-openrouter https://github.com/simonw/llm-openrouter) + free models (https://openrouter.ai/models?max_price=0 https://openrouter.ai/models?max_price=0) + glow (https://github.com/charmbracelet/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 https://github.com/laktak/extrakto * mcfly history: https://github.com/cantino/mcfly https://github.com/cantino/mcfly just watch the demo, you'll see * ugrep: grep with a powerful tui: https://github.com/Genivia/ugrep https://github.com/Genivia/ugrep - I became an instant convert. * batcat: https://github.com/sharkdp/bat https://github.com/sharkdp/bat ... you really need to use some of its other features to leverage it. It's really nice.
- regnull 2y 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 https://github.com/regnull/how.sh
  - kristopolous 2y ago
    I see you did some prompt engineering: https://github.com/regnull/how.sh/blob/main/how.sh 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.
__s 2y ago
For colorsheme allow me to suggest https://github.com/savq/melange-nvim 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 2y 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.
- xboxnolifes 2y 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.
  - exmadscientist 2y 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.
    - dfox 2y ago
      -? 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 2y ago
        `?` 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).
deleted 2y ago
[deleted]
ggm 2y 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 2y 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 2y ago
  sounds like Pharo
gossamer 2y 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 2y 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 2y ago
For categorising feedback like this, a card sorting exercise can work well, and then move go a spreadsheet.
oneeyedpigeon 2y 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.
- slightwinder 2y 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.
  - oneeyedpigeon 2y 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: -?
    - achierius 2y ago
      If you have brew you can install findutils to get gfind which behaves more like you'd expect
    - slightwinder 2y ago
      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 2y 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
p0w3n3d 2y ago
Am I the only one to whom the term _terminal frustrations_ sounds like things that frustrate you and then you die?
- AStonesThrow 2y 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 2y ago
  It's likely correct because I doubt these frustrations will be solved in our lifetimes.
maleldil 2y 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 https://github.com/sharkdp/vivid
- gkfasdfasdf 2y ago
  Thanks for the tip, another awesome tool from sharkdp.
efitz 2y 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.
- xerox13ster 2y 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.
matthewmorgan 2y ago
'I built a tool' no you didn't, you wrote a program. Stop larping
crabbone 2y 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 2y 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 2y 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_clone 2y 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 2y 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 2y ago
  Are you backing up your command history?
  - reddit_clone 2y ago
    No. But I copy it over when I setup a new computer.
jillesvangurp 2y 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.
- jimmaswell 2y 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 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 2y ago
Do you know any nice copilots working in the terminal? "remembering exact commands" (vide https://xkcd.com/1168/ https://xkcd.com/1168/) and "getting context for a given instruction" are precisely things at which LLMs excel.
knazarov 2y 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 2y ago
  Then how do you SIGINT?
  - mook 2y ago
    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 https://en.m.wikipedia.org/wiki/IBM_Common_User_Access
    - knazarov 2y ago
      Right. Ctrl+C is still mapped as usual.
- pcthrowaway 2y 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 2y 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 2y 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 2y 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.
gkfasdfasdf 2y 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 https://llm.datasette.io [1] - https://docs.github.com/en/copilot/using-github-copilot/using-github-copilot-in-the-command-line https://docs.github.com/en/copilot/using-github-copilot/usin...
- jeffbee 2y 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 2y 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 2y 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.
bawolff 2y 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 2y 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 2y ago
  if [[ "${TERM}" != "dumb" ]] || [[ $- == *i* ]]; then PROMPT_COMMAND='printf "⏎%$((COLUMNS-1))s\\r"'$'\n'"$PROMPT_COMMAND" fi
  - bawolff 2y ago
    Thanks! This has been life changing for me.
hiAndrewQuinn 2y 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 https://github.com/hiAndrewQuinn/shell-bling-ubuntu
- lifefeed 2y 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 https://github.com/jmcguire/dotfiles
  - hiAndrewQuinn 2y 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.
    - lifefeed 2y ago
      I've tried a few dotfile management tools, and yeah they're always overkill. Plus it's one more dependency to handle when I'm setting up a new environment.
jeffbee 2y 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 2y 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/ https://atuin.sh/
- lucb1e 2y 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 2y 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
  - deleted 2y ago
    [deleted]
  - yonatan8070 2y ago
    Besides history sync, I'm pretty sure fish does all the same things
enriquto 2y 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.
- indigo945 2y 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 2y 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 2y ago
    Selecting text with a mouse inside a tmux session absolutely honors splits so long as mouse support is enabled.
- samspot 2y ago
  What if you can't use the mouse?
- WD-42 2y ago
  I think it was more common until Apple normalized the one button mouse.
- 2y ago
dare944 2y 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 2y 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 2y ago
I think I remember swyx had compiled some thoughts on CLIs: https://github.com/swyxio/cli-cheatsheet 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 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 2y 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.
xp84 2y 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 ;)
teknopaul 2y 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
- teknopaul 2y 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 2y 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.

273 points by aragilar 2y 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.

eviks 2y 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
- gregjor 2y 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.
Analemma_ 2y 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.
- skydhash 2y 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.
  - fragmede 2y ago
    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 2y ago
      > 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.
follower 2y 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"
- gregjor 2y 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.
  - follower 2y ago
    > 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 2y ago
> A good catalog of mostly skills issues. It's a good reminder to some of us that we are not in fact imposters.

rcarmo 2y ago

Previously: https://news.ycombinator.com/item?id=42970632 https://news.ycombinator.com/item?id=42970632 https://news.ycombinator.com/item?id=42975816 https://news.ycombinator.com/item?id=42975816 https://news.ycombinator.com/item?id=42959824 https://news.ycombinator.com/item?id=42959824 https://news.ycombinator.com/item?id=42953869 https://news.ycombinator.com/item?id=42953869

tonymet 2y ago
Is this a bot?
- fragmede 2y ago
  does it matter if it is?
  - wutwutwat 2y ago
    It matters to the person above, which would be why they asked the question. That's generally how question asking goes...
  - tonymet 2y ago
    Isn’t this the forum for the technically curious? So yes, it matters.
    - fragmede 2y ago
      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?

atoav 2y 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.

skydhash 2y 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.
- atoav 2y 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.
  - scbrg 2y ago
    You... can? Perhaps I misunderstand you, but doesn't readline solve this problem?
fragmede 2y 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.
ninkendo 2y 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.

tonymet 2y 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 2y 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 2y 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.
- kristopolous 2y ago
  second this. huge game changer. should be default.
- lloeki 2y 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

kalaksi 2y 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 https://github.com/kalaksi/lightkeeper). Works over SSH, requires no daemons and is configurable. Still working on some unfinished features.

UltraSane 2y ago

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

tonymet 2y ago
Check out powershell
- UltraSane 2y 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.
  - quotemstr 2y ago
    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 2y ago
    it deserves more advocacy
- crabbone 2y 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.

oliviergg 2y 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 2y ago
Same
laktak 2y ago
I find the history much too unorganized to be useful. That's why I made playbooks https://github.com/laktak/tome https://github.com/laktak/tome ymmv but I prefer this to searching.
pridkett 2y 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 2y 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

terminaltrove 2y 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/ https://terminaltrove.com/

armanckeser 2y 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
- terminaltrove 2y ago
  Thanks for the feedback, We have categorization here: https://terminaltrove.com/categories/ 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 2y ago
    > 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 2y ago
    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.

quotemstr 2y 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 https://github.com/prompt-toolkit/python-prompt-toolkit), * chalk (https://github.com/chalk/chalk https://github.com/chalk/chalk), * linenose (https://github.com/antirez/linenoise 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 2y 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.

kristopolous 2y 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 https://github.com/simonw/llm) + openrouter (https://github.com/simonw/llm-openrouter https://github.com/simonw/llm-openrouter) + free models (https://openrouter.ai/models?max_price=0 https://openrouter.ai/models?max_price=0) + glow (https://github.com/charmbracelet/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 https://github.com/laktak/extrakto * mcfly history: https://github.com/cantino/mcfly https://github.com/cantino/mcfly just watch the demo, you'll see * ugrep: grep with a powerful tui: https://github.com/Genivia/ugrep https://github.com/Genivia/ugrep - I became an instant convert. * batcat: https://github.com/sharkdp/bat https://github.com/sharkdp/bat ... you really need to use some of its other features to leverage it. It's really nice.

regnull 2y 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 https://github.com/regnull/how.sh
- kristopolous 2y ago
  I see you did some prompt engineering: https://github.com/regnull/how.sh/blob/main/how.sh 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.

__s 2y ago

For colorsheme allow me to suggest https://github.com/savq/melange-nvim 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 2y 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.

xboxnolifes 2y 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.
- exmadscientist 2y 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.
  - dfox 2y ago
    -? 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 2y ago
      `?` 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).

deleted 2y ago

[deleted]

ggm 2y 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 2y 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 2y ago
sounds like Pharo

gossamer 2y 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 2y 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 2y ago

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

oneeyedpigeon 2y 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.

slightwinder 2y 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.
- oneeyedpigeon 2y 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: -?
  - achierius 2y ago
    If you have brew you can install findutils to get gfind which behaves more like you'd expect
  - slightwinder 2y ago
    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 2y 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

p0w3n3d 2y ago

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

AStonesThrow 2y 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 2y ago
It's likely correct because I doubt these frustrations will be solved in our lifetimes.

maleldil 2y 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 https://github.com/sharkdp/vivid

gkfasdfasdf 2y ago
Thanks for the tip, another awesome tool from sharkdp.

efitz 2y 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.

xerox13ster 2y 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.

matthewmorgan 2y ago

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

crabbone 2y 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 2y 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 2y 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_clone 2y 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 2y 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 2y ago
Are you backing up your command history?
- reddit_clone 2y ago
  No. But I copy it over when I setup a new computer.

jillesvangurp 2y 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.

jimmaswell 2y 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 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 2y ago

Do you know any nice copilots working in the terminal? "remembering exact commands" (vide https://xkcd.com/1168/ https://xkcd.com/1168/) and "getting context for a given instruction" are precisely things at which LLMs excel.

knazarov 2y 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 2y ago
Then how do you SIGINT?
- mook 2y ago
  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 https://en.m.wikipedia.org/wiki/IBM_Common_User_Access
  - knazarov 2y ago
    Right. Ctrl+C is still mapped as usual.
pcthrowaway 2y 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 2y 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 2y 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 2y 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.

gkfasdfasdf 2y 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 https://llm.datasette.io [1] - https://docs.github.com/en/copilot/using-github-copilot/using-github-copilot-in-the-command-line https://docs.github.com/en/copilot/using-github-copilot/usin...

jeffbee 2y 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 2y 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 2y 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.

bawolff 2y 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 2y 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 2y ago
if [[ "${TERM}" != "dumb" ]] || [[ $- == *i* ]]; then PROMPT_COMMAND='printf "⏎%$((COLUMNS-1))s\\r"'$'\n'"$PROMPT_COMMAND" fi
- bawolff 2y ago
  Thanks! This has been life changing for me.

hiAndrewQuinn 2y 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 https://github.com/hiAndrewQuinn/shell-bling-ubuntu

lifefeed 2y 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 https://github.com/jmcguire/dotfiles
- hiAndrewQuinn 2y 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.
  - lifefeed 2y ago
    I've tried a few dotfile management tools, and yeah they're always overkill. Plus it's one more dependency to handle when I'm setting up a new environment.

jeffbee 2y 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 2y 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/ https://atuin.sh/

lucb1e 2y 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 2y 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
- deleted 2y ago
  [deleted]
- yonatan8070 2y ago
  Besides history sync, I'm pretty sure fish does all the same things

enriquto 2y 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.

indigo945 2y 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 2y 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 2y ago
  Selecting text with a mouse inside a tmux session absolutely honors splits so long as mouse support is enabled.
samspot 2y ago
What if you can't use the mouse?
WD-42 2y ago
I think it was more common until Apple normalized the one button mouse.
2y ago

dare944 2y 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 2y 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 2y ago

I think I remember swyx had compiled some thoughts on CLIs: https://github.com/swyxio/cli-cheatsheet 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 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 2y 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.

xp84 2y 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 ;)

teknopaul 2y 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

teknopaul 2y 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 2y 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.