I find your bash examples to be much more readable than your Python ones. My general rule of thumb for when to switch from shell to Python is “when I find myself needing to do nontrivial control flow”. Even then, it is perfectly legitimate to extract a single self-contained bit of shell that involves lots of stream management into its own perform_specific_operation.sh and invoke that from a Python wrapper program that handles control flow. Just be sure you’re handling quoting properly, which in practice just means “you should always pass a list as the first argument to subprocess.Popen(), never a concatenated string”.
perform_specific_operation.sh is essentially what I did (compute-alignments.sh) though it has more control flow than I’d like because it needs to branch to handle 1- and 2-input cases. And since I use a string to build up CMD it now means all of the arguments need to be well behaved.
And since I use a string to build up CMD it now means all of the arguments need to be well behaved.
I’m not entirely sure what you mean by that—it looks like you’re already using arrays instead of string concatenation to construct your command on the python side and properly quoting shell args on the bash side, so I wouldn’t expect you to run into any quoting issues.
I find your bash examples to be much more readable than your Python ones. My general rule of thumb for when to switch from shell to Python is “when I find myself needing to do nontrivial control flow”. Even then, it is perfectly legitimate to extract a single self-contained bit of shell that involves lots of stream management into its own
perform_specific_operation.sh
and invoke that from a Python wrapper program that handles control flow. Just be sure you’re handling quoting properly, which in practice just means “you should always pass a list as the first argument tosubprocess.Popen()
, never a concatenated string”.perform_specific_operation.sh
is essentially what I did (compute-alignments.sh
) though it has more control flow than I’d like because it needs to branch to handle 1- and 2-input cases. And since I use a string to build upCMD
it now means all of the arguments need to be well behaved.I’m not entirely sure what you mean by that—it looks like you’re already using arrays instead of string concatenation to construct your command on the python side and properly quoting shell args on the bash side, so I wouldn’t expect you to run into any quoting issues.
I have
CMD+=" -S $1"
, so if$1
has any spaces in it the parsing will be wrong.Now, I know this about my script and will be careful not to do that, but it’s still a risk.
Ah, I see.
It may be worthwhile to instead define
CMD
as an array, rather than a string, like thisOf course at that point you’re losing some of the readability benefits of using bash in the first place...
Edit: or, of course, you keep the script simple and readable at the cost of some duplication, e.g.