4 ms·

> Look on github for how many people write shell scripts in ruby because they don't know how bash works. You can find the same over-syntax'd-programming-environ

> Look on github for how many people write shell scripts in ruby because they don't know how bash works. You can find the same over-syntax'd-programming-environment-as-shell-script with node too. We're the exceptions. They can't handle the truth. As someone who has done this (and who currently works in C), I will say only that shell scripts translated to Ruby can be a lot easier to read and maintain than those written in bash... if I get to the point where I'm having to pipe to more than two of awk/sed/grep I will generally just write it in Ruby, because then my mother could read it. YMMV though. In every other sense I agree with you entirely, and I think the proliferation of JS rewrites of things that work in actually-designed languages is appalling.

seiji 13y ago
You found the one exception. There's a fuzzy line when dealing with shell scripts. If you're just iterating over a directory and checking some files, that's great shell script territory. If you're making a launcher script for another program to set the environment, check directories, fix permissions, and run pre-flight checks, that's great for shell script. But, sometimes we end up with feature creep. You start out with "Well, this shell script just has to parse some CSV and insert into sqlite" then before you know it, it also has to check another pre-existing DB for redundancy checks or constraints, then you're 100 pages into the Advanced Bash-Scripting Guide trying to make Bash do something that would be a six liner in Perl 4. The benefits of over-programming bash scripts is extensive portability though (if you make sure you aren't using features only in very late version of the shell).
- kbenson 13y ago
  Except if by portability you include non-unix systems. Then you're probably better off with Perl (for example) again.
- planckscnst 13y ago
  > If you're just iterating over a directory and checking some files Unfortunately, I very frequently see this in shell scripts... ls $SOME_PATH | awk... I even once saw someone use ls to figure out if a certain file was a symlink by looking for "->"! That kind of stuff doesn't typically happen in other languages.

seiji 13y ago

You found the one exception. There's a fuzzy line when dealing with shell scripts. If you're just iterating over a directory and checking some files, that's great shell script territory. If you're making a launcher script for another program to set the environment, check directories, fix permissions, and run pre-flight checks, that's great for shell script. But, sometimes we end up with feature creep. You start out with "Well, this shell script just has to parse some CSV and insert into sqlite" then before you know it, it also has to check another pre-existing DB for redundancy checks or constraints, then you're 100 pages into the Advanced Bash-Scripting Guide trying to make Bash do something that would be a six liner in Perl 4. The benefits of over-programming bash scripts is extensive portability though (if you make sure you aren't using features only in very late version of the shell).

kbenson 13y ago
Except if by portability you include non-unix systems. Then you're probably better off with Perl (for example) again.
planckscnst 13y ago
> If you're just iterating over a directory and checking some files Unfortunately, I very frequently see this in shell scripts... ls $SOME_PATH | awk... I even once saw someone use ls to figure out if a certain file was a symlink by looking for "->"! That kind of stuff doesn't typically happen in other languages.