101–110 of 138 posts
Earlier quoted context omitted.
Judging by the reaction of the kids at work, what you did is already unmaintainable. Plus, if you are running shell out of necessity on a constrained system, that doesn't mean shell deserves to be a programming language where there's actual choice.
Anything is unmaintainable if the maintainers don't have the foundational skills.
https://github.com/MoserMichael/subb
https://pypi.org/project/subb/
Python doesn't have the problem of shell scripting language, it doesn't get impractical, as the program is getting more complex. In bash you have arrays, and even maps, but these aren't pretty. Also the shell scripting language is being evaluated by an parse tree/AST interpreter, that's significantly slower than even python, in it's byte code interpreted form.
My objective was to get an abstraction, for a one line process run and extraction of the result, similar to what we had in Perl5 with the system library function. https://perldoc.perl.org/functions/system
Also the shell is impractical, when it comes to slightly more complex programs. There is a limit on what you can do with pipes. Maybe that's the reason why perl is that flexible, as they tried to bridge both realms: Perl had to be useful as a replacement for the quick shell like script, and to be useful as a general purpose programming language.
I have some bad news for you, from a long, long, long time CS/EE/Sysadmin person: I can probably run my bash script on every linux I ever touched. I can probably have that python code break on half of the linux boxen I use. This one does not have module X installed. This one is too old, this one is too new, this python is not holding its mouth just at the right angle to work. Yeah, bash bash all you want. I have pull…
If you switch from Linux to *nix where you introduce BSD variants (like macOS) it gets even worse. Python dependency management leaves much to be desired but bash has none.
I wrote this to simplify just that for my own tools; the subprocess module that comes with the batteries has a very general interface, i think that it is a bit complex for a quick script. https://github.com/MoserMichael/subb https://pypi.org/project/subb/ Python doesn't have the problem of shell scripting language, it doesn't get impractical, as the program is getting more complex. In bash you have arrays, and even m…
Earlier quoted context omitted.
That's what Python2.7 is and why every major proprietary product won't adopt anything else. It's also why it won't go away. All of my Python 2.6-2.7 scripts haven't been touched in 10 years in production and they aren't likely to ever be updated. I actually now refuse to write new Python that isn't compatible with both 2&3 for this reason. Python3 refuses to stabilize.
> It's also why it won't go away. Python 2 went away in macOS. Bash still exists.
`/usr/bin/python` invokes Python 2.7.18 on my just-bought Macbook Pro 14 running MacOS 12.2. Maybe that's because I installed the Xcode command line tools?
Earlier quoted context omitted.
Also, how much code would it take to do the same thing in python?
Probably something along the line of Popen(["the_tool"] + list(Path().glob("*.yml")))
While dethanatos's point about Bash's default behavior with a non-matching glob is on target, the remainder of the example demonstrates a problem in the_tool, which will need to be worked around regardless of how you invoke it.
I was hoping someone finally had a library or something to make python good at the things shell does well (mostly, running stuff and piping output around). If only. This really just reads like someone who doesn't know shell and does know python, but thinks the problem is the tool. They continually describe shell with phrases like "obscure and difficult-to-predict" while talking through things that are either obvious…
We had some problem, roughly, "run a tool on all YAML files in the directory" or something. The first attempt that led to a production outage: (It is late, bash examples are approximate. Don't sweat the syntax.) the_tool *.yaml There weren't any YAML files, so argv[1] was literally "*.yaml", which then wasn't found, leading to errors, etc. shopt -s nullglob the_tool *.yaml (Don't even get me started on how there's sh…
It absolutely can, I have no idea where you’re getting this idea.
Earlier quoted context omitted.
We had some problem, roughly, "run a tool on all YAML files in the directory" or something. The first attempt that led to a production outage: (It is late, bash examples are approximate. Don't sweat the syntax.) the_tool *.yaml There weren't any YAML files, so argv[1] was literally "*.yaml", which then wasn't found, leading to errors, etc. shopt -s nullglob the_tool *.yaml (Don't even get me started on how there's sh…
find . -maxdepth 1 -name '*.yaml' -print0 | xargs -r0 the_tool >To say "you're holding it wrong" is just folly. Bash is worthy of the same treatment that "A Fractal of Bad Design" gave PHP, and it has no place in anything that wants to call itself engineering. If you have a problem that involves "run a command with a list of parameters but not if the list is empty" and you don't immediately think of `xargs -r`, then…
find has -exec, xargs isn't necessary.