Date:Tue, 28 Jan 2020 16:25:51 -0500
From:Roger
Message-ID: <20200128212551.GD12574@localhost4.local>
| Wow, " trap 'trap INT; kill -INT $$' INT " not easily readable for me.
You can often help with things like that by reformatting
trap '
Date:Tue, 28 Jan 2020 16:02:25 -0500
From:Roger
Message-ID: <20200128210225.GC12574@localhost4.local>
| 1) Bash internal reserved words cannot be used a variables.
No such rule. Vars are always assigned using xxx= (no reserved words
contain an '=') and accessed u
>Here's a simple fix, that involves setting up ONE trap within the
>shell script, to override the shell's default SIGINT handling heuristic.
>
>
>#!/bin/bash
>trap exit INT
>while true; do
> ping -c 3 8.8.8.8
>done
>
>
>There. Now, when I hit Ctrl-C, the whole script exits, not just one
>instance
On Tue, Jan 28, 2020 at 03:49:32PM -0500, Roger wrote:
> As I slept on this, I realized the likeliness some programs are also trapping
> CTRL-C as you just explained.
>
> The programs I'm using within a loop were ffmpeg && mv (rename) after
> verifying
> ffmpeg created a file >0 bytes.
I'm not
I've used Bash for quite some time now and have heard lots about how variables
should be named or styled.
1) Bash internal reserved words cannot be used a variables. (OK. All of us who
have programmed code get this and of course abide whole heartedly, else we fail
quickly!)
2) Operating Syste
>If you run these, and try to kill them with Ctrl-C, you may find that
>the first one behaves perfectly (stops when you ask), and the second
>one does not. It may take several tries to kill the second one. You
>might have better luck suspending it with Ctrl-Z first, then killing
>the shell only,
On Mon, Jan 27, 2020 at 09:03:22PM -0500, Roger wrote:
> I've always had a problem with Bash script (eg. for/while) loops creating
> havoc
> upon a ctrl-c keypress.
What's *in* the loop? It matters.
Consider the following two scripts:
==
#!/bin/bash
while true;
I've always had a problem with Bash script (eg. for/while) loops creating havoc
upon a ctrl-c keypress.
One good idea, is not to put statements (eg. rm) within the loop that could
possibly create problems upon partial execution.
Another idea, addressing the monkey within the room, should a trap