Yash: Yet Another Shell(github.com) |
Yash: Yet Another Shell(github.com) |
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.
https://www.howtogeek.com/be-more-productive-in-linux-with-k...
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.
So the field is ripe for whoever wants to try... though now same accounts to XYZ are being used for hundred things..
If that's not enough, there's always whole VMs.
Nix is that taken to the logical conclusion.
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
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.
A lot of my commands would work in any directory, but sometimes the directory matters and I run it in the wrong place.
shopt -s histappend
PROMPT_COMMAND="history -a"It’s a free local (or remote) better shell history utility. Does a good job of syncing histories across multiple windows in my experience
# History file for zsh HISTFILE=~/.zsh_history
# How many commands to store in history HISTSIZE=10000 SAVEHIST=10000
# Share history in every terminal session
setopt SHARE_HISTORY
function set_histfile {
export HISTFILE="$HOME/.bash_history_$(pwd | tr '/' '_')"
}
PROMPT_COMMAND="set_histfile; $PROMPT_COMMAND"
There may be other ways, but probably can't do it without PROMPT_COMMAND.Someone else mentioned "direnv", too.
https://docs.atuin.sh/reference/search/#examples
You could also make "directory" the default filter mode or bind it to up-arrow:
https://docs.atuin.sh/configuration/config/#filter_mode
https://docs.atuin.sh/configuration/key-binding/#custom-up-a...
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: line=$(docker ps | grep postgres)
echo $line | awk '{print $2}'
echo $line | awk -F 'ago' '{print $2}' | sed 's/hours.*/hours/'
to get output like this postgres:12.6
Up 9 hours
In nushell, that's this (notice that it gets the whitespace right, which is more than I can say for awk). $ docker ps | detect columns --guess | where ($it.IMAGE =~ postgres) | select IMAGE STATUS
╭───┬───────────────┬────────────╮
│ # │ IMAGE │ STATUS │
├───┼───────────────┼────────────┤
│ 0 │ postgres:12.6 │ Up 9 hours │
╰───┴───────────────┴────────────╯
This the part where somebody says "powershell does that too", but check out this stackoverflow post on just how that might be done: https://stackoverflow.com/questions/47335781/extract-columns... It's not exactly wow material.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:
$ let token = "REDACTED"
( http post
-H {Circle-Token : $token}
--content-type application/json
"https://circleci.com/api/v2/project/gh/job/myproject/pipeline"
{ branch: "main", parameters: { action: "dothething" }}
)
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.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.