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

471–480 of 500 posts

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

#471

Post by pmarreck »

pdntspa wrote: post #389
rcthompson wrote: post #326

Earlier quoted context omitted.

One of my favorite Perl features that has been disappointingly under-appropriated by other languages is quoting with q(...).

This is one of my favorite features of Ruby! Though Ruby makes it confusing AF because there are two quoting types for both strings and symbols, and they're different. (%Q %q %W %w %i) I can never remember which does which.... the letter choice feels really arbitrary.

Elixir has something like this too, but even more powerful (you can define your own):

https://elixir-lang.org/getting-started/sigils.html#strings-...

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

#473

Post by grappler »

There is an actual, honest-to-goodness, standardized, current, Shell Command Language now. It's part of POSIX.1-2017 or, if you like, IEEE Std 1003.1-2017.

Perhaps not surprisingly, it's bourne shell, not bash. But still, it's an actual published standard all can refer to when the language in question is "shell scripts", i.e. .sh files, or "shell commands" in some context where a shell command is called for (e.g. portable makefiles).

  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

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

#474

Post by partdavid »

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.

Can you expand on the parallelism features you use and what shell? In bash I've basically given up managing background jobs because identifying and waiting for them properly is super clunky; throttling them is impossible (pool of workers) and so for that kind of thing I've had to use GNU parallel (which is its own abstruse mini-language thing and obviously nothing to do with shell). Ad-hoc but correct parallelism and first class job management was one of the things that got me to switch away from bash.

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

#475

Post by sshd »

GoblinSlayer wrote: post #451
sophacles wrote: post #416

Earlier quoted context omitted.

You say this as if it wasn't extremely common to find giant python monstrosities that can be replaced by a handful of lines of shell. TBF the shell code often is not just cleaner and easier to follow, but also faster. It's possible to use the wrong tool for the job in any language - including language choice itself. Dismissing a programming language because it's not shell and dismissing shell because it's not a prora…

Bash is a good tool if the script is short enough, but if you have to write more than 10 lines, then use a real language.

If my bash script is more than 10 lines, I switch to python and if that's more than 10 lines I switch to C! And if that's more than 10 lines I use assembly!

/s

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

#476

Post by kotlin2 »

squirt wrote: post #413
kotlin2 wrote: post #250

Earlier quoted context omitted.

Now do an associative array containing another associative array.

Easy. declare -A outer=( [inner]="_inner" ) declare -A _inner=( [key]="value" ) Access inner elements via a nameref. declare -n inner="${outer[inner]}" echo "${inner[key]}" # value Currently writing a compiler in Bash built largely on this premise.

That seems really inconvenient to be honest.

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

#477

Post by sargstuff »

Spivak wrote: post #247
bitofhope wrote: post #197

Earlier quoted context omitted.

There are workloads where shell scripts are the so-called right tool for a job . All too often I see people writing scripts in "proper" languages and calling os.system() on every other line. Shell scripts are good for gluing programs together. It's fine to use them for that.

For me it's once you make switch to a "proper" language you realize how much lifting pipelines do when it comes to chaining external binaries together.

Heaping things together is better than letting things stack up/down.

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

#478

Post by sargstuff »

tuatoru wrote: post #434
ndsipa_pomu wrote: post #362

Earlier quoted context omitted.

0, 1, 3, 4 and infinity - there's four numbers in this industry. Five There's five numbers in this industry 0, 1, 3, 4, 5 and infinity Wait, I'll come in again

0, 1, 7, and indeterminate, IME. The 7 being for design. If there are more than 7 boxes on the whiteboard, try again.

ah, log base 2 of 7 is 127 bits (aka 8, y 1).

Unicode character can have more than 7 font boxes associated with one character box and still be a valid determinate character form.

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

#479

Post by sargstuff »

throw10920 wrote: post #332
marklgr wrote: post #184

Earlier quoted context omitted.

> "If you have to write more than 10 lines, then use a real language" I swear, there should be a HN rule against those. It pollutes every single Shell discussions, bringing nothing to them and making it hard for others do discuss the real topic.

The majority of those comments have significantly more thought put into them (and adhere more closely to the HN guidelines) than this comment does.

Is there a link to HN line discipline criteria? (beyond asci ranges 0 through 31)

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

#480

Post by sargstuff »

marklgr wrote: post #184
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…

> "If you have to write more than 10 lines, then use a real language" I swear, there should be a HN rule against those. It pollutes every single Shell discussions, bringing nothing to them and making it hard for others do discuss the real topic.

Think use a real line discipline like n 8 1 would make more semantic sense than 'use a real lanaguage'.

Unless, the language is APL, in which case, 10 lines is an operating system.

Post reply on HN