[HN Gopher] Entering text in the terminal is complicated
___________________________________________________________________
Entering text in the terminal is complicated
Author : todsacerdoti
Score : 158 points
Date : 2024-07-08 17:52 UTC (5 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| glial wrote:
| Nice to see this writeup. Entering text into the terminal, and
| copying output out, is a huge barrier to entry for beginners.
| Windows terminals in particular feel downright antagonistic to
| use.
| onehair wrote:
| cmd.exe or the new https://github.com/microsoft/terminal ?
| glial wrote:
| I haven't used the new one! Will check it out, thanks.
| kapitanjakc wrote:
| For me, Ubuntu's terminal is perfect.
|
| Give me arrows, tab, Ctrl+(R/C/D/W) etc and its a great.
|
| But I agree with the point that different systems have their own
| implementation which could lead to frustration.
|
| I am working on set of servers only accessible through PAM and
| those admins don't allow anything. It gets so frustrating.
|
| I feel a lot of the frustration also comes from shifting to
| unfamiliar environment. Like I work on those restricted servers
| and am cursing the admins, but when I switch to Ubuntu's terminal
| I am thanking the gods for liberation.
| frankus wrote:
| Periodic reminder that many emacs-like keybindings exist in
| almost every text field in macOS: Ctrl A, E, P, N, K, Y, T, and
| probably others I'm forgetting (start of line, end of line,
| previous line, next line, kill (delete everything to the end of
| the line and put it in a special pasteboard), yank (paste from
| that special pasteboard) and transpose characters).
|
| Edit: more complete list here: https://jblevins.org/log/kbd
|
| Edit 2: can't believe I forgot Ctrl-D, which is forward delete.
| squigz wrote:
| It took the author _15 years_ to learn basic readline commands?
| asciimov wrote:
| Terminal feature discovery is hard. If you don't regularly use
| the commands it's easy to forget they exist.
| eequah9L wrote:
| Yeah, I have my doubts about the claim. I forgot what I read
| way back when as an intro book, but I suspect it was more like
| a month in my case, if that. But I remember having been
| surprised at various points that there was an undo (C-_), and a
| clipboard (C-y to paste) including a history (M-y). So yeah, I
| guess it depends on the scope.
|
| Maybe it's a hyperbole? Dunno, doesn't really read that way.
| 0cf8612b2e1e wrote:
| How can you discover something on the terminal itself? You
| fall into a pattern and stick with it. It is only if you get
| out of band information that you can learn these tricks.
| squigz wrote:
| Bit confused by this comment. I don't think anybody
| suggested you're going to find these things solely by
| interacting with the terminal - but rather through "out of
| band information" as you put it, which in GP's case, as he
| said, was a book. The surprising part of TFA, and replies
| to my comment - to me anyway - is how one can go so many
| years without picking up that information.
| 0cf8612b2e1e wrote:
| I have never read a book about improving my terminal
| knowledge. I have a few tricks I have picked up over time
| (probably through posts like this!), but never done
| holistic research on the subject. Therefore, despite
| having used the terminal for decades, I likely have a
| similarly long list of basic terminal knowledge gaps. I
| do not know what I do not know.
| tobinfekkes wrote:
| I've been using terminal for +15 years, and I just learned what
| this is. Because you highlighted it being crazy that someone
| didn't know what it was, I looked it up.
|
| Neat! Thanks for teaching me something today. This will be
| helpful, especially after I spent all morning messing with
| crontabs and logs and permissions and PATH env's.
|
| Edit: Having read more about this now, I'm realizing that I do
| use a couple of these out of habit. I just didn't know they
| were called "readline commands". I thought they were just "how
| to use the terminal". But there's dozens and dozens of other
| commands I never knew were possible. Brilliant. Happy Monday.
| epidemian wrote:
| I've also been using Linux and the terminal ~15 years, and
| these things i keep forgetting and relearning every now and
| then. About Ctrl+A in particular, it never sticks in my memory,
| since i find typing the Home key to be more intuitive. Maybe
| the author has this same "problem".
|
| It's funny how other programs don't seem to have this issue,
| and their users are able to learn new things without having to
| resort to an external manual. Makes one wonder about the design
| of everyday things!
| asciimov wrote:
| In bash, if you set $EDITOR to your favorite text editor, you can
| send the current line to $EDITOR with ctrl-x ctrl-e. After
| editing the command you can save and exit for the command to
| execute.
| cyberpunk wrote:
| You can also just press 'v' if you're using vi mode in ksh like
| hardened old unixbeards like me :}
| abound wrote:
| And for the fish folk, it's Alt-e
| oalders wrote:
| Or even just bind it to ctrl-e in bash:
|
| bind '\C-e: edit-and-execute-command'
| chasil wrote:
| > some programs (the dash shell, cat, nc, git commit
| --interactive, etc) don't support using arrow keys at all.
|
| The dash shell does in fact support an editing mode if compiled
| with libedit. Debian derivatives do not do so (likely for
| concerns of space). They very much should, as people who start
| with bash will have much to unlearn.
|
| The POSIX standard also specifies "set -o vi" as an optional
| extension. _Every shell claiming POSIX-compatibility must support
| set -o vi_ if the shell implements this editing mode (so ignore
| inputrc if it pleases you).
|
| "[set -o] vi: Allow shell command line editing using the built-in
| vi editor. Enabling vi mode shall disable any other command line
| editing mode provided as an implementation extension."
|
| https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
| hawski wrote:
| I plan to make one day an alternative to terminals. My idea is
| not fully fleshed out, but I would like to try to forgo TTYs
| altogether. Use only pipes, file descriptors and job control.
|
| The closest thing I saw to what I have in mind is this:
| https://github.com/letoram/cat9/ but more in a way of interface.
| hnlmorg wrote:
| I'm working on a similar vision. Except instead of replacing
| the terminal, I'm turning it into a more of an ergonomic
| interface for structured data and multimedia.
|
| I'm open to discussing thoughts on this.
| cxr wrote:
| One thing to start with is to not throw the user into a screen
| consisting of a grid of fixed width character cells at the very
| beginning. This is what immediately sends a signal of
| discomfort to most users not already familiar with terminal
| emulators. There's no real reason why the default experience of
| having a dialog with your system installation couldn't take
| place within an interface that resembles iMessage or ChatGPT or
| something like Quicksilver. Things like /bin/rm certainly don't
| care whether they're being invoked from a terminal emulator
| that has the conventional look or whether it's in a chat-like
| interface--it doesn't rely on any line drawing characters or
| output alignment. Even the Python REPL doesn't depend on that
| sort of thing a great deal, except for stuff like ASCII art
| arrows pointing to syntax errors. Only when you want to use
| stuff like vi or ps and ls helpfully trying to put things into
| columns will you start running into trouble if your terminal
| emulator has an non-traditional UI. This can be ameliorated to
| some degree with heuristics to detect e.g. spaces being used
| for alignment and cursor positioning escape sequences in the
| output stream.
| nine_k wrote:
| Are you talking about terminals, or about shells?
|
| I suppose the latter. Have you checked Oilshell, Elvish, or
| PowerShell (yes, on Windows)?
| Workaccount2 wrote:
| I have continually contented that the terminal is the single
| thing eternally condemning Linux to <5% market penetration.
|
| It's not just entering text. The entire experience is
| complicated. It's a Concorde jet cockpit[1] (with no labels too),
| when 95% of the population just wants to fly their drone
| around[2].
|
| [1]https://qph.cf2.quoracdn.net/main-
| qimg-2566f4c91b894e4169d77... [2]https://media.thedroningcompany.
| com/images/tincy/WQZpC56vqMp...
| squigz wrote:
| 95% of the population doesn't need to use the terminal.
| Waterluvian wrote:
| If you love cars, popping the hood is probably part of the
| experience. For everyone else, it's the sign of a very
| frustrating day ahead.
|
| As computer lovers, I feel we must endeavour to remain
| mindful that almost everyone else aren't like us. They're
| trying to get a task done. They don't want to maintain or
| talk with the computer.
| squigz wrote:
| > As computer lovers, I feel we must endeavour to remain
| mindful that almost everyone else aren't like us. They're
| trying to get a task done. They don't want to maintain or
| talk with the computer.
|
| This was pretty much my point. 95% of the population isn't
| like us, and don't need to interact with the terminal;
| thus, thinking the terminal is what's keeping Linux back
| doesn't make much sense to me
| shadowgovt wrote:
| The larger issue is the times that the Linux UX goes off
| the rails and the solution turns out to be "You're going
| to have to bleat this esoteric incantation at the command
| line." I plugged my laptop into a second monitor the
| other day and, oops, for whatever Godforsaken reason it
| didn't auto-detect. Suddenly I'm munging around in
| `xrandr` to get my screens to work.
|
| To its credit, all the major desktop distributions today
| are making real inroads to narrowing the scope of
| situations where that happens. This was a much larger
| concern in the past, where key aspects of the user
| experience were still in the category "There was a
| command-line tool written to control it and _that 's all
| you'll ever need, dammit_."
| yencabulator wrote:
| The alternative is "it just won't work". You too can live
| in that world by simply not trying to fix it.
|
| My wife's Macbook won't suspend correctly when it's
| plugged into a Dell monitor, the monitor going into power
| save wakes up the laptop. I wish there was an arcane
| incantation that would fix it, but no, the proprietary
| walled garden is well locked up, with glossy user-
| friendly rounded corners everywhere.
| Waterluvian wrote:
| Sorry if I was vague! I was commenting in complete
| agreement with you.
| nine_k wrote:
| Linux the kernel + some userland without terminal is used by
| majority of people in the form of Android and Chromebooks.
|
| A terminal is a developer and sysadmin tool. It just so happens
| that most users of _desktop GNU /Linux_ are developers and
| sysadmins. They are a few percent of population.
| Workaccount2 wrote:
| >Linux the kernel + some userland without terminal is used by
| majority of people in the form of Android and Chromebooks.
|
| Exactly, so why hasn't the open source community driving free
| distros taken note of this?
|
| Now more than ever, people want out of Windows, but the only
| they step into the seat of exit craft and see the above
| cockpit.
| nine_k wrote:
| > _free distros taken note of this?_
|
| Gnome tries hard to emulate Apple's approach. Results are
| mixed, but I've seen fans of it.
|
| Elementary OS goes in the "normal users" direction, too.
|
| OTOH if something goes badly wrong, and you do need to open
| the hood and follow an arcane tech support recipe, you open
| a command line, be it Linux. macOS, or Windows. (Not
| Android or iOS though, where you do a reset + restore
| dance.)
|
| > _people want out of Windows_
|
| Yes, here's where they meet Steam Deck, that _did_ take
| note, and just puts you into a cared-for gaming
| environment. It can also run a typical desktop. The
| hardware is proprietary, but the software is (mostly /
| completely?) free.
| onehair wrote:
| Doesn't Windows, the most popular OS out there, have a cmd.exe
| terminal thing? Why isn't that harming Windows?
|
| The Windows Command Prompt's default experience is worse than
| most if not all terminals you find on Linux systems. Even in
| play TTY, you're bound to find that the shortcuts the author
| mentioned work like a charm.
|
| To make my cmd.exe bearable I am using
| https://chrisant996.github.io/clink
|
| tl;dr You're comparing the choice of wheels on a plane to what
| makes planes sell more.
| delta_p_delta_x wrote:
| > Doesn't Windows, the most popular OS out there, have a
| cmd.exe terminal thing? Why isn't that harming Windows?
|
| That's because the _overwhelming majority_ of Windows usage,
| administration, and programming can be done almost entirely
| without ever touching the command-line, from Explorer.exe,
| Task Manager, Edge, Media Player, Paint, and built-in ZIP
| handling to the huge list of MMC snap-ins[1], and Visual
| Studio 2022.
|
| > tl;dr You're comparing the choice of wheels on a plane to
| what makes planes sell more.
|
| For the record, aeroplane cockpits have _also_ gotten
| considerably simpler in the intervening half-century since
| Concorde and the first 747s. Here is an Airbus A350
| cockpit[2].
|
| [1]: https://serverfault.com/questions/158075/what-are-the-
| names-...
|
| [2]: https://cdn.airplane-pictures.net/images/uploaded-
| images/201...
| squigz wrote:
| > For the record, aeroplane cockpits have also gotten
| considerably simpler in the intervening half-century since
| Concorde and the first 747s. Here is an Airbus A350
| cockpit[2].
|
| I mean, aesthetically it's simpler sure, but the complexity
| is still there; it's just now much more digital.
| adrian_b wrote:
| That does not match my experience, even if I also believed
| that myth.
|
| At one time I had to install Windows Enterprise IoT on
| several kinds of embedded computers, all of which had
| various quirks.
|
| The computers worked fine in Linux, from the first attempt
| to boot it, without the need to do anything special, but a
| customer wanted to have Windows on those.
|
| After installing Windows, there have been a lot of
| problems, for instance Windows was unbelievably slow,
| because the SSD's had a very low writing speed, but they
| could not be replaced with decent SSD's, because the
| embedded computers were certified for certain applications
| only with their original components.
|
| Making Windows usable on those computers has required a
| week of tuning and finding various workarounds by searching
| the Windows Knowledge Base and various Internet Forums,
| where many Windows users had the same complaints as me, but
| few were able to provide good advice about how to solve the
| problems.
|
| I have been astonished to discover that for every
| workaround I was not able to find any way to do it in any
| graphic interface of Windows, but all workarounds required
| to use in a Cmd window some obscure Microsoft command-line
| utilities with a lot of magic command-line options, which I
| did not understand and I could not find in the official
| Windows Knowledge Base, but which were suggested as
| solutions on various Internet forums and indeed they worked
| as desired.
| a1o wrote:
| Windows has a new terminal as default that is pretty cool - I
| install MSYS2 and set it in the new Windows Terminal and it's
| all good. Gnome Terminal and other terminals on Linux are
| also pretty cool too.
|
| If you want the worst default terminal experience just boot
| macOS.
| TacticalCoder wrote:
| > Doesn't Windows, the most popular OS out there, ...
|
| The most popular _desktop_ OS. It is nowhere to be found in
| the Top 500 supercomputers, is nowhere to be found on
| smartphones, lags in the Cloud, is nowhere to be found in the
| billions of appliances, etc.
|
| > Why isn't that harming Windows?
|
| It _is_ harming Windows. That horrible cmd.exe is one of the
| reason Windows lost in all the other markets and has hardly
| any market share there.
| SAI_Peregrinus wrote:
| Essentially nothing in Windows requires cmd.exe. Having a
| terminal in a desktop OS isn't a problem. Needing one is.
|
| Just like having a GUI isn't a problem for a server OS, but
| needing one is a problem.
| hnlmorg wrote:
| Apple would disagree with you on both counts.
|
| Plus for a long time desktop Windows needed cmd.exe to
| support login scripts.
|
| Just as people use Linux daily without ever touching the
| command line. Eg Android, LG smart TVs (webOS), Satellite
| TV set top boxes (eg Sky Q), home routers, etc.
|
| And if you want to focus on Linux running on laptops, then
| there are ChromeBooks and the old Asus EeePCs.
|
| The reason desktop Linux isn't polished is because every
| time a company invests heavily into desktop Linux,
| Microsoft undercuts them (like how they sold XP at a loss
| to thwart Linux in the netbook market). But the fact that
| Apple could take BSD, Google take Linux, and Nintendo also
| run BSD on some of their consoles, really speaks volumes
| about how there's nothing technically stopping people
| running a POSIX platform like Linux and still hide the
| command line from regular users.
|
| Though going back to my "Linux isn't polished" point, I
| still think Linux+KDE is a lot more polished than modern
| Windows. But that's just my biased opinion.
| a1o wrote:
| I must be doing something wrong because I can just use Home to
| go to the beginning of the line and End to go to the end and I
| am pretty sure all the things that are easy to type as just as
| easy to type be in Gnome Terminal on Ubuntu or Windows Terminal
| on Windows.
|
| The only place I need to know a bunch of weird shortcuts to
| figure things out is in the macOS terminal where everything is
| the less intuitive as possible.
| Mordisquitos wrote:
| If the only Linux distributions were in the style of LFS,
| Gentoo and Arch* you would have a point, but as long as Ubuntu,
| Mint, OpenSUSE, Fedora, Manjaro and the myriad other user-
| friendly exist I fail to see the argument.
|
| Yes, Ubuntu has a Concorde cockpit behind the scenes and yes, I
| can access it on my Ubuntu work* laptop and I am grateful that
| I have that choice. I would hate not having that level of
| control.
|
| Meanwhile, my mother's laptop is also Ubuntu and my
| girlfriend's is Manjaro, and they are both perfectly happy
| "flying their drones around" without ever setting foot in the
| Concorde cockpit.
|
| (*) _I use Arch btw_
| Workaccount2 wrote:
| I have used ubuntu for 2 years now, and its the motivation
| for the post.
|
| Ubuntu (or really any distro I am aware of) is great for
| pensioners (email readers) and power users (career linux
| user), with a protracted and hellishly complicated experience
| in between (technologically adept, but lifelong windows
| user).
|
| True, if you just want to fly straight to one of the most
| popular cities, you can just enter it in the autopilot and it
| will go there. But if you want to go anywhere or do anything
| else, you better be good a googling and understanding "how to
| fly a Concorde".
| bitwize wrote:
| What's condemning Linux to negligible market share is lack of
| preinstalls. Virtually no one used Windows, either, until
| Microsoft did everything short of coercing OEMs to bundle and
| preinstall it during the 3.x era.
| thestoicattack wrote:
| > the readline keybindings come from Emacs
|
| > Because I'm a vim user, It took me a very long time to
| understand where these keybindings come from
|
| libreadline supports a basic vi mode. In bash, `set -o vi` lets
| you use vim-style editing. It is a lifesaver.
| nightpool wrote:
| Already addressed in the article
| eviks wrote:
| > took me maybe 15 years of using the terminal every single day
| to get used to using Ctrl+A to go to the beginning of the line
| (or Ctrl+E for the end).
|
| And the curse of bad defaults strikes again (daily).
|
| After the realization that this is a weird default you don't
| train yourself for 15 years, but change it to your
| comfortable/common keybinds!
| jorams wrote:
| I wonder what terminal that is, because the Home and End keys,
| which I'm pretty sure are the expected alternatives, work fine
| in every terminal for me on Linux.
| a1o wrote:
| I have the same experience.
| binary132 wrote:
| If you were an Emacs user you would find this to be a good and
| useful default. ;)
| nine_k wrote:
| These defaults are not bad if you use Emacs :) Or if you use
| macOS that (gasp) supports the very same ^A and ^E shortcuts in
| all edit controls.
| xg15 wrote:
| > _First, there's "the baseline" - what happens if a program just
| accepts text by calling fgets() or whatever and doing absolutely
| nothing else to provide a nicer experience.
|
| [...] there are actually a few features that you get for free
| just from your terminal, without the program needing to do
| anything special at all.
|
| The things you get for free are: [...]
|
| - backspace
|
| - Ctrl+W, to delete the previous word
|
| - Ctrl+U, to delete the whole line_
|
| Linux noob here, so this may be a stupid question, but how does
| that work under the hood?
|
| The documentation for fgets() says [1]:
|
| > _Reads at most count - 1 characters from the given file stream
| and stores them in the character array pointed to by str. Parsing
| stops if a newline character is found (in which case str will
| contain that newline character) or if end-of-file occurs._
|
| Does that mean that, by default, fgets() blocks until the user
| enters a newline and, before they do, it lets them edit the line
| buffer using the backspace, CTRL+W and CTRL+U shortcuts?
|
| But there seems to be no guarantee that a program is using
| fgets() to read an entire line - it could also set count to 2 and
| read individual characters. Those could not be "unread" anymore
| when a backspace occurs. Is there some magic that lets fgets()
| buffer characters internally in such a situation, or would the
| backspace/line editing functionality just be broken then?
|
| [1] https://en.cppreference.com/w/c/io/fgets
| samatman wrote:
| It's provided by the terminal (emulator) in "cooked" mode:
| https://en.wikipedia.org/wiki/Terminal_mode
|
| raw mode doesn't do this.
| xg15 wrote:
| Ah, that's exactly the answer and makes a lot of sense.
| Thanks a lot.
| _kst_ wrote:
| To be clear, it's not the terminal emulator (xterm, mintty,
| iTerm2, etc.) that does this. It's the tty layer. You can use
| the stty command to change the settings.
| samatman wrote:
| Yes, quite right. I was thinking of the terminal _driver_
| and typed _emulator_ for some reason. Good catch.
| sweeter wrote:
| Programs like zsh, bash, ksh, fish and most TUIs put the
| terminal into cooked mode so that they can manage the terminals
| behavior manually. In cooked mode, the terminal is not new line
| buffered and instead every character is read. The terminal only
| appears to be new line buffered but is actually being managed
| by the shell, which then in turn allows the devs to add nice
| features like manipulating the text buffer to do tab completion
| or prepend the line with sudo.
| kkfx wrote:
| Also worth mention the Plan 9 "fixed prompt" where any command is
| at the top, with it's output underneath, there are few variants
| and in few cases they are comfy.
| I_complete_me wrote:
| I have great respect for Julia Evans and love her contributions
| that get shown here.
|
| But...
|
| > "I've always thought that vi mode seems really cool, but for
| some reason even though I'm a vim user I didn't really like using
| it when I tried it."
|
| Really, that seems weird to me.
|
| I use zsh (btw) and the problem she describes is a non-issue. And
| I am not a pro. (Sorry, Julia).
| drewg123 wrote:
| I don't find that strange at all (prefering emacs to vi mode).
| I feel the same way.
|
| I use tcsh, and have it configured for emacs-style command line
| editing. I use emacs for complex stuff (coding) and vi for
| simple stuff (editing a config file), so I'm comfy with both.
|
| I think my issue is that it seems slightly unnatural to
| remember the mode I'm in on a random terminal command line, and
| much easier to just use the emacs keys to edit when needed.
| vrnmh wrote:
| Another neat trick is to use ctrl-x ctrl-e, this gets the command
| in a vim buffer (default editor for me). Edit the command and
| then :wq to reflect the changes
| hnlmorg wrote:
| > some things this post left out
|
| + wide characters
|
| + different keyboard modes causing the same key press to be
| presented by different ANSI escape sequences
|
| + different TTY states (eg local echo)
|
| + different OSs having subtly different syscalls for changing TTY
| states
|
| + differing support for terminal emulation (most these days
| roughly emulate xterm, but even there, none aim for 100% be
| compatibility)
|
| + a lack of a consensus on how to check for features provided by
| a terminal (some use ANSI escape sequences and wait for an ansi
| sequence to be returned from the term (that's how the old VTs
| worked), some check $TERM (that's how the first wave of terminal
| emulation was detected), some terms expose themselves as xterm
| and ignore the VT feature sequences, but set other env vars. it's
| honestly a bigger mess than the user-agent string.
|
| ...and this is assuming a POSIX system. Things get doubly
| interesting when you throw Windows into the mix
| jFriedensreich wrote:
| warp and and some powershell version were the only "terminals" i
| used that seemed fixing the input line, but also did not quite
| feel right. the worst parts of terminals for me are that input
| line does not behave like a normal text field with mouse click,
| select and everything a user would expect in another context,
| that history mostly scrolls on a line basis instead of smooth
| pixel scrolling like any other document (don't get me started on
| pagers, i still don't manage to disable man pages opening in some
| archaic mode that takes 3 tries to even exit from git), commands
| that default to tuis or clearing the screen. i tried to avoid
| unix as long as possible because of this and the absurd random /
| hostile folder names + layout but just because *nixes won does
| that mean we have to keep these archaic absurdities alive? why
| does even something where innovation would be simple like the
| vscode terminal feel like that and not like the chrome console
| with a normal text input line with graphic autocomplete and
| mostly immutable command response history with
| collapse/expandable sections? even unix commands that would not
| work in this mode could just run in something like an inline
| widget or new tab where they could read input lines by character
| or whatever weird behavior they expect.
| phreack wrote:
| I think the lowest hanging fruit would be doing something
| (anything) to improve discovery of commands. I have great
| grokking abilities but terrible memorization skills, and I end up
| forgetting how to do what I want to do and maybe even have done
| before. Browsing man pages for every command is my bane. It's
| also why I dislike GUI with unlabelled icons, I never remember
| what each one does.
| syndicatedjelly wrote:
| Haven't used it much but "apropos" is probably what you want.
|
| https://man7.org/linux/man-pages/man1/apropos.1.html
| shadowgovt wrote:
| At this point Google has basically taken over that function...
| "How do I _ on the command line?" more often than not gives one
| _some_ starting point to develop from.
| jryb wrote:
| Maybe try fish? Tab completion will suggest subcommands, and if
| you type - or -- and hit tab, it will suggest the available
| options with help text generated from man pages (example:
| https://flaviocopes.com/images/fish-shell/autocomplete.png).
| Doesn't really help with positional arguments but it's
| definitely enhanced the discoverability of many tools for me.
| bongodongobob wrote:
| GPT is great at this. I wrote a little program that I can call
| from a shell. Bashai.py show me a bash one liner that does x.
| It then shows me the command and asks if I want to run it with
| or without root. Simple, yet one of the best tools I've ever
| made for myself.
| shadowgovt wrote:
| > license reasons, if the program's license is not GPL-compatible
| - readline is GPL-licensed, not LGPL
|
| The older I get, the less patient I become with finding out some
| user experience sucks because of GPL / non-GPL knife fights.
|
| It's been thirty-nine years now. I think the GPL was useful at
| its origin, but now the benefits of open-source are proven out,
| the world is _deeply_ interconnected via the Internet, and it 's
| a hindrance to have some code burden other code with
| requirements. I, for one, don't expect to write any further GPL
| code in my lifetime. I'd rather code be maximally unencumbered
| from interoperation.
| mxuribe wrote:
| @shadowgovt Genuine question: if i wanted to create new
| software nowadays, and i wished for it to be as you noted
| "mmaximally unencumbered from interoperation", which license
| should i choose for my software? Which license would you use?
| Again, not trying to be snarky; just wanting to learn and
| understand. :-)
| Uehreka wrote:
| So when I use Windows Terminal and I press Ctrl-C, it always does
| the right thing: If I'm selecting text I want to copy it, if I'm
| not selecting text I want to kill the running process.
|
| On Linux, every Terminal app I've used stubbornly refuses to copy
| when I press Ctrl-C, demanding I press Ctrl-Shift-C. When I
| paste, if I forget my manners and use Ctrl-V instead of Ctrl-
| Shift-V, I am punished by getting a weird character when I start
| typing again. And I am constantly pressing Ctrl-V because of
| muscle memory since no other app works this way.
|
| Is there any terminal app for Linux that does things the Windows
| Terminal way and won't slap me on the wrist for Improper Teletype
| Usage?
| FooBarWidget wrote:
| I've always configured my terminal to copy on select. I never
| press ctrl-c. I mean, why would I want to select text if not to
| copy it?
| agapon wrote:
| E.g., to press Ctrl-(Shift)-V and replace the selection with
| something you copied (to the buffer / clipboard) earlier?
| ordu wrote:
| I copy from/to terminal with middle mouse button. Just select
| some text and click middle button where you want to paste the
| text. Some people don't like it because it needs a mouse, they
| prefer to keep their hands on the keyboard, but I don't see any
| issues with it.
|
| This way to copy/paste uses it's own Xorg buffer, so you can
| copy something with Ctrl-C and select something else, and then
| Ctrl-V will paste the first thing and middle click the second.
| I have issues using Windows and smartphones because I sometimes
| try to copy by just selecting things, forgetting to hit Ctrl-C
| or something. It is really annoying.
|
| > Is there any terminal app for Linux that does things the
| Windows Terminal way and won't slap me on the wrist for
| Improper Teletype Usage?
|
| I think not. The trouble is programs running in terminal may
| want to deal with Ctrl-C by themselves. Text editors for
| example do that, but terminals have no way to know it.
| Terminals even don't know what program is running now, because
| job control is a job of a shell.
| groos wrote:
| Wirth showed us decades ago how to do UIs using text in a modern
| way yet we remain firmly tied to digital analogues of teletype
| terminals.
|
| https://en.wikipedia.org/wiki/Oberon_(operating_system)
| LordDragonfang wrote:
| See also the same blog's previous article, "What happens when you
| press a key in your terminal?"
|
| https://jvns.ca/blog/2022/07/20/pseudoterminals/
|
| (It's a great article, and I'm fairly surprised the post doesn't
| directly link to it)
| inickt wrote:
| Likely an unpopular take, but I switched to the "Natural text
| editing" preset in iTerm2 to get editing shortcuts that match the
| traditional macOS ones. It has the advantage of just remapping to
| the normal control sequences inside terminal apps, so you
| basically get this functionality everywhere without needed to
| change it in multiple places/worry about readline support/etc. It
| isn't perfect (I have rarely needed to enter sequences manually
| that then are remapped), but I find I have used way more command
| editing since its part of my muscle memory.
|
| https://pliszko.com/blog/post/2021-10-31-natural-text-editin...
| alganet wrote:
| This is nice. As always, Julia's articles are always a win.
|
| Here's some stuff that's missing:
|
| Within shell scripts, you can use `stty` to change a lot of stuff
| about the terminal, including how it deals with inputs. You can
| rewire all of these defaults and behaviors.
|
| Here's an experiment I did a while ago using sh and stty:
| https://gist.github.com/alganet/63f1dbc97b8fd35f7bb14ec30f79...
|
| It is able to capture and understand most keyboard combinations
| and even mouse gestures (hold/drag/drop) from within the shell in
| any VT100-compatible terminal (mintty, xterm, Terminal.app,
| vscode, so many others).
|
| Runnable demo: bash -c "$(curl -L
| https://git.io/fjToH)"
|
| Run it and press some keys or move the mouse. Use Ctrl+W to exit.
| It supports zsh and ksh too, but not dash or other shells lacking
| `read -rn1`.
|
| ---
|
| Here's another funny thing: `vi | cat -v`
|
| If you pipe an interactive program to `cat -v`, you can see which
| VT100 escapes that program is using. I learned a lot from how vi
| does it.
| alganet wrote:
| Here's a bonus:
|
| Ever ran a command that left your terminal mangled after it
| finished? No output, weird chars, etc.
|
| That's lack of proper tty hygiene on the offending command.
| Instead of killing your terminal, type: stty
| sane
|
| And you'll demangle it.
| anothername12 wrote:
| I think the command "reset" does something similar
| alganet wrote:
| You are correct! I think it does a little more (restoring
| cursor if hidden, etc). If you have it, it is probably
| better than `stty sane`
| kfrzcode wrote:
| friendly reminder to always check before you slurp code
| directly to bash from the internet. this may have broke my
| (admittedly totally non standard) configuration in weird ways I
| didn't care to document.
| hi_dang_ wrote:
| I thought this was going to cover RS232 implementations. Oh well,
| next time :-)
| 1vuio0pswjnm7 wrote:
| "The other day I asked what folks on Mastodon find confusing
| about working in the terminal, and one thing that stood out to me
| was "editing a command you already typed in".
|
| This really resonated with me: even though entering some text and
| editing it is a very "basic" task, it took me maybe 15 years of
| using the terminal every single day to get used to using Ctrl+A
| to go to the beginning of the line (or Ctrl+E for the end)."
|
| Only took me a year or so to get used to using "v" in vi mode and
| fc. I am not a "developer" but I prefer textmode command line to
| GUI. I do not use X11/Wayland/etc.
|
| I learned sh on NetBSD which I still think is one of the best
| shells available. It's fast. vi mode is the default. People may
| disagree but I think for editing single a line of text, i.e., a
| "command", vi mode offers more precision. For example, being able
| to jump directly to a particular column number.
|
| https://web.archive.org/web/20240528201424if_/https://pubs.o...
| #list previous commands fc -l #edit 5th command on
| the list fc 5
|
| IMO, as a dumb computer user who is not a "developer", this is
| not complicated. I think terminal emulators are complicated,
| though. I do not use them.
|
| I believe fc came to POSIX from ksh.
|
| For me, it is not that UNIX is objectively good. It is that the
| available alternatives are still comparatively bad.
| kazinator wrote:
| I've never seen dash dump escape sequences instead of acting on
| arrow keys. Probably, it's due to a missing or wrong TERM value?
|
| Nowadays, programs should be hard-coded to accept ANSI sequences
| and ignore TERM (unless they need to make some fine-grained
| distinction like do we have 256 color xterm compatibility).
|
| Those programs will never have that problem of not understanding
| arrow keys.
___________________________________________________________________
(page generated 2024-07-08 23:00 UTC)