ninjaaron/replacing-bash-scripting-with-python

Guide on using using python for administrative scripting

replacing-bash-scripting-with-python's Issues

Feature Request: Handling of ctrl-c while running child process

I have found this repository in an internet search. It is helpful. Thank you for writing it.

Do you have suggestions on how to handle ctrl c when running a subprocess where the subprocess wants to react and do something before it exits?

Here is an example.

outer.sh

echo start outer
python inner.py
echo end outer

inner.py

import time

print("start inner")
try:
    time.sleep(5)
except KeyboardInterrupt:
    print("got ctrl c inner")
    time.sleep(1)
    print("finished handling ctrl c inner")
print("end inner")

Running this without interrupting outputs

start outer
start inner
end inner
end outer

and with ctrl c

start outer
start inner
^Cgot ctrl c inner
finished handling ctrl c inner
end inner
end outer

but if we use this version of outer, outer.py

import subprocess

print("start outer")
subprocess.run(["python", "inner.py"], check=True)
print("end outer")

and ctrl c we get

start outer
start inner
^Cgot ctrl c inner
Traceback (most recent call last):
  File "outer.py", line 4, in <module>
    subprocess.run(["python", "inner.py"], check=True)
  File "/usr/lib/python3.7/subprocess.py", line 474, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
  File "/usr/lib/python3.7/subprocess.py", line 931, in communicate
    self.wait()
  File "/usr/lib/python3.7/subprocess.py", line 990, in wait
    return self._wait(timeout=timeout)
  File "/usr/lib/python3.7/subprocess.py", line 1624, in _wait
    (pid, sts) = self._try_wait(0)
  File "/usr/lib/python3.7/subprocess.py", line 1582, in _try_wait
    (pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt

The inner process was not able to react to the ctrl c.

There are various ways to attempt to fix this like catching the KeyboardInterrupt or the SIGTERM also in the outer process and calling terminate on the inner but I am not sure what the best approach is.

Translations?

I'm very pleased by the positive reception of this tutorial, and I've been especially surprised by the the amount of attention it's gotten from Chinese programmers. I was just thinking today that it would be nice if anyone wanted to do a translation into Chinese when I noticed, lo and behold @de8ug seems to be working on a fork with a Chinese translation!

I just wanted to put the word out to him/her and anyone else that I would be happy to help with the translation process in any way I can. English is my native language and I don't feel qualified to do any translations myself, but I'd be happy to support the efforts of anyone who does wish to translate the tutorial.

This could have been written in better way...

Well, while hovering through your stuff ...just stumbled over section "Using stdin, stdout..." in there one line could have been written in much better an concise way... like below

the original line in your document:

program-that-prints-something | grep 'a pattern'

Should have been written like this below

grep "a pattern" program-that-prints-something

Why? Because it gets rid of one process involved in it through piping. Very rudimentary but has a great impact, if you ever sit or work on a real-time server or production server.

I think it just slips in...you know it well.

file iteration

I'm enjoying your document! I've been moving away from Bash to Python scripting for years. I'm always looking for better ways to do it.

I'm curious about the section on iterating through lines of a file. You provide some relatively complicated ways to do it using "with", readline(), etc. Why not simply "for line in open(file):"?

Github Docs

Consider moving it to github docs

Has four years made a difference?

This isn't an issue, just a query, so I'll be closing it straight away.

You seem to've had a pretty dim view of Bash shell scripting four years ago—beyond, as you stated, just gluing the outputs of other programs together. Just curious if time has healed any of those wounds?

Most of your "Warning Signs" actually seem like unambiguously good things to me! The possible exception being while IFS= read -r, which, while I absolutely see why all the parts of that incantation are necessary, justly earns criticism for being so abstruse.

I got the worst cognitive dissonance over your criticism of Bash array syntax, though. Is that really any worse than, say, format strings, Ruby's expression substitution, or Python's f-strings, when compared side-by-side? I mean, Python's f-strings and JavaScript's template literals are basically Bourne shell-style string substitution, including the braces.

Cheers,
Kevin