bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inline `ifdef style` debugging


From: Steven W. Orr
Subject: Re: Inline `ifdef style` debugging
Date: Mon, 08 Aug 2011 13:20:25 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11

On 8/8/2011 1:09 PM, Roger wrote:
On Mon, Aug 08, 2011 at 08:56:36AM -0500, Dennis Williamson wrote:
On Mon, Aug 8, 2011 at 3:47 AM, Roger<rogerx.oss@gmail.com>  wrote:
I'm doing some research for one of my scripts and always liked the C style
ifdef inline debug statements.

...

Another way to write the _debug() function:

#!/bin/bash
debug=true

# Function to optionally handle executing included debug statements
_debug()
{
   debug&&  "$@"
}

Using this method, you don't really need a function at all. You can
just use the debug variable directly (you could use an underscore
prefix):

   $debug&&  printf "Checking depedencies...\n"

   $debug&&  {
        # it's even more like ifdef since you can conditionally
execute blocks of code
        foo
        bar
    }

You have to make sure that $debug contains only "true" or "false" or
you'll get errors. There are exceptions to this, but the complexity
isn't worth the effort.

This is interesting because I'm guessing it might save one or two CPU
cycles, although it still does use a test at "&&", and is still
readable, if not more readable then before.

I prefer using lowercase or mixed case variable names by habit to
reduce the chances of name collisions with predefined variables
(although that's not an issue with this specific script).

I know the system capitalized defined variables, so I usually just use
all capitalized variable for global script variables within the
header/top of the bash script.  I've heard of the risk of collision,
and have tried mixed-case variable names, but they were not as readable
and the risk seemed more minimal ... unless a Linux distribution makes
up a system variable that conflicts with one of my all capitalized
variable names.

I then use lower case for locally used variables within the Bash script or
within the functions of the script.  Similar to C.  It just makes good
sense, and I know where to look for predefined capitalized variable names
for their definition.

Since you're writing a script for Bash, you might as well use Bash
features. Here is the main line of your function a couple of more
different ways (using the original capitalization and value):

   [[ $DEBUG != 0 ]]&&  "$@"            # string comparison
   (( DEBUG != 0 ))&&  "$@"              # integer comparison (note,
the $ is unnecessary)

Yup.  I was thinking of sticking with 0's&  1's, as text comparison
requires more CPU cycles ... although negligible these days, it's just
good programming practice.


Two things:

1. Worrying about lost cycles every time you call _debug because it checks to see if debug is True is pretty miserly. If you *really* have to worry about that kind of economics then it's questionable whether you're even in the right programming language. Having said that, you can certainly create a function that is defined at startup based on the value of debug. Remember that functions are not declared, their creation is executed.

if (( debug ))
then
    _debug()
    {
        "$@"
        # I do question whether this is a viable construct, versus
        # eval "$@"
    }
else
    _debug()
    {
        :
    }
fi

2. The other thing is that instead of

#!/bin/bash
debug=true

at the beginning of the file, you can just say:

#! /bin/bash
: ${debug:=0}   # or false or whatever feels good.

Then when you want to run the program with debug turned on, just say:

debug=1 prog with various args

and the environment variable will override the global variable of the same name in the program, an only set it for the duration of the program.

Is this helpful?


--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]