41–50 of 138 posts
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…
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 have a tool that’s better at dealing with shell stuff. It’s called Perl.
If not, there are copycats like Ruby and Python . . .
having a hard time being sold here. mkdir -p would create the directory without error. checking if a directory exists is trivial before creating it. Python throws an error if the path given to os.mkdir exists too. This article is way too long to digest, so i should stop now. Perhaps the argument should be, rewrite hacky things in bash as programs and build them into your apps?
I'm a professional programmer by trade. Admitting to starting a program I know would be over 100 lines in shell script would be close to an admission of incompetence, because technically shell script is one of the worst computer languages out there. So I'd never admit to it. But it's so damned portable, and ubiquitous and the batteries it comes with (the 'nix cli tools) are to powerful and complete, it makes irresistible at times.
Where this article falls down is they are recommending Python3. Python2 would be fine. But in 'nix environments, where file names and configuration files can't be treated as text (Unicode) because there is no well defined system encoding, Python3 manages to introduce more rare bugs than shell script. It encourages you to treat everything a text, the dies ignominiously when decoding the 'nix byte stream (file name or whatever) fails. (On Windows where everything is UTF16, this isn't a problem - for local files. It remains a problem for data from external systems, like the internet.)
Pull off making a programming language less reliable than shell was a mean achievement - but the Python3 devs did it. Hats off to 'em.
That's why I've done it before, to write tools like custom log rotating / clean-up stuff; another project that comes to mind was a data pipeline that used some Python regex stuff to clean up non-printable characters and ugly stuff from text files before importing data. Both of these projects had lots of tests to verify that the code did what we wanted it to do.
I think this article is supposed to commend Python as a better choice than Bash? I think the author forgot to make a convincing argument for that, though. > The point of bash-bashing is to reduce use of the shell. That's a tautology. I get it, we're supposed to reduce the use of bash ... but why? > Without much real work, it’s easy to replace shell scripts with Python code. But you're writing the same thing again? Th…
I've written extensive programs in Haskell, and yet I also have many Bash scripts. I go back and forth. For the longest time I ignored Perl and just wrote scripts in C. Then I learned Perl, then Python. I prefer Ruby for no better reason than it's less boring. These scripting languages share a common strength: nested hash tables make everything easier. Still, I'd revert to Bash, explaining that if you can't accomplis…
Otherwise they'd just be plain old compiled "languages."
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…
Like testing (Bats sucks).
Like string manipulation (use other utils or even languages callable from Bash).
Like complicated logic. Just don't do that in Bash.
Bash is for (glorified) one-liners. And for I-can't-believe-you-did-that-in-Bash-ers.
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…
Good news, they did! Even better news: it doesn't require python, it's cross platform, and supports an easy-to-read verbose style for scripts but a quick-to-write terse style for interactive usage. It's an absolute joy to use for nested data structures, everything is an object and it has full native tab completion.
Unfortunately it came out of Microsoft so a lot of people haven't given it the time of day yet. It's honestly one of the joys of modern CLI usage though.
Typer is one of the better packages for running Python scripts from CLI. Fabric & Invoke are pretty good too.
To run any bash commands in Python I have a Python script that creates a temporary bash file with the code to execute, makes it executable, runs it with the commands in the built-in subprocess package, then deletes the file. This makes any complex bash commands with piping and whatnot runnable straight from Python.
This way I don't have to learn all the different bash-based Python commands from pathlib and whatnot that throw unexpected errors, and I can run them using pure bash syntax from Python. But then you also get all the benefits of Python's looping syntax, classes etc.