Earlier quoted context omitted.
I think it's time people start using something better than bash/zsh that is decades old, like fish or even come up with a more modern shell. Even by looking at these examples, you see it has less verbosity like "then" and "do", you can reference arguments as $argv instead of cryptic $@ and exit status code as $status instead of $? which is confusing with $! and the likes. https://blog.codeship.com/lets-talk-about-she…
I think a big issue is that bash is available everywhere, while fish might not be. There's also the fact that a lot of us have fancy dotfiles for our work/home computers, and switching to another shell would mean having to rewrite them in the target shell language.
Safe ways to do things in bash
171–180 of 255 posts
Re: Safe ways to do things in bash
#172Earlier quoted context omitted.
I think it's time people start using something better than bash/zsh that is decades old, like fish or even come up with a more modern shell. Even by looking at these examples, you see it has less verbosity like "then" and "do", you can reference arguments as $argv instead of cryptic $@ and exit status code as $status instead of $? which is confusing with $! and the likes. https://blog.codeship.com/lets-talk-about-she…
I think a big issue is that bash is available everywhere, while fish might not be. There's also the fact that a lot of us have fancy dotfiles for our work/home computers, and switching to another shell would mean having to rewrite them in the target shell language.
You can simply import aliases as is and in some cases, you may be able to even simplify parts of your config.
Personally, it was easy for me as I'm administering the servers and it was all just installing fish on every servers. (some dozens.)
Re: Safe ways to do things in bash
#173Earlier quoted context omitted.
I think a big issue is that bash is available everywhere, while fish might not be. There's also the fact that a lot of us have fancy dotfiles for our work/home computers, and switching to another shell would mean having to rewrite them in the target shell language.
Availability is a big issue. It is nearly impossible to get a seasoned sysadmin to install fish for you when bash is available.
Re: Safe ways to do things in bash
#174" Should I use backticks? Command substitutions also come in this form: Correct: "`cmd`" Bad: `cmd` While it is possible to use this style correctly, it looks even more awkward in quotes and is less readable when nested. The consensus around this one is pretty clear: Avoid." This is how one can tell a rookie just learning to program in shell: usage of $() syntax is limited to Bourne family of shells which implement t…
The '$()' notation is a standard shell feature de facto. The fraction of people who care about their script working on all UNIX-like operating systems' default shells is very close to 0. The recommendation is fine - this notation is more readable and nestable.
> "Always test your shell code on a traditional UNIX like HP-UX or a Solaris derivative like SmartOS if possible, with a real Bourne shell."
Only if your script needs to be "original Bourne shell" compatibile. Which is almost never for most script writers.
Re: Safe ways to do things in bash
#175I've written a ridiculous amount of shell script in my day, especially when doing "devops" before we had a term like "devops" to describe it. I've fallen in almost every pit bash has. With that background, here is my opinion. 1. This article contains excellent advice and should be starred for later retrieval. 2. Having basic scripting skills will make you a way better programmer. Many times I've done huge refactors a…
I think it's time people start using something better than bash/zsh that is decades old, like fish or even come up with a more modern shell. Even by looking at these examples, you see it has less verbosity like "then" and "do", you can reference arguments as $argv instead of cryptic $@ and exit status code as $status instead of $? which is confusing with $! and the likes. https://blog.codeship.com/lets-talk-about-she…
Re: Safe ways to do things in bash
#176" Should I use backticks? Command substitutions also come in this form: Correct: "`cmd`" Bad: `cmd` While it is possible to use this style correctly, it looks even more awkward in quotes and is less readable when nested. The consensus around this one is pretty clear: Avoid." This is how one can tell a rookie just learning to program in shell: usage of $() syntax is limited to Bourne family of shells which implement t…
Re: Safe ways to do things in bash
#177Earlier quoted context omitted.
It's time we need a better shell than bash instead of thinking it's great after bleeding with it for years and gets used to it.
I’d vote for PowerShell in a heartbeat. It passes real objects instead of strings. It’s cross platform and open source. It’s imperative but borrows some functional concepts.
Re: Safe ways to do things in bash
#178I've written a ridiculous amount of shell script in my day, especially when doing "devops" before we had a term like "devops" to describe it. I've fallen in almost every pit bash has. With that background, here is my opinion. 1. This article contains excellent advice and should be starred for later retrieval. 2. Having basic scripting skills will make you a way better programmer. Many times I've done huge refactors a…
I think it's time people start using something better than bash/zsh that is decades old, like fish or even come up with a more modern shell. Even by looking at these examples, you see it has less verbosity like "then" and "do", you can reference arguments as $argv instead of cryptic $@ and exit status code as $status instead of $? which is confusing with $! and the likes. https://blog.codeship.com/lets-talk-about-she…
Re: Safe ways to do things in bash
#179I've written a ridiculous amount of shell script in my day, especially when doing "devops" before we had a term like "devops" to describe it. I've fallen in almost every pit bash has. With that background, here is my opinion. 1. This article contains excellent advice and should be starred for later retrieval. 2. Having basic scripting skills will make you a way better programmer. Many times I've done huge refactors a…
I probably have a similar history but I've come to the belief that you should not use Bash if you're doing anything fancy or long (>10 lines). Just use Perl, Python or Ruby. One or all of them is installed on every machine you are likely to use.
I'd really like to use Python more often, but most of the time it only complicates things with those verbose syscalls.
Re: Safe ways to do things in bash
#180Earlier quoted context omitted.
This is ran behind PowerDNS, which handles the compression prior to handing off to this code, so that shouldn't be a problem.
Which means it’s not really doing any of the heavy lifting.