[patch] rc.d cleanup

diz at linuxpowered.com diz at linuxpowered.com
Mon Aug 1 18:30:22 GMT 2005


> Giorgos Keramidas wrote:
>> On 2005-08-01 13:55, John Baldwin <jhb at freebsd.org> wrote:
>> >On Monday 01 August 2005 01:29 pm, diz at linuxpowered.com wrote:
>> >> This patch effects most of the rc.d scripts that utilize simple IF
>> >> statements, converting them to logical AND/OR's instead. For example:
>> >>
>> >> if [ ! -f foo ]
>> >> then
>> >>     bar
>> >> fi
>> >>
>> >> Would simply become:
>> >>
>> >> [ -f foo ] || bar
>> >>
>> >> The exception (but not the rule) is for any situation where ELIF/ELSE
>> is
>> >> required. In other words any exclusive conditional situations.
>> >>
>> >> I also applied this notion to many simple blocks of code wrapped
>> around
>> >> non-exclusive IF statements, such as:
>> >>
>> >> [ -f foo ] && {
>> >>    command-list
>> >>    [...]
>> >> }
>> >
>> > The argument I would have against this is that it is a lot easier to
>> > read the 'if foo; then ; fi' style, esp. for folks used to using C,
>> > etc.  Shell scripts don't need to be overly obfuscated.
>>
>> Ditto.  The if/then blocks may look superficial at first and entirely
>> redundant, but they really work much better then code like this:
>>
>> 	[ -f foo ] || bar
>>
>> has to be extended to form a multiline statement.  Now, I know that one
>> can always write:
>>
>> 	[ -f foo ] || {
>> 		[ -d bar ] && {
>> 			blah
>> 		}
>> 	}
>>
>> But this quickly gets too ugly for my taste.  The equivalent if/then
>> blocks:
>>
>> 	if [ ! -f foo ]; then
>> 		if [ -d bar ]; then
>> 			blah
>> 		fi
>> 	fi
>>
>> or even, the similar:
>>
>> 	if [ ! -f foo ] && [ -d bar ]; then
>> 		blah
>> 	fi
>>
>> Look much much prettier to the eyes of one who knows how to read both
>> shell scripts and C code.
>
> Thirded.  I far prefer the bigger C-like if statements and think this
> patch is a huge code churn for what is basically code obfuscation.
>
> Cheers,
> Maxime


Well I certainly respect the opinions, but respectfully when has the use
of && and || become obfuscation? Secondly, the use of shell style blocks
of code is similar to the way they are done in C where curly-braces are
used to enclose blocks of code. I honestly don't believe that it is
because of people who look at C and shell code, it is probably more due to
the foundation of all that existing shell code we read that does use IF
statements instead of logical AND/OR. What is the point of using a bulky
IF statement for the evaluating simple true/false situation that the shell
supports with && or ||? I would characterize this patch as a
simplification, or rounding down to the lowest common denominator. It
doesn't touch the parts that require the bulky ELIF/ELSE's, just the
simple conditions. However, I would be willing to make the patch less
"code-churning" to only affect the non-blocks of code, aka one-liners
like: [-f foo ] && bar. I don't have the intention to obfusecate, just
good shell code. =)

-Jon



More information about the freebsd-hackers mailing list