I use Zsh, it's such a tremendous improvement over Bash. Not only does it handle parameter expansion much better than any Unix-style shell, but it also has a lot more useful built-ins that can save you from having to call out to external programs to do basic tasks, like getting the absolute path of the directory that contains the current script.
It is so unbelievably feature-rich that it's almost impossible to describe all of its features and merits, but you can safely ignore most of them and the basic day-to-day experience will just be "Bash, but better".
No program is perfect, but Zsh I think is pretty damn close. That's not because it doesn't have flaws (it definitely has flaws), it's because it does such a good job at doing what it does, that all its flaws seem minor and none of them fundamentally get in the way of it doing that job.
One additional thing I'll say is: it is probably the only Unix-style shell where I would feel comfortable writing 1000+-line applications with a CLI, tests, etc. I would never do such a thing with Bash or some minimal Posix-compatible shell. It's a very sensible system scripting language, alongside Python, Perl, etc.
It may be better bash, but it's just an incremental improvement, no more. It still follows the same philosophy as bash.
On the other hand, fish shell feels like a bash rethought and optimized for interactive use. It's now my daily driver on all of my Linux and Windows machines (msys2 port). After using it only for interactive sessions, I also started to write my utilities in fish, which is a breath of fresh air compared to both bash and zsh.
The only place where I still use bash is when I need to write a script that needs to be shared with others, everything else is now fish.
Within 30 seconds of installing fish, I shouted, "How the hell do I disable these annoying suggestions?! This is worse than Clippy!" So I searched fish's docs and learned that it wasn't possible to disable the suggestions! The fish docs state, "Configurability is the root of all evil"[1]. As an Emacs user, this was the most offensive thing I've ever read, which is saying a lot because I once read a work of erotic Star Trek fan fiction about a love triangle involving Dr. Crusher, Wesley and Worf.
[1] https://fishshell.com/docs/current/design.html#configurabili...
not the link I was hoping for ;)
If you don't want suggestions and completions, fish is definitely not the right shell for you !
That said fish is quite configurableĀ¹, it just have pleasant (well maybe not to you) default that you can change.
1- The ssettings are mostly listed there https://fishshell.com/docs/current/interactive.html
I use fish as my default user interactive shell but I still agree with you. I despise this philosophy of "configurability is the root of all evil" coming from fish and "every preference has a cost" coming from GNOME.
I think these projects are extremely opinionated and they will inevitably drive a lot of users away. Both fish and GNOME strive to provide "good" defaults out of the box but those defaults will never appeal to everyone. I ended up liking fish but I still despise GNOME and everything related to it.
Likewise, I don't use fish for exactly this reason. It seems extremely fine tuned to meet exactly the preferences of its developers, and eschews all further configurability. The Clippy comparison is brilliant, by the way, pretty much summarizes my exact feelings about the suggestions.
I ended up back on zsh. It's a real shame, because fish adds quite a lot in terms of improved subshell syntax and intelligent string manipulation.
Seems like someone should have been able to disable the suggestions using a plugin or something, given that IIRC fish has a plugin interface. But as far as I can tell no such thing exists.
The advantage of that, though, is that you can still benefit from the many "how do I do X in bash" posts on various fora, Stack Exchange, etc. With the more esoteric shells you have a much smaller community.
It's very infrequent that you're doing something truly novel with your interactive shell.
For scripts, you can still use bash or zsh or python or whatever you want.
That's a very good point. I have stuck with it because I am comfortable with it, but I have been wanting to spend some quality time with these alternative shells for a while. Have you tried Elvish? I am particularly curious about that one, because it seems like the primary Fish "competitor", but seems comparatively a lot less popular.
I also use fish on basically every linux machine, desktop or server, but I've also tried elvish for a bit. My shell scripts are still mostly bash or even POSIX though, because I haven't rewritten them yet, or they're setup scripts that should work right after the install without installing an additional shell first.
I'll admit that I haven't really dug into scripting with elvish, because I quickly abandoned it again.
My main reason for leaving elvish again was the good syntax completion in fish. Yes, you can create your own completions in elvish and they'll probably be just as good, but that takes time and I ultimately decided not to bother with it.
> it's just an incremental improvement, no more. It still follows the same philosophy as bash.
It is actually the other way round, with bash being an incremental improvement over zsh. Starting from v3, bash has adopted many features that zsh had had for a long time.
Both, bash and zsh, are incremental improvements over the Korn shell.
> It's a very sensible system scripting language, alongside Python, Perl, etc.
Iāve always assumed that the main benefit of bash scripts is that theyāre portable and universal. If youāre willing to compromise that, why not just go with python? I donāt really understand which gap zsh fills here.
> why not just go with python?
I can't speak for anyone else, but for me, it's because Python is cumbersome for doing the sorts of things that are easy in a shell. You want to capture the output of a command, parse it as a tab-separated table, extract the 3rd and 4th columns, and then use them to create new users with the values supplying usernames and passwords. Can you do that easily in Python?
For all its syntactic sugar, dealing with files in python (which comprises probably 90% of what I open a shell for) still requires a fair amount of boilerplate. Which is good for a general scripting language, but makes it poor for the the kind of tasks I expect of a shell.
> Can you do that easily in Python?
I'm not arguing for Python over bash, I'm asking about the value of zsh as opposed to bash or python. So why couldn't one do what you describe in bash? The answer probably is you very well could. So why use zsh for scripting?
I've generally ported _to_ Python to see improved portability: the problem with bash is that it's not just what versions of bash you have installed (if you support RHEL, MacOS, etc. that can limit you significantly) but also all of the utilities which you call so you probably end up needing to wrap things like readlink once you need to run on more than one of GNU, BSD, busybox, etc.
Obviously you can get a fair amount done with pure POSIX but for me it's almost inevitably hit the point where you rewrite it in something else and realize that it's like 30% fewer lines of easier to understand code.
Fine, but this does nothing to address the value of zsh which is what I was asking about.
Furthermore, interactive zsh totally breaks vim-like input mode.
If you choose vim keybindings for navigation, it utterly breaks reverse-r search and the hacks you have to use to fix it do not make it an equivalent experience.
It's like the zsh folks said, "fuck those vim guys".
If I didn't have to use a Mac at work and our tooling didn't behave oddly in bash, I wouldn't use it. Bash is much more comfortable.
What are you talking about? Using reverse-r search in vi mode requires a single line config, no hacks involved.
bindkey -v '^R' history-incremental-search-backward
It's like the zsh folks said, "I like those vim guys".
As a vim user, zsh's vim mode is far better. You do need a few lines of config for stuff like allowing deleting back past the insert position. However, I have never found it lacking, unlike bash which sometimes lacks some motion I try to use.
I didn't mean to imply that Zsh was somehow more portable than Python. And I agree with the sibling commenter that Python is probably more portable than Bash.
I use Zsh for many of my personal scripts, but at work I would never even try to get it into one of our production containers.
I am very aligned with what you said but when it comes to shipping shell scripts (say sysops stuff, init, cron, ..) I tend to stick with the ksh/bash ecosystem mainly due to more tooling (shellcheck, shfmt, bats/bash_unit).
Most things that works in bash obviously works fine in zsh, but as the article very eloquently points out - lots of gotchas.
Yeah, zsh is great. IMHO Oh-my-zsh is the place to start, for those curious about its capabilities.
I sure love it when my shell takes seconds to load on startup.
I hear this argument from zsh purists all the time, I'm pretty sure it's made up. I've used oh-my-zsh for years with several plugins and the startup time is basically imperceptible. Maybe it's slow if you're running on raspberry pi or something.
~/.zshrc:L1:"zmodload zsh/zprof"
~/.zshrc:EOF:"zprof"
Doesn't take long to track down the culprits. nvm is a huge contributor to startup lag, IME. I am not a frontend dev, and rarely have to touch Node, so I comment out anything nvm-related for daily work.
It is easy to go overboard with oh my zsh for sure, but startup time, as long as it's less than ~5 seconds, is not likely to be a big problem for most people. On slower machines the real killer is the time it takes for the next prompt to appear after each command. There are mitigations, but I've definitely had machines where it is almost unbearable.
omz is very very heavy weight. Back when there was a freenode and #zsh it was widely hated as only IRC can hate something.
You can source
https://github.com/zsh-users/zsh-autosuggestions/blob/master...
https://github.com/zsh-users/zsh-syntax-highlighting/blob/ma...
without omz anyways.
Yes it is incredibly heavyweight, but it's very batteries-included in its approach, which helps zsh newbies get started.
For those who want to shed the heavyweight omz stuff, I recommend zplug [0]
Avoid oh-my-zsh like the plague if you value performance...
Here's a nickel kid. Buy a real computer.
I switched to fish a few years back after a couple decades of using bash. It took about 10 minutes to make that permanent everywhere ā because so much is built-in and the defaults are good, there was no need to spend time on more than the package install plus chsh.
For scripting, Iād already set a personal policy that anything complicated use Python. For me thereās a fairly big difference between interactive shell sessions and scripts which solidly shifts the balance to a full language with a rich standard library and robust error handling. My scripts were edited using shfmt and shellcheck interactively anyway, so switching to Python wasnāt an increase in terms of tool support and the richer language means that Iām writing less code to get more functionality and especially error handling.
Same here. It's just so ergonomic. For instance, here's how to make a fancy prompt in fish:
- Write a function called "fish_prompt" with "echo", "set_color", and whatever else you want.
- Put it in a file in fish's "functions" directory called "fish_prompt.fish"
That's it. Done. Every time fish needs to display a prompt, it does so by calling the "fish_prompt" function. Where does fish find the definition of a function called "foo"? In a file called "foo.fish".
Oh, do you want one of those very cool right-side-of-the-window prompts showing the date, maybe? Write a function called "fish_right_prompt.fish". There, you're finished.
There are a million little niceties like this that seem so obvious in retrospect. Fish is what happens when someone completely rethinks a shell from the perspective of how things should be done today after we have a few decades of experimentation under our belt.
Finally, a command line shell for the 90s
Iām glad that works for you but that sounds like a horrible solution to me. Maybe better than Bash but magic named files are probably my least favourite feature in scripting languages.
Don't think of it as magic, but as convention. Where do you put your function definitions? In the folder named "functions". There are only a handful of such things to learn.
Setting a specific path as an āautoloadā path to load shell functions is in bash and zsh too?
Fish doesn't work with a light theme. (Dark text on white background.) Also the keybindings in fish are extremely unergonomic.
Honestly I just want a bash that saves every command entered, ever, and never deletes history. (I think I can spare the 100 kilobytes of disk space to hold command history forever.)
And fish doesn't get this right either, even though it's a complete no-brainer. Sigh.
So no, I'm not a fan of fish.
`fish` is amazing. I used to have a big old dotfiles repo, but nowadays I add starship[0] to my env and I'm pretty much good to go.
On the non-interactive scripting front, I've found fish to be a very competent language for it, but you're right, the error handling (among other things) are lacking compared to "real" languages
[0]: https://starship.rs
I have to say, I use fish and I customize my prompt... is starship really necessary? I recognize starship is cross-shell, but if I standardize on installing fish on my machines, I'm not sure I need that feature.
Is there a "killer app" for starship that you can't get from writing out your prompt in a fish shell script?
Here's mine: https://github.com/maximum-ethics/linode-caddy/blob/master/r...
It's a 3-line prompt with a timestamp on the first line, my username@host + pwd on the 2nd line, and the actual prompt with the cursor on the 3rd line. I'm now considering swapping the timestamp to the right side after that possibility was mentioned in other comments in this thread.
Iāve been using fish for years and I love it. I have a simple prompt and a few functions that I share between all of the environments I have.
I've had this experience as well. My zsh config was a monster. fish was extremely easy -- starship and ready to go.
I used fish for around a year and a half and wound up switching back to zsh. fish's startup time is way too long for my tastes, and the devs seem completely uninterested in providing a "don't load plugins" flag. I open up new tmux panes/windows/etc all the time, so fish's slowness here is really noticeable. It also negatively affects using things like `tmux popup`, which spawns a shell. Things like this that take no noticeable time under zsh are sluggish under fish.
Interesting ā I picked fish because it was so much faster than zsh but I also run it pretty lean without much in the way of plugins.
I switched to fish for about six months, and recently went back to zsh when I realised that the three things I really liked about it (abbreviations, syntax highlighting and autosuggestions) were all doable in zsh with extensions [0]. (It feels pretty slow, even slower than say OMZ, but that's not such a big deal for me.)
[0] https://github.com/olets/zsh-abbr
While these are good examples of some of the fragile parts of bash, I think switching shells is the wrong approach in this case. If you find yourself dealing with binary data, floating point math, complex quoting, and so on...you probably shouldn't be scripting with a shell. Use Python, Perl, Ruby, or something else more suited to the task.
I don't agree with this. Shell syntax is uniquely flexible and powerful when it comes to composing pipelines. It often is precisely the right tool for the job.
Floating point math and "complex" quoting come up pretty often in a wide range of relatively basic tasks. Even something as simple as computing a percentage literally cannot be done in Bash without forking out to an external program. Sure, you could use a tool that does that one thing and does it well, or you could just have it in your shell and not worry about it.
The whole point about quoting is that it's hard to get right even when you're trying. It gets even harder when you are dealing with things like arrays and command substitution. You could switch to another programming language... or you could just use a shell that does these things right from the outset!
Minor nit, but you can compute integer percentages from integer inputs with bash, without shelling out to an external program.
You can also compute non-integer percentages by just adding the period after the math.
I used to say this, but Powershell has really proven to me that we need a shell that is also a good scripting language. Powershell has its faults, but it's as good as any scripting language, especially when time is a factor. And it does this without sacrificing its utility as a shell.
I haven't spent time with elvish but I think it's moving more in the right direction. Zsh and friends are better than bash but they are still too sh-like and a lot of those conventions are just always going to be problems.
There are all sorts of cases where you have a simple script that's perfectly fine, but you want to just add two fractions, or store a bit of binary data in a variable. I think those are reasonable expectations, and I don't think that "rewrite it to {Python,Ruby,...}!" is really a great solution (partly because for some simple tasks writing it in Python, Ruby, etc. is a lot more work). "If you want it, then this is not the right tool" doesn't strike me as a very strong argument for missing basic features such as this. For advanced complex features? Maybe. But not this.
I also don't think shell scripting is quite as bad as people make it out to be, or rather, one of the reasons people hate it is because they use bash or POSIX sh, and yeah, that gets problematic fast. The point of the article was to demonstrate that actually, you can solve a decent chunk of the problems and get something much less problematic without a lot of effort, while still retaining the key advantages of shell scripting.
However, even if we exclude all of scripting: you can't write your ~/.{bash,zsh}rc in Python, and it's useful for interactive usage as well.
Or use powershell and have all the power of C# at your finger tips and shell scripting at the same time!
Powershell does have some really cool shit as far as scripting languages go, but it's just so damn verbose.
It comes with a lot of aliases and does fuzzy matching on arguments. For example:
gci -r
Or use xonsh, which has all the power of Python and shell scripting at the same time!
Xonsh is damn impressive and I loved playing around with it. But it is really slow.
Off topic, but I do like powershell. The lack of a reasonable way to have it NOT pop a console window is regrettable though. What is provided still pops a console window, just for a shorter amount of time.
Massive pain point. Here's a workaround though: https://github.com/stax76/run-hidden
So I read this with a great deal of interest and nodded my head say āyes, thatās trueā at most of it. Despite this I just do not want to switch. Heck, first thing I do when I get a new Mac (now that ash is the default)is switch my shell to bash, install homebrew, then tmux, vim, powerline and git pull my dot files. I think maybe I am just old. Get off my lawn!
I am really working on not writing every little thing I want to script as a shell script. The other day I wanted to scan a dir of ~10k image files and move anything that was corrupt to another dir. I wrote it in bash and it worked. Then I was like, okay you should write this in python because you want to run it on 4 different OS. So I did. The code looks so much cleaner but was half as fast as the shell script. Oh well.
This is me as well - unabashedly a bash person. My reasons to not switch are not driven by the feature set offered by the various shells, but by the fact that I don't want to learn/think or be bothered with the nuances when I log in to various remote hosts, containers, and what have you. When I write shell scripts or installers, I want a single language that is reasonably likely to be present wherever it runs - and that today is bash.
Agreed - people have told me that other shells are better (and I'm sure they are better than bash in some ways) but for a shell, ubiquity is arguably the most important feature.
I agree. There's perfectly good scripting languages if I need to do anything beyond bash.
Also agree. For me, I want to be able to do simple "for each file run this command" loops in the shell. But if those loops get much more complicated than that then I switch over to Ruby.
*Tilt whisky glass your way.
"Bravo sir."
We had _just_ settled the emacs vs vi argument when this starts ...
I guess debian/ Ubuntu folks will choose bash, osx people will continue using zsh and the openbsd users will keep using that vanilla sh because of the vintage feel.
On a more serious note: I can't see my commands in manjaro thanks to all the bells and whistles. For some reason that situation reminds me of spacemacs users.
> I guess debian/ Ubuntu folks will choose bash, osx people will continue using zsh and the openbsd users will keep using that vanilla sh because of the vintage feel.
I believe that using zsh means, for the vast majority of users, using just a small subset of functionality that gives a better UX when compared to Bash.
Both me and my colleagues use zsh this way, and the times I've tried to figure out more advanced functionalities, it wasn't as simple as I expected.
I've read a few points of the article, and although they make sense as improvements, they apply mostly to the scripts domain. I don't recommend writing zsh scripts, because they're subtly different from the (unfortunately) standard that is Bash, besides not being supported (at least until a short time ago) by (the necessary) Shellcheck. If one wants a better experience for scripting, they're better off with a non-shell scripting language altogether (ie. Python).
> I believe that using zsh means, for the vast majority of users, using just a small subset of functionality that gives a better UX when compared to Bash.
What about adding only these functionalities you may care about?
When I tried zsh, what I liked was the history search. Like you, everything else "wasn't as simple as I expected". So I fixed my bash to add and expand what I had enjoyed!
Check https://github.com/csdvrx/bash-timestamping-sqlite :
- stores everything into a sqlite database so separate bash in separate terminals can access each other history on the go (without waiting for the session to end and the history being committed),
- add extra details to the history like when the command started, stopped, which with return code, in which directory (more on what that enables below),
- for accessing the history, uses fzy for fuzzy finding, (the one thing I mostly enjoyed in zsh, not zsh but fzy!!)
- provides 2 separate history search contexts: either global (ctrl-t) or "this directory only" (ctrl-r), with extra goodies like excluding commands with a non-zero return error code thanks to the extra things saved
I included a few examples of the SQL queries you can run.
Looks awesome. Thank you for building it.
> We had _just_ settled the emacs vs vi argument when this starts ...
We did? Thatās news to me!
Yes, we are all switching to vscode.
I switched from vscode to (doom) emacs. I don't know how it is now, but the vi-like key bindings of vscode were pretty bad at the time.
A decade ago after noticing such a conversation I'd have thought about and explored about which was better and which one to try and switch to; at least for few weeks until the novelty wore off.
I am older now (not sure smarter or lazier as well or both) and at this point I couldn't care less. As an Android developer I am essentially forced to use Android Studio - a rebranded IntelliJ and a shameless resource eater - it does the work and employer pays for better Macs every now and then, so it's good.
Who needs vscode when you can just hand write it and scan it?
On my case, it is more like being dragged into VSCode than actually switching to it by choice, specially when Microsoft makes some stuff available as VSCode plugins only (e.g. Powershell and ARM templates editing).
And still there are emacs users.
I'm just gonna use fish because I can't be bothered to setup zsh.
From the article... > P.S. maybe fish is even better by the way, but I could never get over the bright colouring and all these things popping in and out of my screen; it's such a "busy" chaotic experience! I'd have to spend time disabling all that stuff to make it usable for me, and I never bothered ā and if you're disabling the key selling points of a program then it's probably not intended for you anyway.
I have no idea what "things popping in and out of my screen" could possibly mean. I use Fish and it's a beautiful, calm experience.
It does all these "autocomplete" things; for example I type "ls" and then I automatically get "| less" after that (why "| less"? Not sure), also the colours of the text of what I'm typing is constantly changing based on what I typed.
I appreciate that some people really like this sort of thing and that great, but it's not for me ā I find it very distracting and "chaotic". Completion is brilliant, but I only want it on-demand (same with autocomplete when writing code).
Fish is really great for an interactive shell, I love using it. Not so great when it comes to scripting though. For example I think there's still no way to easily exit a script on error except to manually check exit codes.
However I haven't tried writing scripts in zsh yet, just sh/bash.
I couldn't possibly use a shell that wasn't also a decent shell script. It seems my natural progression is always:
1. "Hand written" commands in shell
2. Shell script with copy-pasted commands from interactive session
2b. Evolved shell script with getopt. Complexity level beginning to tickle the spidey sense that it's too big.
3. Node.js script (I can write Python but JS seems infinitely nicer)
fish would break the 1->2 transition, sending me straight to 3 before I've really gotten a handle on the problem domain.
Nothing precludes you from using bash scripts even if ysit fish interactively. Just set a shebang in the script, or run it with bash script.sh.
That said, personally, for anything more involved than a one-liner alias kind of script, I turn to python, or PowerShell on Windows.
I made dash my sh and started writing shell scripts targeting it instead of bash. If there's some bash-ism that can't be elegantly expressed in POSIX sh, it's time to bring out something like Python.
zsh can be a real pain to setup if you want a "performant" git status in your prompt. vcs_info is just too damn slow.
I prefer minimal customisation and so tend to stay away from heavy plugins like ohmyzsh, though I have friends who use it and really like it.
https://github.com/romkatv/powerlevel10k claims to do this (and other things) while remaining extremely fast (apparently the dev was aiming to keep it below the threshold of human perception; not 100% sure that extends to all features or not)
Use https://starship.rs/ and get a performant prompt that stays the same when you switch between bash, zsh and fish.
I suppose that's the nano equivalent:) And that's not the insult you might expect: It sometimes is viewed as a toy, but it actually has depth and does a lot more than one might expect, all while staying very user friendly, albeit at the expense of being rather different than the other major options.
Briging Korn shell into the party.
csh and tcsh dialled in.
The more the merrier.
What I like best about zsh is how easy it makes normal tasks.
* dont know the full name of the folder you want to cd into? Type the 1st few characters, and press tab, zsh will let you select which one you want
* Oh, and search is case insensitive. No more spending hours banging at the tab, wondering why autocomplete isnt working, just because you typed "projects" instead of "Projects"
* history search is great-- type the 1st few lines of a command and press up, it will take you to the last time the command was used
* Oh my zsh gives you a lot of cool utilities-- instead of
git commit -a -m "message"
I can do
gcam "message"
Moving to zsh was the best decision I made.
I feel obligated to point out that this is mostly doable with BASH.
* I don't understand how this is different than usual tab-completion; might just be missing something. You can stick `set show-all-if-ambiguous on` in .inputrc to make it activate on 1 tab instead of 2.
* `set completion-ignore-case on` in .inputrc
* https://askubuntu.com/questions/59846/bash-history-search-pa...
* `alias gcam='git commit -a -m'`, although I assume you're pointing out that it gives you a bunch of default aliases?
I'm glad you like ZSH, for those wondering if you can do similar things in Bash (lots of non technical folks on the site these days).
* I have to admit I tend to run mlocate on my systems and grep for full file paths instead of using tab completion if I don't know what the directory path is. However if you want auto complete with a list to pick from like ZSH bind 'set show-all-if-ambiguous on' bind 'TAB:menu-complete' in your inputrc will do the trick.
* echo set completion-ignore-case on | sudo tee -a /etc/inputrc (use .bashrc instead of input if you only want to set this for your own user)
* ctrl + r type part of your command history search in bash
* alias gcam='git commit -a -m'
ZSH definitely has a lot of cool things (globbing is really nice for instance), but Bash is ubiquitous and it's good to know how to make your life easier if you are working on a server that doesn't have your fave shell installed.
Happy hacking!
When I started typing this there were no replies, I got distracted by a work slack, and came back to hit submit, and there are two basically duplicates. An excellent reminder that none of us are actually the main character so to speak.
Control+r is search and not quite the same, since it matches everywhere rather than just at the start (maybe there's a way to do it, but I never liked the way C-r behaved in the first place so I never checked). However, you can use "history-search-backward" (and -forward) in your inputrc to get it.
I use zsh as well but most of what you highlighted is easily done in bash
> Oh, and search is case insensitive. No more spending hours banging at the tab, wondering why autocomplete isnt working
echo 'set completion-ignore-case On' >> ~/.inputrc
> history search is great-- type the 1st few lines of a command and press up, it will take you to the last time the command was used
CTRL+R and begin typing. CTRL+R again to go to next result.
> instead of git commit -a -m "message" I can do gcam "message"
echo 'alias gcam="git commit -a -m"' >> ~/.bashrc
Wait, are you talking about zsh or bash, because my bash have them all, what's next ?
> Click to see NSFW content. Not suitable for children under 18! click > For example, this can be used to show the longest element in an array: > print ${array[(r)${(l.${#${(O@)array//?/X}[1]}..?.)}]}
Got me there :^)
Perl?
> NUL bytes arenāt that uncommon, think of e.g. find -print0, xargs -0, etc. That all works grand, right up to the point you try to assign it to a variable.
Well, duh. Environment variables are NUL-terminated.
I don't understand arguments like this. "Learn something new so that you can avoid learning something old". None of the arguments on this page show me that zsh has a shallower learning curve than bash - only that zsh makes "more sense", once you've learned it, to you.
> Well, duh. Environment variables are NUL-terminated.
Shell variables aren't the same thing as environment variables.
Oh, great. Except uhh... they are.
Shell variables are inextricably tied to environment variables and frankly, making them uninheritable would make them less useful, not more.
They're not. Here's proof:
$ unset x
$ x=1
$ env | grep '^x='
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.