Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shell script best practices, from a decade of scripting things

sharats.me

Post reply on HN
Print view View original

51–60 of 500 posts

Re: Shell script best practices, from a decade of scripting things

#51

Post by Beltalowda »

benreesman wrote: post #32
Beltalowda wrote: post #19

> 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…

A little personal color: I’m kind of a terminal tweak-fanatic but I’ve stuck with bash. Ten years or so ago the cool kids were using zsh: which is in general a pretty reasonable move, it’s got way more command-line amenities than bash (at least built in). Today fish is the fucking business: fish is so much more fun as a CLI freak. But I guess I’ve got enough PTSD around when k8s or it’s proprietary equivalents get st…

I personally really dislike fish as an interactive shell as it's just so busy. Things keep popping up, everything is in so many different colours, etc. It's great if you like that sort of stuff, but I really appreciate a "quiet" environment. This is also why I use Vim: all the IDEs I tried are just so "busy".

I was only talking about scripting; I know fish scripting is different, but I have no idea if it's any good. For interactive shells I don't care what people use: it's 100% a personal choice.

Re: Shell script best practices, from a decade of scripting things

#52

Post by hdjjhhvvhga »

selectnull wrote: post #34

> Use the .sh (or .bash) extension for your file. It may be fancy to not have an extension for your script, but unless your case explicitly depends on it, you’re probably just trying to do clever stuff. Clever stuff are hard to understand. I don't agree with this one. When I name my script without extension (btw, .sh is fine, .bash is ugly) I want my script to look just like any other command: as a user I do not care…

> .bash is ugly

"Ugly" is subjective. If I encountered a file with that extension, I'd assume it uses Bash-specific features and that I shouldn't run this script with another shell.

Re: Shell script best practices, from a decade of scripting things

#53

Post by wruza »

laserbeam wrote: post #30
grumbel wrote: post #18

What would be the justification for 'cd "$(dirname "$0")"'? Going to the scripts directory does not seem very helpful. If I don't care about the current directory, I might just go to '/' or a temporary directory, when I do care about it I better stay in it or interpreting relative command line arguments is going to get difficult. When symbolic links are involved, dirname will also give the wrong directory.

To be fair, it's common to want to be in the script directory for certain classes of scripts. For example, scripts which automate some tasks in a project, and are written for a project. But, more importantly, people will google for how to set cwd to the script directory more often then will google how to go to an absolute path. Having 'cd "$(dirname "$0")"' as reference in an article discussing best practices and the…

And for certain classes of users, certainly. If I were in $prj/some/dir and called “../../script.sh foo”, I’d expect it to operate on $prj/some/dir/foo, not on $prj/foo. The latter would be a confusing practice, not even remotely the best one.

people will google for how to set cwd to the script directory more often

The answer should suggest setting $script_dir instead of chdir and refer to it when needed, explaining why chdir is a wrong shell mindset except for a very few special cases. It’s okay for personal use, but inheriting such scripts would be an awful experience, imo.

Re: Shell script best practices, from a decade of scripting things

#56

Post by nephrite »

selectnull wrote: post #34

> Use the .sh (or .bash) extension for your file. It may be fancy to not have an extension for your script, but unless your case explicitly depends on it, you’re probably just trying to do clever stuff. Clever stuff are hard to understand. I don't agree with this one. When I name my script without extension (btw, .sh is fine, .bash is ugly) I want my script to look just like any other command: as a user I do not care…

In my setup, I use aliases or functions to have short/mnemonic names for commands. But the files on disk must always have proper extensions like .sh to quickly see what they are.

Re: Shell script best practices, from a decade of scripting things

#57

Post by ndsipa_pomu »

lockedinspace wrote: post #33

This is not a best practices guide, please look forward to: https://mywiki.wooledge.org/BashGuide For example, using cd "$(dirname "$0")" to get the scripts location is not reliable, you could use a more sophisticated option such as: $(dirname $BASH_SOURCE)

This is the way.

I'm more likely to use the BashFAQ though for actual snippets: https://mywiki.wooledge.org/BashFAQ

I start scripts from the very useful template at https://bash3boilerplate.sh/

Re: Shell script best practices, from a decade of scripting things

#58

Post by chriswarbo »

rockyj wrote: post #25

Speaking of shell, which language do you think has the best interoperatibility with shell commands. I mean, running a command, parsing the output, looping, adding user interaction etc. with the least amount of friction. Ruby used to come close for me, just put the command in backticks `` and write the main logic in Ruby, but I want to hear if there is something better.

I like scsh (Scheme shell). A more recent/maintained alternative is Racket's shell-pipeline package https://docs.racket-lang.org/shell-pipeline/pipeline.html
Post reply on HN