For someone who knows errexit can't be trusted, and codes defensively anyway, it's fine.
Shell script best practices, from a decade of scripting things
131–140 of 500 posts
Re: Shell script best practices, from a decade of scripting things
#132> Use bash. Using zsh or fish or any other, will make it hard for others to understand / collaborate. Among all shells, bash strikes a good balance between portability and DX. I think fish is quite a bit different in terms of syntax and semantics (I'm not very familiar with it), but zsh is essentially the same as bash except without most of the needless footguns and awkwardness. zsh also has many more advanced featur…
sh and bash feel pretty primitive after learning PowerShell.
Re: Shell script best practices, from a decade of scripting things
#133Re: Shell script best practices, from a decade of scripting things
#134Earlier quoted context omitted.
I see your point, but you can just as easily run "sh script" although that does imply that you already know that it's a shell script (obviously you wouldn't just run something from the internet without checking it first).
> obviously you wouldn't just run something from the internet without checking it first This died a long time ago with the pervasive use of NPM and PIP and the likes. Most developers probably run a lot of random unchecked shit all the time with local user privileges today without a blink. Somehow people are ready for all this, but are still afraid to run a random shell script from the internet. I guess this fear is o…
Re: Shell script best practices, from a decade of scripting things
#135Re: Shell script best practices, from a decade of scripting things
#136Re: Shell script best practices, from a decade of scripting things
#137Re: Shell script best practices, from a decade of scripting things
#138Earlier quoted context omitted.
I see your point, but you can just as easily run "sh script" although that does imply that you already know that it's a shell script (obviously you wouldn't just run something from the internet without checking it first).
> obviously you wouldn't just run something from the internet without checking it first This died a long time ago with the pervasive use of NPM and PIP and the likes. Most developers probably run a lot of random unchecked shit all the time with local user privileges today without a blink. Somehow people are ready for all this, but are still afraid to run a random shell script from the internet. I guess this fear is o…
Re: Shell script best practices, from a decade of scripting things
#139Earlier quoted context omitted.
If you download a script then running "sh script.sh" is a lot quicker and easier than a chmod followed by ./script.sh. You can of course also type "bash script.sh", but I don't always have it installed on every system, and the .bash extension just clarifies it. For things in my PATH I drop any suffixes like that.
I see your point, but you can just as easily run "sh script" although that does imply that you already know that it's a shell script (obviously you wouldn't just run something from the internet without checking it first).
I don't check everything I download from the internet; I don't think anyone does. It depends on what it is, where I'm getting it from, where I'm running it, etc. There are certainly some things I will review carefully, but other things I give just a quick check to see it's not in complete shambles, and others I barely check at all. I typically run the latest Vim from master, do I check every patch to see if after 30 years Bram finally sneaked in a crypto miner or password stealer? Do the people who package Vim for the Linux distros?
Re: Shell script best practices, from a decade of scripting things
#140I'd also say that in most cases Python is also a better choice, especially when you use the ! syntax.