Bash is a programming language you don't want to use, but end up using anyway. Any effort to make it a bit less clunky and maybe even a bit saver is welcome.
I was rockin' a fancy zsh config on my devbox until I started doing more ops work and traipsing around foreign servers. My muscle memory became useless and back to bash it was.
I'm considering adding Zsh to the base install of all my servers, since it's so useful to be able to write a script with something like
*(om[1])
for the most-recently-modified file, or
$i:l
to get a variable in lower case. I do deploy a .bashrc with some shell aliases, which are the most annoying things to miss when I'm used to using them locally.
I've never understood how people can insist on super fancy custom configs, it is so normal to burn through servers. Just learn the defaults, life is way easier...
It is so normal for sysadmins. Not for developers. Maybe it's more normal now, but that's a recent development.
(These days, I hope I can just develop my super fancy Emacs config in one place, and use TRAMP to work with remote machines through an environment customized for me.)
Some people think we don't need sysadmins nowadays. It's all in the cloud nowadays so we only need developers and some of them can do devops. Then you end up with systems where people all log into the same user with a shared SSH key, who has sudo root access, and access everything by IP address because who needs DNS, where there's no automated or regular patching because we just roll a new release with a new systems image because everything is ephemeral, or I mean will be ephemeral when we are done with it and in the mean time perhaps someone will run ansible on it again if they are brave since no one has run it again since system build. Oh and we are on call because we get outages since the disk space fills up since who needs to monitor and automatically manage that sort of thing if we never use persistent storage.
Throughout my career in dev I have always had to have a presence on sometimes dozens of servers. If something can't be fully customized in a few keystrokes it is not worth the effort, especially if whatever is being customized gets thrown away.
You'd be surprised how different dev careers can be.
In Windows land it's quite frequent that the dev never leaves Visual Studio. In Eclipse/Java land something similar, even though often the deployments would be on Linux, for cost saving reasons, the devs would all be on Windows.
I should write a blog post or something at some point about the differences in dev careers. Enterprise software development is very different from embedded software development which is different from web development for the mass market which is different from mobile development, etc.
And then those Java developers have to try to interface their code to Jenkins to get it to do CI, and the sysadmins have to deal with the Java guys who just click on the "Run" button in Eclipse and don't know basic things like what directory the code needs to execute from.
Don't get me wrong, those Java developers can be great guys, but when the GUI-only people have to interact with the CLI for the first time, all sorts of problems can manifest themselves.
I understand this as 3 categories of deployment size:
- you've got 1 server you visit rarely so don't care about the server shell
- you've got <10 servers you care about and try to replicate your shell config (because you use it daily)
- you've got >10 servers and you almost never log into them because the logs, metrics and deployment are exported to a centralised system... so you don't care about the server shell
If you have a central home directory that is mounted on every server via nfs and zsh is installed everywhere or if you have setup some (semi-)automated file syncing/deploying and develop just on one machine that is setup correctly, then why not?
The main reason for programming Shell/Bash for me is, because its available on the tiniest of Systems, like initramfs, or routers. There aren't many options for scripting. But I also don't know if Bash Infinity makes sense there. So while this project looks interesting, I don't see me using it anytime soon.
It's the same reason for favoring defaults. They are universal, and everywhere, and lets one get to work immediately. Constantly porting over customizations just so a spoiled butt can work comfortably gets tiresome. It's even easier than fussing about trying to automate the whole thing...
Bash is intentionally scoped to be small. The language seems almost intentionally difficult to grok for large projects. There are very few legitimate use cases for large bash scripts, in my opinion, and frameworks only make that harder to see. Javascript also started scoped small, but it was everywhere, and look at it now...
> There are very few legitimate use cases for large bash scripts, in my opinion, and frameworks only make that harder to see. Javascript also started scoped small, but it was everywhere, and look at it now...
Maybe the meaning of "large" depends on familiarity, but somehow, a big part of UNIX/Linux is a pile of large bash scripts...
zsh is quite fun to use tbh and it's worth the pain of not having it on some remote boxes IMO (and I'm working on getting most of those on zsh via Ansible)
I certainly get it. Zsh and the like offer some really nice functionality missing from standard bash. However that muscle memory is lost. Zsh etc. certainly cool for your own tinker box. Not good when dealing with lots of disparate systems. I don't even like to use a lot of aliases because of this.
Same here with zsh. I switched my laptop shell to bash since working all the time in the interpreter at the shell prompt makes me better able to write bash scripts. I don't particular want to deal with the minor syntactic differences of zsh, or the totally different fish, seeing as I have to know bash well.
Bash is a programming language you don't want to use, but end up using anyway. Any effort to make it a bit less clunky and maybe even a bit saver is welcome.