4 ms·

Are there any "real languages" that don't suck at shell scripting? I use node in client side code but glue things together with bash.

bwarp 15y ago
I've not found one yet! If anyone has any suggestions I'd love to know.
- singular 15y ago
  I have to say that I've found go to actually be pretty awesome as a scripting language, though I've not used it a lot for this purpose a lot myself. The type inference + straight-forward standard library helps a lot with it.
- brlewis 15y ago
  I've heard that scsh (The Scheme Shell) is good, but haven't tried it myself. Even though my web app is written in Scheme, I still have a few bash scripts.
  - docgnome 15y ago
    I think chicken scheme is even nicer for that kinna stuff.
irahul 15y ago
It depends on your definition of real language. I consider Ruby and Perl to be real, production level language, and they are both excellent as glue languages. Python, on the other hand, would need some helper functions to make the interface intuitive. But you only need to define them once, and then off you go.
WalterBright 15y ago
D seems to work rather well as a scripting language. http://dlang.org/rdmd.html Note the first line of the D "shell script": #!/usr/bin/rdmd
- bwarp 15y ago
  It is statically typed and non interactive. I'm not sure I could get on with that as a scripting language.
fabricode 15y ago
Yes: Perl. This was the original use case for the language. We used to have to glue together sh, awk, sed, grep, CLIs (custom C), etc in order to automate anything in Unix. Perl brought all of this functionality under one roof with a simple, coherent interface. Most every complaint I read about Perl (too flexible, weird sigils) is a direct reflection of the system it was replacing. It's funny to read how people love that there's more than one way to do just about anything in Linux, but gasp that there are too many ways to do equivalent actions within Perl. They're one in the same. (I am not going to re-re-address its "readonly" nature since that's a red herring which applies to any language.)
- bwarp 15y ago
  I used perl for about 5 years for general scripting tasks. It's not about there being too many ways to do something for me, it's that you need to know the subtlety of each one and cryptic abbreviations.
  - jleader 15y ago
    Regarding "cryptic abbreviations", do you know about "use English;"? It provides readable names for all the "ugly punctuation variables". It's included as part of the core Perl install. http://perldoc.perl.org/English.html http://perldoc.perl.org/English.html
    - bwarp 15y ago
      use English in itself is a sign of much turdyness.
  - fabricode 15y ago
    In probably 99% of Perl code, you only need to know two cryptic symbols: $! for errno and $? for child-process exit status. And if you're programming in shell now, you're already using $?. Yes, there are symbols for handling autoflush on handles, input/output record separators, etc. But rarely will you need to use these items. In fact, we have methods for handling these situations for quite some time now. For instance, to unbuffer your output you'd use $|, but now you just use $filehandle->autoflush(1). Another example would be undefining the input record separator so that you could pull in an entire file with one read, but now that's handled via Slurp::slurp_file.

bwarp 15y ago

I've not found one yet! If anyone has any suggestions I'd love to know.

singular 15y ago
I have to say that I've found go to actually be pretty awesome as a scripting language, though I've not used it a lot for this purpose a lot myself. The type inference + straight-forward standard library helps a lot with it.
brlewis 15y ago
I've heard that scsh (The Scheme Shell) is good, but haven't tried it myself. Even though my web app is written in Scheme, I still have a few bash scripts.
- docgnome 15y ago
  I think chicken scheme is even nicer for that kinna stuff.

irahul 15y ago

It depends on your definition of real language. I consider Ruby and Perl to be real, production level language, and they are both excellent as glue languages. Python, on the other hand, would need some helper functions to make the interface intuitive. But you only need to define them once, and then off you go.

WalterBright 15y ago

D seems to work rather well as a scripting language. http://dlang.org/rdmd.html Note the first line of the D "shell script": #!/usr/bin/rdmd

bwarp 15y ago
It is statically typed and non interactive. I'm not sure I could get on with that as a scripting language.

fabricode 15y ago

Yes: Perl. This was the original use case for the language. We used to have to glue together sh, awk, sed, grep, CLIs (custom C), etc in order to automate anything in Unix. Perl brought all of this functionality under one roof with a simple, coherent interface. Most every complaint I read about Perl (too flexible, weird sigils) is a direct reflection of the system it was replacing. It's funny to read how people love that there's more than one way to do just about anything in Linux, but gasp that there are too many ways to do equivalent actions within Perl. They're one in the same. (I am not going to re-re-address its "readonly" nature since that's a red herring which applies to any language.)

bwarp 15y ago
I used perl for about 5 years for general scripting tasks. It's not about there being too many ways to do something for me, it's that you need to know the subtlety of each one and cryptic abbreviations.
- jleader 15y ago
  Regarding "cryptic abbreviations", do you know about "use English;"? It provides readable names for all the "ugly punctuation variables". It's included as part of the core Perl install. http://perldoc.perl.org/English.html http://perldoc.perl.org/English.html
  - bwarp 15y ago
    use English in itself is a sign of much turdyness.
- fabricode 15y ago
  In probably 99% of Perl code, you only need to know two cryptic symbols: $! for errno and $? for child-process exit status. And if you're programming in shell now, you're already using $?. Yes, there are symbols for handling autoflush on handles, input/output record separators, etc. But rarely will you need to use these items. In fact, we have methods for handling these situations for quite some time now. For instance, to unbuffer your output you'd use $|, but now you just use $filehandle->autoflush(1). Another example would be undefining the input record separator so that you could pull in an entire file with one read, but now that's handled via Slurp::slurp_file.