nsd VS homebrew-core

Repository of scripts written in the language - https://github.com/ngs-lang/nsd

> there isn't really an entry point in murex scripts

I have a nice trick in NGS for that. Under the idea that "small scripts should not suffer", script is running top to bottom without "entry point". However, if the script has defined main() function, it is invoked (with command line arguments passed).

Example - https://github.com/ngs-lang/nsd/blob/afe0cad5e506ec4ee2fa924...

> `args` still contains more boilerplate code than I'm happy with

Is there anything preventing you to have exactly the same functionality but with syntactic sugar that it looks like parameters declaration? (Just to be clear, keeping all the ARGV machinery).

Something like (assuming local variables are supported; if not, it could still be $args[Flags] etc):

  function hippo(name:str, hungry:bool) {

NGS Scripts Dumpster - collection of small scripts in NGS

Doing DevOps today? 99% either abuse bash or abuse a general purpose programming language.

bash does not meet any modern expectations from a programming language: syntax, error handling, data structures

General purpose languages such as Python, Ruby, etc are not domain specific enough to have the desired facilities.

Here is small example of straightforward solution to a small problem: list all CloudFormation stacks that are managed by the given CodePipeline.

https://github.com/ngs-lang/nsd/blob/02d66abb844b7dd6077b9976e3a03659cf4b3660/aws/codepipeline/pipeline-stacks.ngs

The script is at https://github.com/ngs-lang/nsd/blob/master/aws/cloudformation/delete-stack.ngs

$ brew info eza ==> eza: stable 0.18.13 (bottled) Modern, maintained replacement for ls https://github.com/eza-community/eza Not installed From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/e/eza.rb License: MIT ==> Dependencies Build: pandoc ✘, pkg-config ✔, rust ✘ Required: libgit2 ✘ ==> Analytics install: 12,792 (30 days), 38,295 (90 days), 68,375 (365 days) install-on-request: 12,790 (30 days), 38,293 (90 days), 68,375 (365 days) build-error: 0 (30 days)

Is disabling the compromised repo the typical GitHub policy? My concern is there are monorepos used by package managers, like brew, that are a collection of thousands of projects [1]. These monorepos seem like a prime target for attack and if GitHub disables one because a malicious commit was merged then you've taken down an entire ecosystem.

[1] https://github.com/Homebrew/homebrew-core

> Correct. Though we do not appear to be affected, this revert was done out of an abundance of caution.

[1] https://github.com/Homebrew/homebrew-core/pull/167512

> right, but now you know even less about your setup when you some roadblock

This is the same with a binary though. And with homebrew, you can't follow patches or flags used or if they change.

- https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad...

definitely be careful about using fortune in a corporate environment or public space if you don't know what dat files you are using or you might just get an extremely unwelcome surprise.

I was practicing a presentation and used to use "fortune" all the time. I forget exactly what it output but I remember being absolutely mortified about what could have happened if that had popped up during an internal company tech talk.

Kudos to brew for keeping unsuspecting people safe

https://github.com/Homebrew/homebrew-core/commit/3fb3c4c3e55...

I'm sorry to be asking this as I find it a bit silly, but it's blocking my PR [3], so could a few of you star the project on Github [1] to get my PR to run?

[1] https://github.com/laktak/chkbit-py

[2] https://brew.sh

[3] https://github.com/Homebrew/homebrew-core/pull/160018