On Fri, Oct 13, 2023 at 5:59 PM Grisha Levit <grishale...@gmail.com> wrote:
> On Fri, Oct 13, 2023, 10:03 Ti Strga <wearyofallthisc...@gmail.com> wrote:
>>
>> [*] Alternatively, there's the trick about putting the entire script
>> contents inside a compound statement to force the parser to read it all,
>> but that just makes the script harder for a human to read. Copy-and-exec
>> makes the top-level scripts cleaner IMHO.
>
> IMHO you'd be better off just putting a `{` line at the start and `}` line at
> the end of your scripts,
Enh, that clutters up the calling scripts, and unlike setting a
variable at the top (the "OUTSIDE" in the example, with a real name in
the real code), it's not immediately clear to future coworkers why
we're doing it and what effect it has. Semi-self-documenting
variables that can be easily grepped for are always better than
apparently arbitrary isolated curly braces. Having to play tricks
with the parser to avoid something tangentially related to parsing is
not my style, but I appreciate that others may feel differently.
The big weakness of the "{}" approach is that if a writer forgets to
do that, there's no way to detect it until a script is modified and
the running one crashes. But in the case of cloning, we can add such
explicit test-and-detection for "did you forget to trigger the
cloning" in the few scripts that really, really need it.
> and avoid a whole host of other potential problems. (Do you make a separate
> holding directory for each run of the outer script? If so, what happens if
> someone starts another copy after making changes? If not, how do you clean it
> up? Etc.)
Already taken care of. Honestly, this part of the functionality is
pretty solid, I just didn't put it in the example. :-) Yes, we use
different holding copies, it's not a hardcoded "COPY_OF_SCRIPT" in the
real script. Several simultaneous copies are fine. We clean things
up with a combination of chained EXIT traps in the scripts, and some
systemd-tmpfiles work for the parts that aren't scripts.
