I've been trying nushell and words fail me. It's like it was made for actual humans to use! 🤯 🤯 🤯
It even repeats the column headers at the end of the table if the output takes more than your screen...
Trying to think of how to do the same thing with awk/grep/sort/whatever is giving me a headache. Actually just thinking about awk is giving me a headache. I think I might be allergic.
I'm really curious, what's your favorite shell? Have you tried other shells than your distro's default one? Are you an awk wizard or do you run away very fast whenever it's mentioned?
Nushell looks cool but I prefer to stick with the POSIXes so that I know my scripts will always work and syntax always does what I expect it to. I use zsh as a daily driver, and put up with various bashes, ashes, dashes, that come pre-installed with systems I won't be using loads (e.g. temporary vms).
Always confuses me when people say this. You can use multiple different shells / scripting languages, just as you can use multiple programming languages.
If you want your scripts to "always work" you'll need to go with the most common/standard language, because the environments you work on might not be able to use all of those languages.
I mean if all your scripts are fully general purpose. That just seems really weird to me. I don't need to run my yt-dlp scripts on the computational clusters I work on.
Moreover, none of this applies to the interactive use of the shell.
It's not only clusters.. I have my shell configuration even in my Android phone, where I often connect to by ssh. And also in my Kobo, and in my small portable console running Knulli.
In my case, my shell configuration is structured in some folders where I can add config specific to each location while still sharing the same base.
Maybe not everything is general, but the things that are general and useful become ingrained in a way that it becomes annoying when you don't have them. Like specific shortcuts for backwards history search, or even some readline movement shortcuts that apparently are not standard everywhere.. or jumping to most 'frecent' directory based on a pattern like z does.
If you don't mind that those scripts not always work and you have the time to maintain 2 separate sets of configuration and initialization scripts, and aliases, etc. then it's fine.
This feels like ragebait. I have multiple devices, use fish whenever that can be installed and zsh/bash when not, and have none of these issues.
EDIT:
Manually downloading the same shell scripts on every machine is just doing what the package manager is supposed to do for you. I did this once to get some rust utils like eza to get them to work without sudo. It's terrible.
If you have a package manager available, and what you need is available there, sure. My Synology NAS, my Knulli, my cygwin installs in Windows, my Android device.. they are not so easy to have custom shells in (does fish even have a Windows port?).
I rarely have to manually copy, in many of those environments you can at least
git clone, or use existing syncing mechanisms. In the ones that don't even have that.. well, at least copying the config works, I just scp it, not a big deal, it's not like I have to do that so often.. I could even script it to make it automatic if it ever became a problem.Also, note that I do not just use things like
zstraight away.. my custom configuration automatically callszas a fallback when I mistype a directory withcd(or when I intentionally usecdwhile in a far/wrong location just so I can reach faster/easier).. I have a lot of things customized, the package install would only be the first step.So you're willing to do a lot of manual package managing, in general put a lot of work into optimizing your workflow, adjusting to different package availability, adjusting to different operating systems...
...but not writing two different configs?
That is your prerogative but you're not convincing me. Though I don't think I'll be convincing you either.
I have separate configs/aliases/etc for most of my machines just because, well, they are different machines with different hardware, software, data, operating systems and purposes. Even for those (most) that I can easily install fish on.
It's actually the lazy way. I only work once, then copy that work everywhere. The copying/syncing is surprisingly easy. If that's what you call "package management" then I guess doing "package management" saves a lot of work.
If I had to re-configure my devices to my liking every time I would waste time in repetition, not in an actual improvement. I configured it the way I liked it once already, so I want to be able to simply copy it over easily instead of re-writing it every time for different systems. It's the same reason why I've been reusing my entire /home partition for ages in my desktop, I preserve all my setup even after testing out multiple distros.
If someone does not customize their defaults much or does not mind re-configuring things all the time, I'm sure for them it would be ok to have different setup on each device.. but I prefer working only once and copying it.
And I didn't say that bash is the only config I have. Coincidentally, my config does include a config.fish I wrote ages ago (14 years ago apparently). I just don't use it because most devices don't have fish so it cannot replace POSIX/Bash.. as a result it naturally was left very barebones (probably outdated too) and it's not as well crafted/featureful as the POSIX/bash one which gets used much more.
Good that works for you. If only my needs were so simple that the configs could be same on each machine.
paljastus
I know that's an insufferable way to put it but holy shit have you been like that too.I know that. I just don't have a use case for alternative shells. Zsh works fine for me and I know how it works. I don't have problems that need fixing, so I don't need to take the time to learn a new, incompatible shell.
Some people work on machines where they are not allowed to install anything.
What does that have to do with anything?
You said you/I/everyone can use multiple shells, I said: no, I can't, at least not on all the machines that I have to use.
Ok?
Your scripts should have Bourne shebangs
Yeah, there should be a clear separation between scripts, which should have a shebang, and interactive use.
If a script starts acting oddly after someone does a
chsh, then that script is broken. Hopefully people don't actually distribute broken script files that have some implicit dependency on an unspecified interpreter in this day and age.They have
!/bin/shshebangs./bin/shis a symlink, in my case to zsh. I like using one language.than your hashbangs are bad. isn't their point to tell the kernel exactly which interpreter can process it correctly?
To be fair, I'm fairly sure the zsh interpreter has a POSIX sh mode
They're posix scripts... Any posix compliant bin/sh can interpret them.
Hopefully you're not using the sh language—hopefully you're restraining yourself from using any of the non-POSIX extensions then
I don't really mind having a non-POSIX shell since it doesn't prevent bash scripts from working, but I get that if you want portability bash is still best since it'll work mostly anywhere.
If I can shebang nutshell (assuming all the builtins from bash or even sh work) and pass a flag to remove all the fancy UI-for-humans formatting so that piped commands int eh scripts work, then I think this is incredible.
Yeah having this installed along side other more “standard” shells is fine I guess, but it looks like maybe it has some neat functionality that is more difficult in other shells? I guess I’d need to read up on it more but having a non-interactive mode for machines to read more easily would be a huge plus for it overall. I suppose that depends on what it offers/what it’s trying to accomplish.
The Unicode bars aren't actually stored; that's just the graphical representation of the table datatype which you can think of as JSON
Like PowerShell does?
exactly
some claim that was the inspiration for nushell: powershell but less verbose and more bashy
I love NuShell but it is annoying when using LLMs to generate troubleshooting code.