Comment by colejohnson66
5 years ago
The problem is bash et al are languages designed for the command line. Every line is a separate command.
Contrast:
cat test.txt | grep search
With:[0]
import os
import subprocess
with open('test.txt', 'r') as f:
for line in f:
line = line.rstrip()
subprocess.call(['/bin/grep', line, 'search'])
While the first may use some “magic” symbols such as the pipe, it’s really concise in conveying what it’s doing.
I will give you this: bash variables and expansions can be confusing. Contrast with programming where this probably works:
"start" + variable + "end"
My problem with shells is not just about the obscure syntax, but rather about the point, that it is next to impossible to write reliable and reusable scripts.
By default return codes of failed commands are silently ignored and `set -e` does not work under all circumstances. By default every variable is part of the global scope and the best you can do about it in a POSIX compliant way are sub-shells, which in turn have no way to change variables outside of their scope.
It is just broken by design :-/
It's because shells are really designed as ways to run and manage tasks (subprocesses). So anything not related to that is at best secondary, and a pain in the ass.
The opposite being true for your average general-purpose program, where managing tasks is a secondary concern and delegated to a library.
Not only is the intent of those snippets rather different, you've rather misunderstood the original to the extent that it's broken.
The bash version looks for the pattern `search` in every line of `test.txt`, the Python version treats `test.txt` as a file of patterns, and look for each of these patterns in the file `search`.
And of course you wouldn't implement the bash version in python that way as it's rather trivial to do it in Python:
or somesuch.