<html><head></head><body>If a chunk of a script is useful by itself, I'll make it it's own file and just call it. I'm not concerned about efficiency of resources so calling a subshell for an external script is not a concern. Grep, sed, and awk are often launched many, many times in sequence anyway so what's another 10-40 subshells? :-)<br><br>An example:<br><br>I have one script that gathers the names of all nodes in the cluster. That can be called as input to push config changes or pull current settings or data. <br>The multi-cluster version calls the same named script as above for each cluster, gathered using different, cluster-specific methods, to perform operations across all nodes in all clusters.<br>There are several, tiny, modifier scripts that can be selectively piped through for queue and node, node only, or queue only selection.<br><br>The modifier scripts were split out so I can reuse that functionality in the myriad ad hoc scripts I write daily for poke, prod, and general break-fix operations.<br><br><div class="gmail_quote">On April 26, 2021 10:11:43 PM EDT, David Jackson via Ale <ale@ale.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">Hey Everyone,<br><div><br></div><div>When do you guys feel that your bash scripts have gotten too long? When do they need to be broken out into individual files, and when does doing so make them less easy to maintain or follow?</div><div><br></div><div>Also, how do you organize your scripts so they are easy for newcomers to understand?</div><div><br></div><div>Your thoughts are appreciated!</div><div><br></div><div>Thanks!</div><div>Dave</div></div>
</blockquote></div><br>-- <br>Computers amplify human error<br>Super computers are really cool</body></html>