Re: Syntax Question...

[Linda Walsh]

` Dennis Williamson wrote:
> On
> >     
>
> Greg already covered some important points and I'll add a few more.
>   
----
   *cough*....
   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?
> http://mywiki.wooledge.org/BashFAQ/028
>   
???  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
> http://mywiki.wooledge.org/BashFAQ/035.
>   
----
   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
> problem).
>   
=====
   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 .


>   
> > prefix="snapdir/@GMT-"
> > snap_today="$(date +%Y.%m.%d-)"
> > snap_prefix="$mp/$prefix$snap_today*"
> > 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

     /home/snapdir-@GMT-YYYY-MM-DD-*
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
   fi

--- 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