[Top][All Lists]

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

Who's the target? Was: Inline `ifdef style` debugging

From: Steven W. Orr
Subject: Who's the target? Was: Inline `ifdef style` debugging
Date: Mon, 08 Aug 2011 15:07:15 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11

On 8/8/2011 2:38 PM, Roger wrote:
On Mon, Aug 08, 2011 at 01:20:25PM -0400, Steven W. Orr wrote:

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 ))
         # I do question whether this is a viable construct, versus
         # eval "$@"

2. The other thing is that instead of


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?


I've decided to use Mr. Williamson's suggestion:

     [[ $DEBUG != 0 ]]&&  "$@"

The reply above was very helpful and might provide people searching for
"ifdef style debugging" for Bash further info on inline debugging techniques.

The above does complete the task of inline ifdef style debugging, however, I
think it might confuse or slight hinder readability for some beginners.

I'll flag email and restudy it later as I think this "ifdef style" is the
better method versus having a function read every time even though it isn't
executed at all!

Thanks, I think ;-)

But you raise an interesting question: When I write code, am I targeting the person who knows less of the language, and so therefore I should dumb my code down? Or should I feel free to use the well documented constructs that I went out of my way to learn (and of course to doc what I write)?

Imagine a code base of 10s of thousands of lines of bash, where there are no shared modules, no arrays, almost no error checking, no local variables, no command line option parsing, no anything that's not completely vanilla. In short, only constructs that contributed to Sun's succeeding for years at foisting the Cshell on people.

Languages come in different sizes. C is small, PL/I is large. I'd categorize bash as somewhere in the middle. If you're in high school, then the name of the game is to write a program that prints the right answer. If you're a professional software engineer, then the name of the game is to write high quality, industrial grade code, that is well documented, and targets the reader of the code with all the information (s)he needs to understand just what this verfluchtiges thing is trying to do.

It can be very frustrating that people will go out of their way to write compiled code in painstaking detail, but then when they get to shell scripts, they throw their hands up and just get it done with no concept of doing it well.

Two examples: New person out of school is told to write something and to use some code that almost does what they want from Big Blue. The guy who wrote the code from Big Blue clearly thought that all he knew from Csh should be used in his bash scripts.

Only that were
if ( test $? -eq 0 )

Another case: There's a guy in a well known Journal of Linux magazine who writes a column on bash scripting. He wouldn't know it if he got bashed in the face with his junk properly written. He seems hell bent on doing things with as many possible processes; basically pushing the limits of what a junior Bourne shell guy might have mastered years earlier.

I didn't mean to go on a rant, but this list here should not be another place that discourages people from learning more of the language elements that allow us to do better work. Obscure features are in the mind of the uneducated. Doc your code well, but don't engage in elbow kissing in the misdirected intent to make the code simpler.


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]