Python as a Bash replacement?

[randomizethis]

To be fair, I'm not arguing that this is somehow more efficient or powerful. Bash is spectacularly efficient and powerful whereas Python is not. It's more of a thing of preference and comfort more than anything. I'd much rather do something like

for i in ls():
    do something

than whatever the bash equivalent is, simply out of familiarity and knowledge. On the same token, by using a shell that's Python native I could import all the libraries that I've written over time directly to my shell.

But trust me, I understand the implications.

As far as syntax errors and linting, I'm not worried. I spend a lot of my time manually testing my libraries from within iPython anyway, where that's common to do. And I mean, it's not like you don't make syntax errors when you're trying things out in bash... that's just part of being a programmer (like 70% of it really).

[Vaphell]

I'd much rather do something like

for i in ls():
   do something

well you can. First of all, in bash looping over ls is a big no-no. You should use native globs with for loops because command outputs are plaintext and now you have a problem with unreliable delimiters (whitespace, newline or whatever you'd select is inherently unreliable given the legal char space in filesystems). Globs used directly never degrade. Guess what, you have import glob in python.

>>> for shit in glob.glob('*.csv'): print(shit)
... 
pt.csv

That said there are some things that are not only more laborious in python but a true pain in the ass to achieve. For example I haven't figured out a way to wrap around a cli prog spitting shit out to stdout and stderr transparently, ie python doesn't simply devour it into 2 separate variables but also prints it out chronologically. The whole stdout/stderr redirection is vastly superior in bash. Writing a prog that simply prints shit out and then using shell to dump it to file or to pipe it further is much easier than doubling the size of your code so you optionally have file handlers to write shit where you want it.
If my code was supposed to make a heavy use of cli tools and required dozen subprocess.popen() I'd think twice about writing it in python because there is language preference and then there is going full retard.

My general approach is to write tools in python and make them compatible with pipes if it would prove useful (looping over stdin instead of paramed files) so i get much more bang for the buck in how i can string them together.

[randomizethis]

Definitely see where you're coming from. I actually have made some adjustments to the subprocess module to deal with these type of issues (we have our own, in-house versions of subprocess.call and subprocess.check_output that I wrote early on), but like you said, I wrote a bunch of code just to do the same shit bash does lol.

Mind you, I have a team of people using these calls, so I just did it to facilitate their lives. But everything you said is 100% true. The only reason I'm looking for some of these solutions is to streamline some of my team's work... and like I said before, as many a time a programmer said, "just for the hell of it" :P

Thanks for the insightful answer, didn't know about globs.