<div dir="ltr"><div>I thought I knew bash pretty well, but I&#39;ve picked up some valuable hints from this discussion.<br><br></div>-- CHS<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 6:44 AM, Leam Hall <span dir="ltr">&lt;<a href="mailto:leamhall@gmail.com" target="_blank">leamhall@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Scott, thanks!<br>
<br>
Several folks have provided critique, and if I hadn&#39;t been ill for the past week or so much of their input would already be integrated. As is I can mostly survive work but not much else. Feel free to provide notes as late as you want; I&#39;m more the &quot;get it right&quot; than &quot;leave it alone&quot; type.<span class="HOEnZb"><font color="#888888"><br>
<br>
Leam</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 04/14/15 16:46, Scott Plante wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;ll take a whack at it. Sorry for the delay, I wanted to wait until I had time to really have a good look.<br>
<br>
One thing that&#39;s often overlooked in shell scripts is that you can redirect the output<br>
of a block of statements at once. I often see stuff like<br>
   echo a &gt; filename<br>
   echo b &gt;&gt; filename<br>
   echo c &gt;&gt; filename<br>
instead of<br>
   {<br>
     echo a<br>
     echo b<br>
     echo c<br>
   } &gt; filename<br>
The latter also has the advantage of only opening the file once, instead of 3 (or x) times. It may not<br>
seem more concise &amp; readable here (2 extra lines!) but in practice it usually is. Or especially in cases<br>
like yours where the block (for loop) is already there.<br>
<br>
Also, for simple &quot;if&quot; conditionals where there isn&#39;t both a true and false statement,<br>
and especially where there&#39;s only a single statement to execute conditionally, you can<br>
use the handy &amp;&amp; and || connectors. &amp;&amp; means execute the next statement if the previous<br>
returned 0 exit code (true/no error), and || when non-zero/false.<br>
<br>
e.g. [ -f &quot;$file&quot; ] &amp;&amp; true &gt; &quot;$file&quot;<br>
<br>
And for short sanity checks, I often do this kind of thing even though it&#39;s two statements:<br>
   [ -f &quot;$reqfile&quot; ] ||<br>
       { echo &quot;$reqfile is required&quot; 1&gt;&amp;2; exit 1; }<br>
or in your case:<br>
   [ -z &quot;$RELEASE&quot;  ] &amp;&amp;<br>
       { echo &quot;Please provide a release number.&quot; 1&gt;&amp;2; exit 2; }<br>
Somebody mentioned about the non-zero exit codes already. Also, the 1&gt;&amp;2 sends the<br>
message to std err, which would be the convention.<br>
<br>
An aside:<br>
   I often use the simple<br>
     &gt; $file<br>
   and I&#39;ve seen<br>
    : &gt; $file&quot;<br>
   Note &quot;:&quot; is the null statement. In my e.g. I used &quot;true&quot; as it&#39;s concise and emits no output<br>
   but is unlikely to be overlooked. If you think cat /dev/null is more readable then that&#39;s<br>
   fine, but I don&#39;t know if I&#39;d say any are very much better than the others. I think the cat /dev/null<br>
   is mostly more readable if you&#39;re used to seeing it and not used to seeing the others, but there<br>
   are no absolute answers in stylistic questions.<br>
<br>
I&#39;m a bit unsure what&#39;s meant to be in default, but it seems like the &quot;-r RELEASE&quot; option is not meant<br>
to be optional. If that&#39;s true, you shouldn&#39;t have it in square brackets in your help message. But maybe<br>
you mean it&#39;s optional if it&#39;s in the default?<br>
<br>
I&#39;m not a big getopts user so I&#39;m going to assume that&#39;s all working correctly. I have a vague memory that<br>
it had some kind of notation for which options were required, but I could be confused.<br>
<br>
There is a handy little dev file /dev/stdout you can use for standard out when you need a file placeholder.<br>
I don&#39;t see exactly in your script where OUTFILE could be empty, so I just added a check before the &quot;for file in&quot;:<br>
<br>
So you could make the last block a lot more concise like this:<br>
<br>
[ -z &quot;${OUTFILE}&quot; ] &amp;&amp; OUTFILE=/dev/stdout<br>
for file in install network services partitions packages pre post<br>
do<br>
   if [ -f &quot;${file}.${RELEASE}.${SUFFIX}&quot; ]<br>
     cat &quot;${file}.${RELEASE}.${SUFFIX}&quot;<br>
   elif [ -f &quot;${file}.${RELEASE}&quot; ]<br>
     cat &quot;${file}.${RELEASE}&quot;<br>
   else<br>
     cat &quot;${file}&quot;<br>
   fi<br>
done &gt; &quot;${OUTFILE}&quot;<br>
<br>
In Linux we don&#39;t often get files/directories with white space in them, but I always try to account<br>
for the possibility. Hence the added double quotes around &quot;$OUTFILE&quot; etc.<br>
<br>
Ok I lied--not always--typing all those quotes does get old. But usually at least if it&#39;s meant to be a<br>
long-lived script and/or other people will use it. I have the same problem w/ the curly braces on<br>
variables. At least with them, it&#39;s not dependent on the value of the variable--if it works without the<br>
curlies, it&#39;ll always work.<br>
<br>
One minor stylistic/convention point. I notice you sometimes use all caps variable names and sometimes<br>
lower case. I was taught that environment variables were all-caps to differentiate them from the ones<br>
in your scripts. So I believe OUTFILE, RELEASE, etc. should all be lowercase. The first shell variables<br>
people learn about are environment variables so they seem to think all shell variable should be caps,<br>
and this old convention is widely ignored or unknown, or maybe I was taught wrong :-P get off my lawn!<br>
<br>
FWIW, I&#39;ve written many shell scripts over the years and never known a missing line-end semicolon to<br>
cause problems. Well at least if you actually end the line. You need them if you want to type<br>
{ cmd-a; cmd-b; }<br>
instead of<br>
{<br>
   cmd-a<br>
   cmd-b<br>
}<br>
Not to say there isn&#39;t some edge case, but I&#39;d be very curious to see it. Then again,<br>
I sometimes add the superfluous semis out of habit from other languages.<br>
<br>
Scott<br>
<br>
p.s. One last thought occurred to me. After fixing whatever typos, you could try something like this:<br>
<br>
for prefix in install network services partitions packages pre post<br>
do<br>
   for file in &quot;${prefix}.${RELEASE}.${<u></u>SUFFIX}&quot; &quot;${prefix}.${RELEASE}&quot; &quot;${prefix}&quot;<br>
   do<br>
     [ -f &quot;$file&quot; ] &amp;&amp; { cat &quot;${file}&quot;; continue 2; }<br>
   done<br>
done &gt; &quot;${OUTFILE}&quot;<br>
<br>
<br>
----- Original Message -----<br>
<br>
From: &quot;Leam Hall&quot; &lt;<a href="mailto:leamhall@gmail.com" target="_blank">leamhall@gmail.com</a>&gt;<br>
To: &quot;Atlanta Linux Enthusiasts&quot; &lt;<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>&gt;<br>
Sent: Saturday, April 11, 2015 10:22:59 AM<br>
Subject: [ale] Anyone want to crtique a shell script?<br>
<br>
Could use critique on a shell script that writes Kickstart files. You<br>
don&#39;t have to understand Kickstart to critique, the output files are<br>
plain text in a certain order.<br>
<br>
<a href="https://github.com/LeamHall/SecComFrame/tree/master/tools/ks_writer" target="_blank">https://github.com/LeamHall/<u></u>SecComFrame/tree/master/tools/<u></u>ks_writer</a><br>
<br>
The script is ks_writer.sh and the other files there are what gets<br>
pulled in and what an output might look like.<br>
<br>
Thanks!<br>
<br>
Leam<br>
______________________________<u></u>_________________<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/<u></u>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/<u></u>listinfo</a><br>
______________________________<u></u>_________________<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/<u></u>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/<u></u>listinfo</a><br>
<br>
</blockquote>
______________________________<u></u>_________________<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/<u></u>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/<u></u>listinfo</a><br>
</div></div></blockquote></div><br></div>