Re:Why Create a New Unix Shell?
by jeremyjh on Wednesday January 31, 2018 @07:54PM
(#16278945)
Yeah I've seen that Python code. Every other line is a call to os.system('...').
[ Parent
| on HN ]
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.
declare -a myArray=("foo" "bar" "baz")
echo "${myArray[2]}"
Bash is weird.
I've had good luck with this module. Much nicer than using os.system() imo.
never use os.system. os.system is a hack.
Subprocess is a bit verbose to use, though... A wrapper would be nice.
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.
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.
Ah, that's nice!
... unfortunately, I'm stuck with python2.4 or 2.6 on most machines my Python code has to run on. :/
> 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.
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.
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?
Every other line of my code is check_call. Could you expand on the issue you're observing?