Ruby: A great language for shell scripts
lucasoshiro.github.io
Ruby: A great language for shell scripts
1–10 of 368 posts
Re: Ruby: A great language for shell scripts
#2For me, when Bash ain't enough I upgrade to the Project language (PHP, Python, JS, etc). For compiled project I reach for LSB language (Perl, Python) before introducing a new dependency.
Re: Ruby: A great language for shell scripts
#3These are great points, if you already have Ruby in your stack. For me, when Bash ain't enough I upgrade to the Project language (PHP, Python, JS, etc). For compiled project I reach for LSB language (Perl, Python) before introducing a new dependency.
Re: Ruby: A great language for shell scripts
#4These are great points, if you already have Ruby in your stack. For me, when Bash ain't enough I upgrade to the Project language (PHP, Python, JS, etc). For compiled project I reach for LSB language (Perl, Python) before introducing a new dependency.
What does LSB stand for?
Re: Ruby: A great language for shell scripts
#5These are great points, if you already have Ruby in your stack. For me, when Bash ain't enough I upgrade to the Project language (PHP, Python, JS, etc). For compiled project I reach for LSB language (Perl, Python) before introducing a new dependency.
Re: Ruby: A great language for shell scripts
#6Small nit: your note in Feature 4 is actually supposed to be in Feature 5, I assume.
Re: Ruby: A great language for shell scripts
#7These are great points, if you already have Ruby in your stack. For me, when Bash ain't enough I upgrade to the Project language (PHP, Python, JS, etc). For compiled project I reach for LSB language (Perl, Python) before introducing a new dependency.
What does LSB stand for?
https://refspecs.linuxbase.org/LSB_3.2.0/LSB-Languages/LSB-L...
Re: Ruby: A great language for shell scripts
#8Re: Ruby: A great language for shell scripts
#9Also ruby is great in allowing complexity to grow smoothly, no sudden hiccups. You start with just one line (everything goes into module main implicitly), extend it to a single-file script, require some built-in libraries, then add a module or helper class in the same file, and only then maybe extract those files to required files, add gems, whatever. No boilerplate whatsoever, no jumps, no big rewrites.
meanwhile, a lot of tooling nowadays is written in Go, and I have no idea why, it's not friendly for os manipulation at all, and number crunching power is not needed in many, many tasks of that sort.