4 ms·

Yeah I've seen that Python code. Every other line is a call to os.system('...').

sethrin 9y ago
You say that like it's a bad thing. Bash does not support niceties like typed variables, named parameters, or classes. Its conditional operator is an external program with a required last argument to make it look like sane syntax. Little things like interpolating variables, array access, or taking command line options are awkward and prone to failure. It doesn't have the insane syntactical issues that csh had, and POSIX is ubiquitous, but that's a pretty low bar and an inadequate justification for using a fundamentally limited language. Python could have a nicer syntax for invoking the system interpreter -- personally, I think that Ruby's backticks feel very Unixy -- but if there is a better interpreter on the system there is no reason not to use it. Even if half your code is calling out to the shell, you still have the benefits of typed variables, a nicer syntax, the ability to abstract code into classes, a variety of nice enumeration options, and all the other benefits of a "real" programming language.
- watersb 9y ago
  declare -a myArray=("foo" "bar" "baz") echo "${myArray[2]}" Bash is weird.
dsnuh 9y ago
I've had good luck with this module. Much nicer than using os.system() imo. https://amoffat.github.io/sh/ https://amoffat.github.io/sh/
- arghwhat 9y ago
  never use os.system. os.system is a hack. Subprocess is a bit verbose to use, though... A wrapper would be nice.
  - Rotareti 9y ago
    Since python3.6 it's just subprocess.run(). The SP module was refactored. I hope that eliminates the need for all these annoying (IMHO) wrappers.
    - arghwhat 9y ago
      Ah, that's nice! ... unfortunately, I'm stuck with python2.4 or 2.6 on most machines my Python code has to run on. :/
      - Sean1708 9y ago
        > I'm stuck with python2.4 or 2.6 Not even 2.7?! 2.6 hasn't had a security update since 2013[0], I dread to think how old 2.4 is. [0]: https://www.python.org/download/releases/2.6.9/ https://www.python.org/download/releases/2.6.9/
        arghwhat 9y ago
        Python2.4 is what RHEL/CentOS 5 has to work with... And the extended support for that bloody release lasts till 2021. You can install a newer version, but our CentOS 5 machines are meant for compatibility tests, so modifying their setup is unacceptable.
        dsnuh 9y ago
        Have you tried using the scl repos from RedHat/CentOS? I use it at work yo enable different versions of Python at a system level if I am unable to muck with it because of yum. I believe they are available for CentOS 5.x?
  - dsnuh 9y ago
    I wasn't recommending os.system() ever, OP used it in the example. Subprocess is better, as you said. I think the sh module is better than Subprocess as well.
rendaw 9y ago
Every other line of my code is check_call. Could you expand on the issue you're observing?
- nickcw 9y ago
  check_call for the win! I contributed check_call to the subprocess module for exactly that purpose - easier shell like scripting in python :-)

You say that like it's a bad thing. Bash does not support niceties like typed variables, named parameters, or classes. Its conditional operator is an external program with a required last argument to make it look like sane syntax. Little things like interpolating variables, array access, or taking command line options are awkward and prone to failure. It doesn't have the insane syntactical issues that csh had, and POSIX is ubiquitous, but that's a pretty low bar and an inadequate justification for using a fundamentally limited language. Python could have a nicer syntax for invoking the system interpreter -- personally, I think that Ruby's backticks feel very Unixy -- but if there is a better interpreter on the system there is no reason not to use it. Even if half your code is calling out to the shell, you still have the benefits of typed variables, a nicer syntax, the ability to abstract code into classes, a variety of nice enumeration options, and all the other benefits of a "real" programming language.

watersb 9y ago
declare -a myArray=("foo" "bar" "baz") echo "${myArray[2]}" Bash is weird.

dsnuh 9y ago

I've had good luck with this module. Much nicer than using os.system() imo. https://amoffat.github.io/sh/ https://amoffat.github.io/sh/

arghwhat 9y ago
never use os.system. os.system is a hack. Subprocess is a bit verbose to use, though... A wrapper would be nice.
- Rotareti 9y ago
  Since python3.6 it's just subprocess.run(). The SP module was refactored. I hope that eliminates the need for all these annoying (IMHO) wrappers.
  - arghwhat 9y ago
    Ah, that's nice! ... unfortunately, I'm stuck with python2.4 or 2.6 on most machines my Python code has to run on. :/
    - Sean1708 9y ago
      > I'm stuck with python2.4 or 2.6 Not even 2.7?! 2.6 hasn't had a security update since 2013[0], I dread to think how old 2.4 is. [0]: https://www.python.org/download/releases/2.6.9/ https://www.python.org/download/releases/2.6.9/
      - arghwhat 9y ago
        Python2.4 is what RHEL/CentOS 5 has to work with... And the extended support for that bloody release lasts till 2021. You can install a newer version, but our CentOS 5 machines are meant for compatibility tests, so modifying their setup is unacceptable.
        dsnuh 9y ago
        Have you tried using the scl repos from RedHat/CentOS? I use it at work yo enable different versions of Python at a system level if I am unable to muck with it because of yum. I believe they are available for CentOS 5.x?
- dsnuh 9y ago
  I wasn't recommending os.system() ever, OP used it in the example. Subprocess is better, as you said. I think the sh module is better than Subprocess as well.

rendaw 9y ago

Every other line of my code is check_call. Could you expand on the issue you're observing?

nickcw 9y ago
check_call for the win! I contributed check_call to the subprocess module for exactly that purpose - easier shell like scripting in python :-)