<div dir="ltr"><p dir="ltr">Yes! Exactly what JD said.</p>
<p dir="ltr">I only make separate scripts if they are intended to be run separately. I hate needlessly sub-filed code. I don't want to have to jump file to file to make sense of it when reading the code or making changes. Break complex scripts up into functions even if they only get called once. A clearly named function that removes a dozen or so lines from its calling function is an excellent form of documentation.</p>
<p dir="ltr">If I do intend to script separate tasks, I prefer to avoid the pattern:<br>
monolith_script command arguments [arguments...]</p><p>Instead, I create a separate script per task and for the common pieces I will also define a bash "library" that defines functions but calls none. This, padawan, is The Way.</p>
<p dir="ltr"><br></p>
<div class="gmail_quote">On Jul 24, 2013 10:44 AM, "JD" <<a href="mailto:jdp@algoloma.com" target="_blank">jdp@algoloma.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I've written commercial installers in Borne shell. Didn't have any choice. I<br>
always felt "dirty" after.<br>
<br>
The key things to reducing bugs in any language is using functions AND no<br>
function should be larger than 1 screen (including comments). 5-20 real lines<br>
of code tops, plus checking the return code for EVERY call.<br>
<br>
<br>
On 07/24/2013 08:47 AM, Charles Shapiro wrote:<br>
> Less chance of bugs due to scoping errors<br>
> Easier to optimize (although you're going to pay a performance price for loading<br>
> more scripts)<br>
> Easier to document ( scripts should carry their own documentation )<br>
> Easier to move to new systems ( you can test and modify smaller scripts<br>
> individually)<br>
><br>
> My general rule of thumb is that once a bash script moves beyond about 500<br>
> lines, it's un-maintainable and should be rewritten in a more suitable language.<br>
><br>
> -- CHS<br>
><br>
><br>
><br>
> On Wed, Jul 24, 2013 at 8:29 AM, leam hall <<a href="mailto:leamhall@gmail.com" target="_blank">leamhall@gmail.com</a><br>
> <mailto:<a href="mailto:leamhall@gmail.com" target="_blank">leamhall@gmail.com</a>>> wrote:<br>
><br>
> Any supporting ideas for pushing the argument of "Use lots of small scripts<br>
> for a big task, instead of one large one"?<br>
><br>
> So far my thoughts are:<br>
><br>
><br>
> Isolation of new, untested functionality<br>
> Ease of use when only one part of the task is required<br>
> Easier to introduce new programmers<br>
> Ease of maintenance since you don't have to look past one screen<br>
><br>
> Anything else?<br>
><br>
> Thanks!<br>
><br>
> Leam<br>
><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>
</div>