From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 18:30:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B97A16A41F; Mon, 1 Aug 2005 18:30:22 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 538F743D46; Mon, 1 Aug 2005 18:30:19 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 78C05264278; Mon, 1 Aug 2005 13:29:02 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26487-06; Mon, 1 Aug 2005 13:29:00 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id BD5B2264053; Mon, 1 Aug 2005 13:29:00 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Mon, 1 Aug 2005 13:29:00 -0500 (CDT) Message-ID: <52275.68.95.232.238.1122920940.squirrel@68.95.232.238> In-Reply-To: <20050801181014.GA14567@elvis.mu.org> References: <64511.68.95.232.238.1122917387.squirrel@68.95.232.238> <200508011355.19274.jhb@FreeBSD.org> <20050801180254.GB1176@beatrix.daedalusnetworks.priv> <20050801181014.GA14567@elvis.mu.org> Date: Mon, 1 Aug 2005 13:29:00 -0500 (CDT) From: diz@linuxpowered.com To: "Maxime Henrion" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] rc.d cleanup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2005 18:30:22 -0000 > Giorgos Keramidas wrote: >> On 2005-08-01 13:55, John Baldwin wrote: >> >On Monday 01 August 2005 01:29 pm, diz@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