It is obviously each person's preference, but I especially hate non-reproducible, context dependent bugs. I think having a reproducible, consistent runs is key

It is obviously each person's preference, but I especially hate non-reproducible, context dependent bugs. I think having a reproducible, consistent runs is key to having nice software that everyone enjoys developing. In this light, I find the tty decision particularly bad, as it is very prone to introducing subtle changes -- for example, do you need the special flag for "git log"? what about "git for-each-ref"? what about "ls"? what about "gcc"? For this reason, I find it way easier to just ban "sh" outright altogether. Our organization policy say "do not use sh module". When new member joins, and they way to shell stuff out, they will find out that they need to use subprocess module, grumble a bit, search the web, but then produce a working, if verbose, code. An alternative would be to say: You can use sh, but never use it as sh's own front page recommends. If you find an article on the web which mentions sh, be aware that you cannot just copy-paste code from it, as it can be broken depending on which command you run. You need to audit which command you run to see if it cares about tty. Currently, you have to include the flag for many (but not all) git subcommands, "ls", "apt", ... but that list can change at anytime. > i know i've been happy it's there and used it in a few projects with good success, particularly projects that need exactly that: replace a shell and have the terminal passed down correctly. You have been lucky so far, but every time you use "sh" you are walking on landmines. I can give you a ton of plausible examples where sh breaks. Here is a shell replacement gone wrong: $ git show HEAD | wc 49 273 2202 $ python3 -c 'import sh; print(sh.wc(sh.git.show("HEAD")))' 19 97 812 edit: have you seen "subprocess.run" in python 3.5 [0]? It gives nice all-in-one API, with readable options like `check=True' or `capture_stdout=True` [0] https://docs.python.org/3/library/subprocess.html#subprocess.run https://docs.python.org/3/library/subprocess.html#subprocess...