I kind of wish there was a shell that had the option for histories localized to a directory. So I can go into a directory and then look at what I was doing when I was last in that directory. Some complicated compilation command line to compile and link a source file and a bunch of libraries that was run when I was last in that directory, for example. There'd still be the 'history' command for everything and then maybe 'dhistory' for the commands that I ran in that specific directory when I was last there.
I kind of wish there was a project-oriented complete desktop environment, where you could enter a project and everything was context-sensitive to it. editor, files, directories, shell, browser, whatever.
sort of a way to work on projects, then put them on old.
and maybe meta-projects to choose, track, arrange, manage some or all projects. maybe by area of responsibility.
Initially it seemed useful but it quickly felt like more of a chore. At work it's mostly just the same one IDE and one browser. For personal stuff I either used a different user account/different laptop and there was little benefit of activities for me after that.
looong time ago - ~2005 maybe? - the late Pieter Hintjens told me about such overarching idea including whole project management and all related ping-pongs - code, data, documents, issues, e-mails, chats, everything - think like one laptop for this project and different one for that project - and that they had at the time approached something like that, and got it mostly working, over linux etc. But AFAIK it never went public and has been abandoned.
So the field is ripe for whoever wants to try... though now same accounts to XYZ are being used for hundred things..
my first thought too. on a mac at least it’s a little crusty, but it really does make it convenient to have a project completely and accurately describe its environment.
nushell does this by default, sort of. it will show you autocompletes that are relevant to the current directory and will fallback to history more generally.
i’m a huge nushell fan. if you can stand a non POSIX shell, it’s great for working with any kind of structured data and has a sane mostly FP scripting language
When I first switched to nushell as my daily driver, I spent a lot of time integrating fzf in various creative ways, which was a fine learning exercise I guess.
But once I realized that the auto complete was sensitive to my cwd, I've since been using my fzf bindings less and less.
I'm very happy I made the switch, for this and many other reasons.
I bet yash is great, sorry for distracting from the topic, but since you asked...
It's not one killer feature, but it's a lot of small things that add up to this feeling that POSIX shells are stuck in a rut and that a better world is possible.
I'm going to use docker output as an example. I know that you can ask docker for json and then use jq, but let's pretend that what you're working with isn't so friendly as docker. Here's the output of "docker ps", a string:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
786fc8348b7a postgres:12.6 "docker-entrypoint.s…" 9 hours ago Up 9 hours 127.0.0.1:5432->5432/tcp
I'm not proud of it, but I used to write bash scripts which looked like this:
Powershell feels to me like it's made by people who want all data to be structured, and who expect the app to do the work of structuring it for them. nushell feels like it's made by people who understand that text is king, and who are willing to attempt taming that beast as-is.
Plus there are a lot of batteries-included things that just feel nicer. Like if you want to make an http post request, the command is "http post". Of course you can still use curl, but I feel like this is so much more readable:
The built in help is excellent (try "help http post"), and the error messages are very pleasant:
$ 5 + "5"
Error: nu::parser::unsupported_operation
× addition is not supported between int and string.
╭─[entry #208:1:1]
1 │ 5 + "5"
· ┬ ┬ ─┬─
· │ │ ╰── string
· │ ╰── doesn't support these values
· ╰── int
╰────
I dunno, it's just nice. I'd be much happier teaching a bunch of scientists to use nushell than I am when teaching them to use bash. When I try to do the latter I feel like I just stepped out of a time warp from the 60's and they think I'm here to punish them.
That "detect columns" piping stuff looks very nice, though it looks like this is something that could be implemented extrashellularly (as discrete "detect" and "where" binaries)?
Eh, yes and no. There's nothing stopping a cohort of programs from adopting some standard and using it among themselves such that the binary values that are traveling across the pipes are interpreted by the recipient as having some type, and then if the reader of your pipe is a tty then you draw a pretty picture for the user, which gets you much of the way there in principle.
But as far as I know there's no portable way to write a program which can uncover enough of the pipeline to print an error message that spans multiple stages. So you get output from potentially many of them and you have to figure out who is complaining.
I'm not intimate with the implementation but it feels like nushell commands are compiled, so there's much less deduction necessary to just tell the user what is wrong in a way that considers the whole command instead of just one stage of the pipeline.
I haven't spent much time with the plugin interface yet, but the idea is that programs can register their input and output types with the shell if they want nushell to treat them like it does it's builtins. Its an extra step up front, but it seems like less of a mess than trying to coordinate types been programs without having a common touch point for them.
well, it’s a few things. a lot of it comes down to reading structured data and scripting. i will often stream logs from k8s or when running a service locally that outputs JSON, and nushell can parse the logs for readability or to find a particular field. i mean, that’s nothing jq couldn’t do. but having an integrated experience based more on readability makes things nice.
also when i say scripting i mean actual real functions. you can define a command complete with parsed documented arguments as if you’re using argparse or clap, and it also supports completions. so when i go to sign into the company VPN i have a lil function that grabs my credentials and takes an argument that is one of several providers my company uses, which i can autocomplete with tab because i’ve written a simple completion helper (literally a function that returns a list). it’s documentation as code, and i push all these helpers up to my company git repo so when someone asks me how to do something i have workable readable examples.
if you’ve ever wanted a real programming language (like Python) as your shell, i think this is worth a shot.
Neat idea. I think I’d like it to maintain a global history and local, with some UI affordance to remind me both exist and perhaps what are the last few entries.
A lot of my commands would work in any directory, but sometimes the directory matters and I run it in the wrong place.
What I do is split up my work by context into different screen (or tmux, depending on mood when I set up the computer) sessions. I have a script that attaches one by name if it's present and otherwise creates one with the name in question after setting an environment variable that's therefore inherited by any shells spawned in that screen session. Various things in my bashrc then look at that environment variable to point things at a context specific config directory, including setting HISTFILE to a context specific history file and sourcing a context specific bashrc (in which I often cd to a relevant directory and may set some variables, functions, and aliases specific to the context).
Yes, but it's a shell nevertheless :), and it actually now supports some of the most common bashisms, so simple copy-pasted commands designed for bash now work. For any actual scripting IMO bash (or /bin/sh) is still the better choice, since it's installed everywhere, even though it might not have such great syntax.
If you are open to using zsh, take a look at https://github.com/larkery/zsh-histdb . It stores your zsh history in a sqlite3 db. The benefit of this is that your history is well-structured and indexed, and that you can use SQL to query it. The working directory, exit status, and more are included, so you can easily implement your own smart history tools.
I'm an atuin user and if this feature exists, I have not seen it and would love to have it. Could you expand on how to get per-directory history as something separate from global shell history?
This is a great idea. Just better history management in general would be such a boon. If I have multiple console windows open, I still don't know what will wind up in .bash_history, and what (which?) history will be there when I start a new one.
I've never seen a mid-sized C codebase that annotate "restrict", "nonnull" pointers and "pure", "const" functions so thoroughly, very interesting, would be an important case study if I ever get around to write C optimizer passes.
Scenario: Something forces a reboot. I've got 4 bash shells open. I've been doing some compilation & linking of libraries with a crazy long gcc command. After I reboot, that's not in my history because only the first-opened bash shell's history seems to get saved and I've gotta recreate the commandline again. Is there any shell that would let me see all the history from all of the different shells I might have had open?
I had something similar set up on my second to last work laptop. I had done some heavy customization that was mostly focused on common workflows for that job, but I have learned that I should still keep a backup even if most of it won't work elsewhere. I should have learned this lesson almost a couple decades ago when I lost all my emacs customizations on a personal computer. But instead, I decided to learn vim.
As unhelpful as the other commenter suggesting atuin was, this is actually a thing that atuin does well, if you're using a shell it supports, it commits to history immediately.
It's a comfortable, feature-rich interactive shell like bash, but with a relatively clean and small codebase, and the binary is only a third of bash's size. It's also much easier to build from source. Sort of a suckless bash replacement. Not compatible to most bash features though, focus is on POSIX compatibility.
Not sure, but it says it's the most POSIX-compliant shell. Sometimes you have a requirement for a project like "must use a POSIX-compliant shell". If all the other existing shells are only mostly POSIX-compliant, then you'd want Yash.
