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

441–450 of 500 posts

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

#441

Post by kazinator »

xelxebar wrote: post #182

Hands down, shell scripting is one of my all time favorite languages. It gets tons of hate, e.g. "If you have to write more than 10 lines, then use a real language," but I feel like those assertions are more socially-founded opinions than technically-backed arguments. My basic thesis is that Shell as a programming language---with it's dynamic scope, focus on line-oriented text, and pipelines---is simply a different p…

> with it's dynamic scope

Bash has dynamic scope with its local variables.

The standard POSIX language has only global variables: one pervasive scope.

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

#442

Post by majkinetor »

partdavid wrote: post #396
Beltalowda wrote: post #66

Earlier quoted context omitted.

zsh is not a "cleaned-up bash"; it's more of a clone of ksh (closed source at the time), with some csh features added in, as well as their own inventions. bash and zsh appeared at roughly the same time, many features were added in zsh first and added to bash later (sometimes much later, and often never). This is kind of a good example of what I meant when people conflate "bash" with "shell". As for your larger point:…

I'm a Unix user and spent almost all of my professional career in bash, and switched to Powershell for my interactive shell a few years ago. The nice thing with Powershell is that it's not verbose, but the arcane abbreviations are actually quite a bit easier to remember and discover than bash. What mixes people up is that in documented examples and reusable scripts, it makes sense to use the full, canonical name, whi…

Very well said, most people don't know about shorter way

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

#443

Post by IncRnd »

deadbunny wrote: post #420
IncRnd wrote: post #39

There is an error with the template script on a fully patched m1 macbook. $1 is unbound, unless you provide an argument. This seems to be an utterly basic oversight for a template script from someone attempting to educate on bash's best practices. Especially true for seeking a "good balance between portability and DX".

You say fully patched. Does that include upgrading bash from 3.2 released in 2007?

Yes. Version 5.1.16(1).

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

#444

Post by usrbinbash »

scbrg wrote: post #353
usrbinbash wrote: post #312

Earlier quoted context omitted.

Now do that again, but this time the regular expression is controlled by 2 command line params, one which gives it the substitution, the other one is a boolean switch that tells it whether to ignore case. And the script has to give a good error if the substitution isn't a valid regular expression. It should also give me a helptext for its command line options if I ask it with `-h, --h`. In python I can use `opt/argpa…

Man, you chose the wrong username, didn't you? ;-)

Not really, I love bash. I also love perl and vimscript btw. :D

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

#445

Post by gpderetta »

jb3689 wrote: post #384
snidane wrote: post #204

Earlier quoted context omitted.

Shell and SQL make you 10x productive over any alternative. Nothing even comes close. I've seen people scrambling for 1 hours to write some data munging, then spend another 1 hour to run it through a thread pool to utilize those cores , while somebody comfortable is shell writes a parallelized one liner, rips through GBs of data, and delivers the answer in 15 minutes. What Python is to Java, Shell is to Python. It sp…

I feel like the reasons for this are: * Shell scripts force you to think in a more scalable way (data streams) * Shell scripts compose rich programs rather than simplistic functions * Shells encourage you to program with a rich, extensible feature set (ad-hoc I/O redirection, files) The only times I don’t like shell scripts are when dealing with regex and dealing with parallelism

> The only times I don’t like shell scripts are when dealing with regex and dealing with parallelism

Wow, for me parallelism is one of the best features of a unix shell and I find it vastly superior to most other programming languages.

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

#446

Post by fomine3 »

gpderetta wrote: post #445
jb3689 wrote: post #384

Earlier quoted context omitted.

I feel like the reasons for this are: * Shell scripts force you to think in a more scalable way (data streams) * Shell scripts compose rich programs rather than simplistic functions * Shells encourage you to program with a rich, extensible feature set (ad-hoc I/O redirection, files) The only times I don’t like shell scripts are when dealing with regex and dealing with parallelism

> The only times I don’t like shell scripts are when dealing with regex and dealing with parallelism Wow, for me parallelism is one of the best features of a unix shell and I find it vastly superior to most other programming languages.

It's great for embarrassingly parallel data processing, but not good for concurrent/async task.

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

#447

Post by myuzio »

pxtail wrote: post #112
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)

And THIS is the primary source of my furious hate in my toxic love-hate relationship with bash. Guy is writing bash FOR 10 FUCKING YEARS and still apparently doing it wrong in 10 letter oneliner. When it comes to bash search for even simplest command/syntax always ALWAYS leads to stackoverflow thread with 50 answers where bash wizards pull oneliners from sleeves and nitpick and argue about various intricancies

10 years of doing something wrong doesn't make it any better. 10 years of doing something and RTFM instead of random blog posts and SOF may help.

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

#448

Post by myuzio »

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)

Thanks for sharing. The only actual useful thing I got from this post.

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

#450

Post by einpoklum »

partdavid wrote: post #398
einpoklum wrote: post #132

Earlier quoted context omitted.

sh and bash feel a lot more sane and reasonable after learning some PowerShell. PowerShell is mostly not-a-shell.

Can you expand on this? What do you mean by it's "mostly not-a-shell."? I don't understand it.

It's mostly a scripting language whose commands communicate with each other, which also let's you issue commands interactively. In an actual shell, programs and commands communicate with the _user_ via textual output that the user can read and understand; and other programs can take the place of the user, reading and parsing the textual output instead. That's not what happens in PowerShell, mostly.
Post reply on HN