4 ms·

There is one and only one language that's both correct and the best tool for scripting: Bourne or its superset the Korn shell (not even bash).

tannhaeuser 8y ago
You probably mean the POSIX shell [1] ;) I never understood why folks venture into bashisms for no or little gain (bash isn't even the default shell on Debian/Devuan), or would invent/use entire new languages with singleton implementations such as Perl in the 1990s or Python in the 2000s (other than for fun, of course). Note that Python is actually a descendant of the ABC programming language developed to be human-friendly, not a shell replacement language per se. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
- Annatar 8y ago
  No, I don't "probably" mean POSIX, if I write Bourne and Korn shell, then that is what I mean! I grew up on real UNIX operating systems, not the GNU/Linux cheap knockoff! Boy do statements like these make me furious!
  - 0xdeadb00f 8y ago
    What do you have against POSIX sh? Unless I'm mistaken, it's compatible with both the GNU/Linux knockoff and Unix (*BSD, etc). I prefer it to Korn and Bourne because it's compatibility is so widespread.
    - Annatar 8y ago
      I have nothing at all against POSIX, but unless one is running HP-UX, Solaris or an illumos-based OS like SmartOS, POSIX compliance is spotty at best in other operating systems. For this reason, the safest thing to do is write code for either the original Bourne shell, or ksh. Programs written in ksh are the most portable across systems, moreso since other systems have it too. And to top it all off, ksh sets the standard for POSIX, especially ksh93.
tyingq 8y ago
Because shell scripts usually have lots of dependencies on external tools, it's harder to make them portable. Those external utilities have different behavior on different platforms. I have much better luck with Python, Perl, etc, for scripts.
- Annatar 8y ago
  Shell scripts depend on what is in /sbin and /usr/bin, so software which comes with the OS. If you are struggling with that, then I warmly recommend the "Learning the UNIX operating system" book from O'Reilly to get the basics down. Your argument makes no sense.
  - tyingq 8y ago
    You seem to be assuming that Unix like utilities have the same options and work the same way everywhere. They don't. Shell portability issues are a thing. Also, why all the snark?
theshrike79 8y ago
From Google's Shell Style Guide[1]: "If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date." [1] https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml
- tannhaeuser 8y ago
  Well if Google says so ... Python brings a ton of dependencies, thereby seriously limiting your deployment options. And, together with Python's not-so-great package management story, this spells a lot of trouble for as long as Python 2 and 3 need to coexist. Many useful Python 2 programs (such as Apple's old caldav server based on twisted) won't be ported over to 3, and the migration to Python 3 creates an unnecessary burden on apps that chose Python as user-scripting language, such as Blender. There might be reasons to use Python, but the aesthetics (or lack thereof) of a scripting language, or an artificial limit on the number of lines most definitely isn't one of them.
- Annatar 8y ago
  Google has no business writing a programming guide for something they aren't competent for; the guy who wrote this is about as clueless as they come when it comes to shell programming, for example he thinks using eval should be forbidden for security reasons. And it's a guide by some company, not gospel.

tannhaeuser 8y ago

You probably mean the POSIX shell [1] ;) I never understood why folks venture into bashisms for no or little gain (bash isn't even the default shell on Debian/Devuan), or would invent/use entire new languages with singleton implementations such as Perl in the 1990s or Python in the 2000s (other than for fun, of course). Note that Python is actually a descendant of the ABC programming language developed to be human-friendly, not a shell replacement language per se. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Annatar 8y ago
No, I don't "probably" mean POSIX, if I write Bourne and Korn shell, then that is what I mean! I grew up on real UNIX operating systems, not the GNU/Linux cheap knockoff! Boy do statements like these make me furious!
- 0xdeadb00f 8y ago
  What do you have against POSIX sh? Unless I'm mistaken, it's compatible with both the GNU/Linux knockoff and Unix (*BSD, etc). I prefer it to Korn and Bourne because it's compatibility is so widespread.
  - Annatar 8y ago
    I have nothing at all against POSIX, but unless one is running HP-UX, Solaris or an illumos-based OS like SmartOS, POSIX compliance is spotty at best in other operating systems. For this reason, the safest thing to do is write code for either the original Bourne shell, or ksh. Programs written in ksh are the most portable across systems, moreso since other systems have it too. And to top it all off, ksh sets the standard for POSIX, especially ksh93.

tyingq 8y ago

Because shell scripts usually have lots of dependencies on external tools, it's harder to make them portable. Those external utilities have different behavior on different platforms. I have much better luck with Python, Perl, etc, for scripts.

Annatar 8y ago
Shell scripts depend on what is in /sbin and /usr/bin, so software which comes with the OS. If you are struggling with that, then I warmly recommend the "Learning the UNIX operating system" book from O'Reilly to get the basics down. Your argument makes no sense.
- tyingq 8y ago
  You seem to be assuming that Unix like utilities have the same options and work the same way everywhere. They don't. Shell portability issues are a thing. Also, why all the snark?

theshrike79 8y ago

From Google's Shell Style Guide[1]: "If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date." [1] https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml

tannhaeuser 8y ago
Well if Google says so ... Python brings a ton of dependencies, thereby seriously limiting your deployment options. And, together with Python's not-so-great package management story, this spells a lot of trouble for as long as Python 2 and 3 need to coexist. Many useful Python 2 programs (such as Apple's old caldav server based on twisted) won't be ported over to 3, and the migration to Python 3 creates an unnecessary burden on apps that chose Python as user-scripting language, such as Blender. There might be reasons to use Python, but the aesthetics (or lack thereof) of a scripting language, or an artificial limit on the number of lines most definitely isn't one of them.
Annatar 8y ago
Google has no business writing a programming guide for something they aren't competent for; the guy who wrote this is about as clueless as they come when it comes to shell programming, for example he thinks using eval should be forbidden for security reasons. And it's a guide by some company, not gospel.