[Top][All Lists]

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

Re: Syntax Question...

From: Linda Walsh
Subject: Re: Syntax Question...
Date: Mon, 15 Aug 2011 20:19:01 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Thunderbird/ Mnenhy/

` Dennis Williamson wrote:

Greg already covered some important points and I'll add a few more.
sorry, I just haven't responded ... I threw up my hands in disgust and got too
irritated to respond, so have done other things.

As has been said before, don't use "bash -e".
   Why don't you convince Chet to remove it then?

   Why don't you convince him how useless it is because it is NOW broken
(it USED only exit on simple commands -- now it exits on complex commands like
calculations.  This makes it very unuseful).

   You never answered my Q before.

   Do you run perl with "-w" and 'use strict;'

Or do you claim they are crutches and no substitute for proper error checking.

If your answer isn't the same, then you should be supporting me in getting -e fixed and more useful.

One isn't a substitute for the other.
How do I determine the location of my script?
??? I don't understand the need for complexity -- what I have works. Its a few lines@ most -- I use the same in perl. has worked for years. But then I'm not running
the scripts on remote systems via 'ssh'....

I don't need to fix problems that aren't broken.

To process your arguments, use "case" instead of a string of if/else.
You could instead use "getopts" if you only needed to support short
options (or if you're brave you could use the external getopt(1), but
there are versions that work and those that don't). See
I don't like case as well...not as flexible. I've used it...had one case in this code where I was using 'case' ... it depends on how many arguments I'm parsing...

10-20 -- then a case statement is probably appropriate, but a few options.
if/else is easier to type and read.

In your arg processing, you copy $@ into $arg, but then you assign
each argument to elements in $arg individually as you iterate over 
Why? Also, it's usually not necessary to maintain an index variable
and use shift in a while loop. Use "for arg; do" which uses an implied
   Actually rewrote that ...but the routine that does the parsing does
while The assignment at the beginning was an forsaken method of dealing.
The for arg ;do = implied $@, intesting...
I would have ended up with "for arg in "$@";"...at the very least...it might
work...I wasn't sure, since at one point I was thinking to remove things from the $@ arrray, but instead I copy the un-matched args into 'args', and do a 'set' on ${args[*]}
in the main prog (or did before I rewrote that this morning...)

Now process_args returns an eval string that is eval'ed directly -- so no
assigning to vars, and extra assignements afterward just:

eval "$(process_args "$@")"

--- will set all the prog's globals, PATH, flags, etc...

I have no idea what "if [[ ${var:-} ..." is intended to do.
It protects against "-u" killing the prog. if you just reference var and it isn't defined, it dies. (a good thing in most programmer's minds)....one reason why perl
authors recommend -w+use strict;)....

-u is another good one to run -- and a reason to run "-e" and make it work. You can't
implement error checking for EACH reference to a variable name.

using -ue tries to make sure if you reference an undefined/unset variable, then you'll get an exception. Most languages consider use of such a feature MANDATORY -- otherwise, how do you catch typos? This is why I scratch my head at people who say -eu is useless. Many experience programs (will say you are just being careless if you don't turn on such checking -- since many many errors of of the typo/mispelling variety. For people who don't use -ue, those error will silently pass by and cause unpredictable
program behavior.   I don't like such behavior in my programs -- generally.

"if -v have_dep" in one place (which probably results in a "command
not found error" and "if have_dep -v" in another. I think something
got transposed.
   Already found earlier today and fixed.

"mp_dev_is_not_same_as_2nd_fs" - Ack!
what's wrote with "mountpoint dev is not same as a 2nd fs that is passed in"

I use long var names so I know what the heck the darn thing does (or is supposed to do...and now you do to. It checks the devs of a mountpoint, and and 2nd fs passed as an arg and checks if they are the same 'fs'. I try to verify I'm not deleting or copying on files from/to the wrong target. I also set 'root_dev near the beginning of the prog to make sure that my script isn't about to try to do something to the root 'fs', since
it needs root privs to do all it does, it could cause problems.

I could go on (and on), but this is making me tired. I didn't intend
for you to post an entire script (and its subscripts). Rather, I
intended that you post a problematic section of code and specific
goals for that portion. Then we could help you make that bit of code
accomplish its intended result (while simultaneously avoiding an XY
Oh my gawd... I don't have any *specific problem sections*...just a long string of special cases I need to check for and check for and check for...ad infinitum.

The entire time I've been posting, the code has been changing and I'm usually hitting different problems at different times....like the Q about the indirect arrays...I wanted to support lists in the dependency chains, but I worked around that by relying on the fact that my 'depnames' have similar restrictions as varnames. i.e. spaces won't be
a problem .

snap_today="$(date +%Y.%m.%d-)"
today_snaps="$('ls' -1 ${snap_prefix} 2>/dev/null |tr "\n" " " )"

This one is so bad, I saved it for last. Ack! Pfffft! Wait, what? Why?
What the? Huh?
you left of the lines before it that explain it...(fixed that for ya!)
for a 'mp'=home, it looks for

w/today's date -- the "*" would match any time.

'ls' -1 lists them 1/line, if it isn't found, the errors goto devnull, and any filenames
are put on the same line and space separated and stored in 'today snaps'...

That, by default will force a program halt unless you tell it what to do (at least at this point), with the --Force=<string w/options to override some behaviors, currently only two behaviors are detected that way, both related to the today-snap case,
'snap_today' (force a snap today), and 'skip_today_snap':
   if [[ $Force =~ ^.*skip_today_snap.*$ ]]; then
           chk_today_snap "$base_mp" "$Force"
           add_provides new_snapshot_wanted

--- that way I can skip over that check AND a new snapshot won't be created
(because the snapshot wanted flag isn't set).

That's what I mean by 'interlocks'... Am trying to 'interlock each step', so error damage is minimal and recovery can pick up where a previous run ran into a problem.

If everything always worked perfectly, I wouldn't need about 'half' or more of this
program (which is devoted to error checking, and debugging)....

So...I had 'echo' there, before, but for some reason,, it wasn't expanding, so I went
with 'ls/tr'....tried and true!

What would you do to search for files w/wild cards and return the output
in a list?

I'm sorry if you feel you waisted your time, I usually don't stay stuck on something for too long. If I do, I just go do someting else for a while, usually when I get away from something, I'll get a different insight or something will hit me -- and I can fix the problem.

You were not very specific about what you wanted to see in the way of code, and because the code is heavily parameterized and uses many functions, if I didn't
include the whole body, they I was sure you'd ask me what 'xxyz' did because
it wasn't referenced in the code you were looking at.

I did get a successful run-through and am close to another .... then I can work
on cleanup and optimization if I am motivated...

Thanks for the comments, hope I explained a few things...

and thanks for the 'for arg;do'....nice

reply via email to

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