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 ))
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?
Yes.
I've decided to use Mr. Williamson's suggestion:
_debug()
{
[[ $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.
No?
--
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
