s/bash/zsh/g
arp242.net
arp242.net
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.
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.
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.
For scripts, you can still use bash or zsh or python or whatever you want.
I prefer to keep my utilities scripting and interactive shell the same. That way I don't have to keep two sets of gotchas in my head, and don't accidentally use the wrong syntax in one place or the other sometimes leading to confusing misbehaviours.
While I don't mix bash/zsh/sh/... I will consider python/node/other if I need specific things that they do well or I'm making something more than a simple tool or automation (for which bash is either underkill or just thoroughly unsuited). They are sufficiently different that I'm not going to cause myself the sort of mix-up I might with flipping between shell scripting syntaxes.
[1] https://fishshell.com/docs/current/design.html#configurabili...
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 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.
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.
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.
Most things that works in bash obviously works fine in zsh, but as the article very eloquently points out - lots of gotchas.
Also useful would be a tool that tells me if I'm using a zsh construct that isn't supported in bash... or even better, how to do it in bash
~/.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.
There's a --no-use flag that short-circuits all the heavy startup processing, but still gives you access to the command.
Here's a snippet from my zshrc: ``` export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" --no-use export PATH="$HOME/.nvm/versions/node/v14.17.6/bin:$PATH" ```
My Node-related macOS terminal setup:
- iTerm.app
- zsh (via brew)
- n-install -> n -> node (/npm)
- yarn (via npm i -g)
- pnpm ("")
HTH! :)
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.
For those who want to shed the heavyweight omz stuff, I recommend zplug [0]
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.
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.
bindkey -v '^R' history-incremental-search-backward
It's like the zsh folks said, "I like those vim guys".
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.
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?
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 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.
TIL zsh is even better than zsh!
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.
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
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.
Alt+Up is great for recalling individual arguments, but am I missing something or is there no way to recall a whole previous line in-place, without overwriting what’s currently on the command line?
Seems to work in bash too, fwiw.
[0] https://fishshell.com/docs/current/interactive.html#copy-and...
On the other hand, you can disable all these advanced features in zsh and get something a bit closer to a bash readline shell, with a few extra features. That's what I use.
- 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.
Inside ‘function’ blocks, like the language syntax defines for any other type of function. I can then throw those functions into any file I chose.
Having special functions inside special files just creates annoying special cases I need to look up.
That's the only remotely magical thing added here: by convention, an autoload function named "foo" is defined in ~/.config/fish/functions/foo.fish.
Now I’ve got nothing against git hooks nor Fish per se, I just don’t see this particular model for defining behaviour to be convenient (eg what if you want to quickly change the prompt of a session without affecting other sessions?)
There might be more detail I’m missing and if that’s the case I apologise. But from what I’ve read thus far I’m not sold. It might appeal to others and good for them.
There's also this package, which the author admits only allows "slight" customization, to implement sessions: https://github.com/farzadghanei/fishion
https://murex.rocks/docs/commands/config.html
You can set prompt functions with that; strings, ints and Booleans too. And ‘config’ comes with descriptions for each configurable thing, choices of options in many cases, and an easy way to default back to shell defaults too. So it’s dead easy to play around configuring whatever you want (you never need to leave the shell to look up an option).
The shell has its own problems though but it’s an interesting alternative take for grouping shell config.
They don't. You have to define the function somehow, but fish doesn't care about how that happens. It's just that if it's not defined yet it'll try to load it from the file.
If you want, you can just do it all in config.fish, like you'd do it all in .bashrc for bash.
>what if you want to quickly change the prompt of a session without affecting other sessions?
Then you can redefine the function, just like you could switch the value of $PS1.
https://fishshell.com/docs/current/cmds/fish_command_not_fou...
So yeah you could make crazy stuff like Rail's routing and rendering DSLs that interpreted method names as programs.
It's meant to give you a nice error message like
"foo is missing. You can install it with 'apt install foo123'"
See:
- https://zsh.sourceforge.io/Doc/Release/Command-Execution.htm... for zsh
- https://www.gnu.org/software/bash/manual/bash.html#Command-S... for bash
You could make it run arbitrary things, but then you're quite clearly misusing it and e.g. there's no way to make it return a different status, fish will still view the command as failed.
Don’t get me wrong, I think the PS1 variable sucks. But I’m not convinced Fish’s solution is much better.
You can achieve PS1-like functionality “simply” by placing this bit of code somewhere in your startup:
function fish_prompt
set -l prompt_symbol '$'
fish_is_root_user; and set prompt_symbol '#'
echo -s $hostname (set_color blue) (prompt_pwd) \
(set_color yellow) $prompt_symbol (set_color normal)
end
Even as someone who doesn’t use fish day to day, I think fish’s prompt customization is much more approachable. If I had a powerline prompt I wanted to tweak, I’d know to start with `functions fish_prompt` to print out the current contents of the function and have the complete code to how the prompt is built. zsh requires a lot more reading and understanding of the prompt system before you can dig into how exactly it all works. IIRC, most dynamic bash prompts have similar issues. PS1 is just interpolated globals and color codes, creating a disconnect between the prompt variable and the shell functions that update it.
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.
[0] https://github.com/olets/zsh-abbr
Not sure if fish has this or not, but I use reverse search in bash exhaustively.
There's no need to enter a separate mode via ctrl-r.
https://fishshell.com/docs/current/interactive.html#searchab...
I find it to be more polished and especially like the way it works with fragments (e.g. if you start typing "git log" and hit Option/Alt-ꜛ it will find commands prefixed with that whereas bash Control-R requires you to hit Control-R first and then type that, which isn't as handy when you realize you want to search halfway through).
I'm guessing someone probably has a plugin for it or people just get used to using autosuggest
I feel torn because I really can empathize with making a clean break. But it also precludes a lot of people from making the shell a daily driver when your co-workers are shoving shell scripts your supposed to source into your env into github, lol.
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!
gci -r
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.
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.
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.
"Bravo sir."
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.
We did? That’s news to me!
Hmm, in this false analogy game, what editor is aligned with korn shell? xemacs?
OpenBSD (as well as the others?) come with pdksh and nvi out of the box.
I feel attacked. In all seriousness: so long as you have a POSIX shell available (and set as default), you don't have to use a POSIX shell. I rarely do anything with fish syntax because I mostly use it for the REPL experience.
vi (not vim), preferably running on OpenBSD :)
I tried learning to use Org-mode as a Markdown replacement over Doom Emacs. At some point, I switched back to vscode+Markdown and it felt like a breeze. I'm not a SWE, so the payoff would've probably taken too long to happen.
I also tried using the Maxima mode for Emacs as an interactive CAS. The only thing I got was Latex-formatted output and the same Emacs-like key bindings that you get in any terminal emulator. No auto-suggestion/Intellisense to help you navigate and avoid learning the API, so I wasn't overly impressed.
But yes, I'm 100% convinced that it's not for everyone, and depends a lot of the quality of the integration/mode of your specific use case.
I also switched from vs code to doom emacs though, just because I wanted to.
$ cat > file.c <<EOMI 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.
Back then, I would then keypunch them the next time I was on campus and could access a keypunch machine. Writing even a modest 1000 line program was quite a chore because you'd have to carry around a box of 1000 cards and keep them from getting mixed up. Here's a picture of a full 2000 card box[1]; notice how we used to write diagonal lines on the edges of the cards to help put them in order after spilling the box on the floor!
See [2] for a picture of the first kind of keypunch machine I ever used, the IBM 026. The subsequent model, the IBM 029, was much better.
Of course the turnaround time wasn't measured in seconds back then. Once, I was given an assignment that required writing a program in IBM 360 assembler, it was the first time I ever had to write assembly language. With the aid of IBM's excellent manual, IBM 360 Principles of Operation, I hand wrote this program, went to campus to keypunch the program, and turned it in for one of the seven scheduled overnight submissions we were allowed. After around the fifth attempt I was starting the think that I wouldn't get credit for this assignment; miraculously, on my seventh and last submission the program finally worked.
[1] https://upload.wikimedia.org/wikipedia/commons/thumb/8/86/Pu...
[2] https://en.wikipedia.org/wiki/File:Keypunching_at_Texas_A&M2...
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.
Using it is very high value-for-effort.
However I haven't tried writing scripts in zsh yet, just sh/bash.
That said, personally, for anything more involved than a one-liner alias kind of script, I turn to python, or PowerShell on Windows.
You and submitter (who according to CV is proficient in Python) might like Oilshell.
I agree with this. If you can trust your users to have python3 in their environment, I don't see a good reason to use sh/bash instead of python. Non-trivial shell scripts are unreadable to me, and the semantics are too different from normal programming languages.
The only scenario I can see is a script that has to call multiple commands over and over, which can be a pain in python if you're piping a lot of stuff and all that. No, piping grep to cut and sed doesn't count; you can do that in python itself.
You would need to ensure said users have all the pip dependencies your python script imports as well. shell scripts don’t have that issue unless you’re calling some external program that isn’t installed.
Good thing that bash has such an extensive amount of standard libraries and that you're almost never calling external programs? And unlike Python, which is seemingly almost exclusively calling third-party libraries from PyPI?
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.
Ruby'd be my pick for "most-pleasant scripting language" so long as I can avoid any libraries/frameworks that do too much metaprograming "gee, wouldn't you love to never be able to track down where this is defined?" crap. Maybe Lua, but deps are a bit of a pain to manage there, and it's a huge step down in third party library availability compared with the other three languages here mentioned.
Really, if not for up-to-date library availability being higher in other languages, I'd probably still be using Perl for everything. It feels more "command-line native" than the other options. Installed everywhere. The community's not too in-love with trendy, cute bullcrap. A project you wrote five years ago will probably still run fine with no effort. It's kinda like supercharged bash with way fewer footguns.
I don't think anyone would make something quite like it these days, starting form scratch.
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.
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).
Pretty sure it's autocompleting the last thing that you executed that started with "ls".
Anyhow, doesn't really matter shrug.
It might be nice when you're getting started, so you don't have to learn all the ins and outs of the shell to have cool prompts and other useful functionality.
E.g. oh-my-zsh adds a bunch of keybindings and a git prompt, and sets a bunch of options (like turning on history deduplication, or comments in interactive sessions).
Fish already does equivalents of much of that, by default, so oh-my-fish doesn't have to do it. They mostly add more prompts (with their own, separate, git prompt implementation) and provide a package manager.
That means fish without oh-my-fish is already close to the experience of zsh with oh-my-zsh.
(disclaimer: I'm a fish developer, and not really involved with oh-my-fish - I sent a few courtesy patches over the years)
~ > omf
fish: Unknown command: omf
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).
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.
* 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 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?
> 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
* 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.
Got me there :^)
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.
Shell variables aren't the same thing as environment variables.
Shell variables are inextricably tied to environment variables and frankly, making them uninheritable would make them less useful, not more.
$ unset x
$ x=1
$ env | grep '^x='
Yes.
> and common
Not even remotely.
> Variables silently dropping off characters causes problems for these use cases.
Sure, you should just silently drop it off when you export it instead, because that makes far more sense.
> Not even remotely.
Real world code from numerous prominent open source projects begs to differ. Almost every random script I've opened in random open source projects made use of unexported shell variables. Take a look at the source repositories of the Linux kernel, Git, coreutils, GCC, LLVM, CMake, GDB, cURL, OpenSSL, Firefox, Chromium, Vim, and tmux. It's so prevalent that I don't even know why I have to point this out.
I use fish shell mostly these days. Magic autocompletion is life-changing.
1. Install prereqs with package manager (curl, git, zsh, vim)
2. Download and install oh-my-zsh
3. Pull .zshrc, .vimrc, etc. from Github
4. (optional) Add workarounds because Windows Terminal still can't handle color and cursor position codes.
I've heard of some things not working in other shells, and since bash works for the things I use it for, I have no reason to change.
I would set the hashbang to "#!/usr/bin/env bash" and then bail out if $BASH_VERSION isn't set on the first line, while also naming the script "foo.bash" (rather than foo.sh).
This way you can "enforce" a specific interpreter. Scripts using #!/bin/sh while relying on bash features was a common annoyance when I used FreeBSD – although it's probably less common now that some Linuxes have started using dash and /bin/sh. I don't mind if people use bash, but please make it explicit, especially because these types of errors are not necessarily obvious to the user.
bindkey '^[' complete-word
You may want to set lower KEYTIMEOUT too, so it doesn't wait as long for further keys after an escape. I'm not sure what the default is.
I _LIVE_ in the CLI. 90% of my day. And I have anywhere from 2-8 terminal windows open at a time.
I've automated what can be automated, so I'm not doing this out of ignorance.
I prefer the CLI too. every CLI based program I use is more performant then a GUI counter-part.
If ZSH solves 10% of my BASH headaches then that equals a HUGE reduction in the effort of doing 'work'.
It's ok that you don't like the CLI.
Practically, I find myself typing `irb` before every quick arithmetic session anyway... but w/e.
I use those functions in both scripts and my interactive shell (which is bash).
I cannot do the same with zsh as my interactive shell if scripting is supposed to stay POSIX/bourne shell. Which I want as I often do this in systemwide scripts or modify existing scripts (all plain sh). The incompatibilities do matter.
where sh is NetBSD's ash, with command history
### cwd: /some/path
cd /home/user/mysvc
…
cd /etc/systemd/system
…
sudo ln -s /path/to/mysvc.service
…
git pull
…
sudo systemctl restart mysvc
…
tail -f /path/to/log.txt #! lines=10 nowrap autorun
…(10 lines)
Before I used to also have a per folder history file, so I could pull up the last thing I did there. That also helped a lot, especially when switching between different personal projects and forgetting how it all works.
The test I prefer to do with python.
My conclusion is that it looks like the author wants to use a shell like a programing language.
But zsh doesn't even use readline, which is bananas to me. Sure, provide an alternative but at least support readline.
Why? ZLE is what makes zsh compelling for users. It provides a high level of customizability into command line editing that is simply not possible with bash. It powers zsh's most touted completion feature as well as popular plugins such as zsh-syntax-highlighting[1] and zsh-autosuggestions[2]. Replacing it with readline would be a sure way to lose a majority of users in a blink of an eye.
I don't want to have customize each tool individually.
You do realize this is open source, right?
Here's a non-exhaustive list that immediately come to mind:
bash
rc
psql
bc
ftp
GDB
GPG
Guile
Lua
NetworkManager
Parted
Python
Ruby
SQLite
wpa_supplicantAbsolutely not. Using readline means completion and keybinding customization would be limited to what bash can do, or even worse as is typical with other readline based REPLs. What you're asking for is to gut a definitive feature of zsh only so that it can be bash. That provides zero value to zsh users.
Nailed it. It's perfectly okay that bash doesn't have every feature under the sun because it's main goal is to let the user interact with the OS, which includes calling the right program for the right job.
If you want to write scripts for your personal use, or maybe for some project you have then I recommend zsh as it's so much more useful and easier. The zsh User Guide is quite good by the way (not updated in a long time, but still relevant).
I you want to write shell scripts at $DAYJOB or some such bash is probably the wiser choice, as it's just more common. Whether that's a good or bad thing is kinda besides the point here; it just is.
For scripts? Use Posix sh.