3 ms·
This may be obvious, but what I realized recently, when I tried to switch to one of the “alternative” shells (xonsh, based on Python), is that the experience of
by svat 3y ago
This may be obvious, but what I realized recently, when I tried to switch to one of the “alternative” shells (xonsh, based on Python), is that the experience of using a shell is (at least) four (overlapping) experiences:
1. The basic interactive stuff at the command-line: typing commands, tab-completion, aborting a half-written command when you change your mind or remember something else to do first, cut-and-paste, ….
2. Basic scripting at the command-line: writing a loop, piping one command into another, defining a function (over multiple lines?), ….
3. Scripting for job control: getting the return value of a command, waiting for a command to finish, putting one in the background, sleep, …
4. Programming as in other languages: if/else statements, assigning to variables, what arrays look like, doing more complicated logic and processing, ….
[There's some overlap, and note that (3) or (4) may happen either at the command-line itself or in a separate .sh (or whatever) file in a text editor.]
I found that `xonsh` seemed to be focusing on making (4) better—basically replacing the `if … fi` and `case … esac` of Bash/Zsh with Python—but it turns out I care about it less, and I'm too used to (just) 20 years of (1) to miss it: when Alt-. doesn't insert the last part of the previous command, or I cut some line(s) with Ctrl-k and Alt-y doesn't maintain the kill ring to paste it back (so it's gone??), and half-a-dozen other issues like that, it was annoying enough for me to switch back in less than a day or two. I don't think of myself as an old/long-time user (when I started in 2003 I was a newbie), but I guess I am one by now: don't mess with standard readline conventions. And (3) is core to why someone would use shell scripts; if you need me to "import subprocess" or do anything nontrivial to pipe (for example), you've already lost me.
My understanding is that fish has focused on (1) with good results, and the "ls | where size > 10kb" example here, or what Powershell is good at, is focusing on another (5) that I didn't write about (the commands themselves, the flags to them, parsing their output etc).
Anyway, interesting post, I'll try out nushell. As the post doesn't seem to link to it: https://www.nushell.sh/ https://www.nushell.sh/ (install it, and then start it with `nu`, not `nushell`.)
- 1vuio0pswjnm7 3y agoFWIW, I like libedit's vi mode more than readline's.
- fiddlerwoaroof 3y agoThe issue I have is I don’t really get the value of solving (5) at the shell level: anything doable with richer datatypes is doable with a version of coreutils and peripheral utilities with better serialization formats. And, I’d rather the shell’s piping be less intelligent in favor of offloading more intelligence where it’s easier for users to extend: external binaries on $PATH
- 10000truths 3y agoI strongly agree, the dumbness of the Unix pipe is instrumental to its composability. The actual issue is the lack of an agreed-upon standard, default, stable, machine-friendly output format across the "give me a list of x" commands. I can easily imagine a parallel universe where df, ls, find, etc. would output JSON by default, and jq (or some other JSON manipulation utility) would be just as important as the shell itself.
- svat 3y agoOne of the other comments (https://news.ycombinator.com/item?id=37335912 https://news.ycombinator.com/item?id=37335912) mentions that it's possible to use `nu` for its (5) solutions without switching to it as a shell: nu --commands 'ls | where size > 1MiB' So it seems possible to use nu and its coreutils equivalents / filters as an “island” having structured output and easy parsing etc, without switching one's shell.
- 8n4vidtmkvmk 3y agoI think there's a (6) here too.. the terminal app that the shell runs in. I still don't fully understand how the 2 interact, but I've never been quite happy with any terminal I've used and I wish someone would just marry the shell and the terminal so they can have nice rich integrations that aren't limited to text. Like why can't I just pop into a file picker to complete a path if I want to? Why can't I get a drop down of options like in my IDE? Tooltips? Images? Why do I have to remember what magic keystroke I need to background a process without losing it forever so that I can run another one while I wait?
- follower 3y agoFWIW I think wezterm (https://wezfurlong.org/wezterm/ https://wezfurlong.org/wezterm/) offers some hope in this direction. I switched to wezterm (a couple of years ago by now, I think) in part motivated by its support for "Kitty graphics" protocol (and others) but also because its author seemed to be interested in pushing the envelope in terms(!) of what a terminal could be & do. The recent addition of a Command Palette[0] really helps with discoverability of features and can also have user customised items added[1] to it. Other recent additions include the ability to prompt the user to choose from a list of options[2] or input text[3]. This is barely scratching the surface of the feature set but you might like to take a look at wezterm to see if it might be closer to your terminal ideal or at least a project to watch that's innovating in the terminal space. :) [0] https://wezfurlong.org/wezterm/config/lua/keyassignment/ActivateCommandPalette.html https://wezfurlong.org/wezterm/config/lua/keyassignment/Acti... [1] https://wezfurlong.org/wezterm/config/lua/window-events/augment-command-palette.html https://wezfurlong.org/wezterm/config/lua/window-events/augm... [2] https://wezfurlong.org/wezterm/config/lua/keyassignment/InputSelector.html https://wezfurlong.org/wezterm/config/lua/keyassignment/Inpu... [3] https://wezfurlong.org/wezterm/config/lua/keyassignment/PromptInputLine.html https://wezfurlong.org/wezterm/config/lua/keyassignment/Prom...
- eviks 3y ago5. it takes more than a day or two to change to something better or find workarounds to preserve the old habits in the new environment
- maegul 3y agoInteresting on (1), I’ve always used vi mode (like I don’t even know those commands, maybe they work in vi mode too?) and from memory Xonsh had as good a vi mode as bash along with some baked in improvements over vanilla bash. I’m more or less waiting to move to Xonsh full time to see how I go once I’ve got some time to invest moving, largely because it seems it will be a win on all 4 points for me. Otherwise, the bigger point 5 you allude to is probably the real issue we’re all avoiding.
- xmonkee 3y agoYeah, vi mode is a must for me at this point. I have the readline shortcuts on a post-it on my monitor for the odd time i find myself in a sqlite repl or something.
- kagevf 3y agoThat feature comes from emacs; hit ctrl-y to get ("yank") the last thing you copied, hit alt-y to get the previous thing you copied, and keep hitting alt-y in succession to cycle through the clipboard, which is called the "kill ring" in emacs. I don't know if vim itself supports that feature, let alone vi mode on the command line. "Real" vim supports adding text to registers - does vi mode support it?
- pkulak 3y agoThis is the first I’ve heard of a “kill ring” thing, and it sounds wonderful. Pasting in Vim is generally a PITA because I always cut some word, then delete something to make room for it, which is itself another cut, and then I have to remember what register the thing I want is in now, and how to get at it. Double quote and then 9? I can’t even remember and I’ve been using Vim every day for a decade now.
- NegativeLatency 3y agoI set my vim clipboard to use the system one, and then use a system level clipboard manager it’s great https://github.com/TermiT/Flycut https://github.com/TermiT/Flycut