4 ms·
I don’t think it’s fair to compare a workflow that is designed for sed/awk. It’s about 10 lines of python to run my command and capture stdout/stderr - the bene
by maccard 2y ago
I don’t think it’s fair to compare a workflow that is designed for sed/awk. It’s about 10 lines of python to run my command and capture stdout/stderr - the benefit of which is that I can actually read it. What happens if you want to retry a line if it fails?
- necheffa 2y ago> I don’t think it’s fair to compare a workflow that is designed for sed/awk. If your position is that we should not be writing bash but instead Python, then yes, it is absolutely fair. > the benefit of which is that I can actually read it. And you couldn't read the command pipeline I put together? > What happens if you want to retry a line if it fails? Put the thing you want to do in a function, execute it on a line, if the sub-shell returns a failure status, execute it again. It isn't like bash does not have if-statements or while-loops.
- maccard 2y agoMy point is that if you take a snippet designed to be terse in bash, it’s an unfair advantage to bash. There are dozens of countless examples in python which will show the opposite > And you couldn't read the command pipeline I put together? It took me multiple goes, but the equivalent in python I can understand in one go. > Put the thing you want to do in a function, execute it on a line, if the sub-shell returns a failure status, execute it again. It isn't like bash does not have if-statements or while-loops. But when you do that, it all of a sudden looks a lot more like the python code