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

141–150 of 500 posts

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

#141

Post by erlkonig »

pindab0ter wrote: post #122
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…

There are use cases where you don't have execute privileges. In those cases the .sh-extension makes it clear that you can do `bash script.sh`. If you don't use an extension you wouldn't easily see that that was an option.

No, it doesn't. The extensions are usually too inaccurate to rely on. That could be either a Bourne or Bash script, meaning it could either fail at some arbitrary point during run if the wrong one is used, or just subtly, critically change some output. Much more true for Python scripts.

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

#142

Post by sharat87 »

bheadmaster wrote: post #45

> For copy-paste: if [[ -n "${TRACE-}" ]]; then set -o xtrace; fi > People can now enable debug mode, by running your script as TRACE=1 ./script.sh instead of ./script.sh. The above "if" condition will set xtrace even when user explicitly disables trace by setting TRACE=0. A correct way of doing this would be: if [[ "${TRACE-0}" == "1" ]]; then set -o xtrace; fi

Excellent point. Thanks for this. Fixing it.

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

#143

Post by erlkonig »

nephrite wrote: post #56
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.

The extensions are improper from the outset. Commands should not have extensions.

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

#144

Post by sharat87 »

Xophmeister wrote: post #105

There's a bug in his template. He suggests to `set -eu`, which is a good idea, but then immediately does this: if [[ "$1" =~ ^-*h(elp)?$ ]]; ... If the script is given no arguments, this will exit with an unbound variable error. Instead, you want something like this: if [[ "${1-}" =~ ^-*h(elp)?$ ]]; then

Good catch. Fixing it.

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

#145

Post by Woeps »

moritonal wrote: post #140

If you are on Windows or Linux, Powershell is a decent scripting language that comfortably replaces Shell for scripted task running. The commands are vastly more readable and you get an okay experience with branches. I'd also say that in most cases Python is also a better choice, especially when you use the ! syntax.

The issue I have with powershell is the extreem verbosity.

But that's just a personal thing and not something that I can realy blame the language.

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

#147

Post by erlkonig »

Octabrain wrote: post #65
hdjjhhvvhga wrote: post #52

Earlier quoted context omitted.

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

Subjetive, indeed. But unless I am missing something, the interpreter to be used should be determined by the shebang within the script though?

It's the effect of the extension on USER behavior that's the problem, the OS doesn't care.

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

#148

Post by Beltalowda »

alwillis wrote: post #110
naniwaduni wrote: post #78

Earlier quoted context omitted.

zsh is, historically, a step from csh-like interactive shells in the direction of Bourne/ksh compatibility. It's easy to get the impression that zsh is a newer development than bash, but they're actually contemporary—bash rode on the popularity of GNU in the 90s, despite being a "small evolution" (frankly, a step back) compared to the ksh lineage.

It certainly didn’t hurt the popularity of Bash by having it be the default shell on tens of millions of Macs for so many years. I’m aware that ZSH has been the default shell since Catalina. Started using fish a month ago and really liking it.

tcsh was the default shell before that, and it didn't help much with its popularity, and for interactive usage tcsh can do most of the things bash can and is mostly okay (not scripting though).

I think being the de-facto default on Linux as part of "GNU plus Linux" has more to do with it.

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

#149

Post by Ultimatt »

nousermane wrote: post #146

About that "#!/usr/bin/env bash" business - are there any systems out there that have "/usr/bin/env", but do not have "/bin/bash"?

That you've asked this question means you don't understand the actual reason to do this. I might have my own bash in my home I use to run all my shell scripts, why are you ignoring my environment and going for the system shell? Unless you control the system or are writing a system script this is absolutely unexpected and bad behaviour. On macOS now that zsh is the main supported shell plenty of people run a modern Bash out of their home.

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

#150

Post by masklinn »

lhoursquentin wrote: post #119
dvzk wrote: post #86

Earlier quoted context omitted.

Bash extensions are cool to have in the interpreter. I really don't think we need more than the basic POSIX shell for most scripts. I once wrote a tar replacement in it, with a restricted YAML generator and parser and a state machine — don’t judge me, I think I was manic — and the result was weirdly beautiful.

The lack of arrays, dicts and local variables when trying to be POSIX compliant becomes quickly annoying when writing big programs though. There are of course workarounds to deal with those but I wish we didn't have to use them.

Needing arrays, dicts, and local variables is a strong hint that you need something more capable than a shell. So is calling the artefact a program.
Post reply on HN