Re: Syntax Question...

[Dennis Williamson]

http://mywiki.wooledge.org/XyProblem

I suspect that you are hung up on the way to do something and have
lost sight of (or failed to tell us) what it is you're *actually*
trying to do.

If what you're trying to do requires complex data structures, you're
either doing it wrong in Bash or Bash is the wrong tool. It does not,
in and of itself, mean that Bash is in some way flawed. Pliers and
wrenches have some overlap in their capabilities, but you're better
off using the one that's better suited for the task than to curse the
design of the wrong one.

We can be much more help if you provide specifics and omit *all* hyperbole.

Show some code, describe *specifically* what the starting conditions
are and what the desired *end* result is and we can fix your code.

While Bash, like *all* software, has some bugs and even regressions,
for most uses it's more than adequate. While I'm sure there are many
successful, production 1500 line shell scripts, I would say that's
getting into the size that they should have been written in something
else or in some cases, better use of loops and functions would shorten
them and make them more readable and maintainable.

Also, don't worry about POSIX unless portability is an issue that you
must contend with. If you are writing scripts for a well-defined
environment in which you can safely expect certain dependencies to be
met then go ahead and make full use of all the facilities available
under those conditions.

Please show some code.

On Sun, Aug 14, 2011 at 10:15 PM, Linda Walsh <bash@tlinx.org> wrote:
>
>
>
> ` Dennis Williamson wrote:
>>
>> On Sun, Aug 14, 2011 at 6:31 PM, Linda Walsh <bash@tlinx.org> wrote:
>>
>>>>>
>>>>> please show quote the section
>>>>> that shows using an variable that holds the name of an array to be used
>>>>> (and assigned to)....
>>>
>>> ====
>>> The FAQ covers indirect,
>>> it covers arrays,
>>> but I see no place where it covers the combination.
>>>
>
> ----
>   That's EXACTLY what I said -- it doesn't show anyway to do it, in fact,
> it points the the exact problem I've been complaining about is bash's
> instability
> in it's extended features.   I thought it would be like perl -- stable
> progression, not
> random jumps that break code.
>
>   All he's saying is bash "shouldn't" or "can't (with any stability), but
> used for
> anything complex.
>
>   He may be right.
>
>   Personally I think it sucks.
>
>   I was very happy with bash's extensions, and their progression -- right up
> to this
> last revision, when functionality was removed, and others functionality was
> broken
>
> -- I USE tabs when typing a program into bash -- not all the time, but
> now I can't -- in "single quotes", it tries to expand to all the words in my
> curdir.
>
> The script I've been working on was suppose to be relatively simple -- but
> given the all
> the error checking I've been putting in, and all of the state tracking so a
> run of the script wouldn't come in and corrupt what had been left by a
> previous run, it's gotten ALOT more complex.
>
> Conceptually...about 8-10 lines of english, -> almost 1500 lines of bash
> code -- MUCH of
> which is to compensate for bashes new broken features.
>
>
> One can claim it's my fault for not using POSIX, but I don't have this
> problem in perl (the python people did...)....  maybe I haven't appreciated
> how stable perl has been -- like C.
>
> But
> 1) create snapshot
> 2) look for oldest active snapshot
> 3) rsync the diffs from the oldest snapshot compared against current to a
> 'diff vol'
> 4) create new 'static vol' sized to content on diff vol, and get rid of the
> oldest active snapshot.
>
>
> That's. IT!
>
> But...
> .9) see if we have already created a snapshot today and require an override
> flag
> 3.5) label diff vol  with content label of snapshot this came from.
> with labeled diff vol, can remove old active snapshot (which needs to be
> removed
> before creating a new one w/same name & same mount point, but static)...
> (could create new vol, and do renames, but would result in >lvm
> fragmentation).
> 2.8) before copying to diff dir -- make sure it is the correct mounted file
> system and
> delete it's contents (dependent on there being a "valid snap copy"...)
>
> which doesn't get set until the diff dir is copied to the new static stap
> and IT gets
> a label -- saying that the diff-copy completed successfully.
>
> etc.
> etc.
> etc...
>
>
> It's just been growing...
> (I didn't come close to listing all the checks that are in there now)...
>
> So conceptually --- looked like a simple shell script.
>
> but...to handle bash's broken error handling, all steps have to be
> 'interlocked' --
> state 'checked' into a file system, and validated before going to the next
> step.
>
> Otherwise, I end up with more problems than you want to know about.
>
>>
>> Please try to be briefer and more on topic in your posts to this list,
>> by the way.
>>
>>
>
> I'm stopping now.
> Maybe not entirely on-topic, but I wasn't the one who started a side
> conversation by
> claiming that the information I needed was on URLxxyz...when it wasn't.
>
> It wasn't obvious from anyone that there was some subtle hint that trying to
> use
> bash for things like this was ridiculous (if that's the message I was
> supposed to get
> from reading it).    I may be tending more to to agree....but I honestly
> thought bash seemed forwardly stable....with broken compat, being relegated
> to
> --posix mode.   I'm slow to change when things 'break' -- I'd prefer to try
> to get them
> fixed, or fix them, than move-on.   I know -- most people just move
> on...whatever.
>
> Thanks for the clarification (I think?)...
>
>
>
>
>



-- 
Visit serverfault.com to get your system administration questions answered.