Re: Syntax Question...

[Linda Walsh]

Ken Irving wrote:
> On Mon, Aug 15, 2011 at 08:19:01PM -0700, Linda Walsh wrote:
>   
> > > > 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?
> > >       
> > ...
> > What would you do to search for files w/wild cards and return the output
> > in a list?
> >     
> Maybe this?
>     today_snaps=( ${snap_prefix} )
>   
----
  but as you mention, that will put them into an array....sorry "imprecise
terminology".... list for me is some number of objects in a string 
separated by some
separator.

I don't use list to mean 'array', though I see now how it could have 
been taken that way.

> e.g., given:
>     $ ls note*
>     note  note-to-bob  note-to-bob.txt
>     $ unset foo bar; bar=note\*; foo=($bar); echo ${foo[@]}; echo $foo
>     note note-to-bob note-to-bob.txt
>     note
> This result is an array; if you really want a string,
>   
----
You are about to tell me what I already did...
Look closely at the line...it's:

      today_snaps="$( )".... 

$() acts like a variable syntactically -- the results will be
separate words when re-evaluated unless there are quotes
around it like I have. So I think I'm already using the case
you mention next:

>     $ unset foo bar; bar=note\*; foo="$bar"; echo ${foo[@]}; echo $foo
>     note note-to-bob note-to-bob.txt
>     note note-to-bob note-to-bob.txt
> From bash(1):
>    Pathname Expansion ...[snip]
>
> I'm guessing the 'Ack!' was maybe for 'useless use of subshell'?
>   
maybe?   Maybe he had a hairball and it was like a can'ts Gack!?  ;-)


> It seems to me that there are real bugs in applying set -e that can only
> be fixed by handling more special cases in the bash code,and those cases
> may vary for different scripts. 

> [snip]
>     set ...
>     -e  The shell does not exit if the command that fails is part of the
>         command list immediately  following  a while or until keyword,
>         part of the test following the if or elif reserved words,
>         part of any command executed in a && or || list except the
>         command following the final && or ||, any command in a pipeline
>         but the  last,  or  if  the  command's return  value  is being
>         inverted with !
>   
> A constructive contribution might be made by seeing if you can add your
> special cases to that list, even better if you can help by identifying
> where it might be done in the code.
>   
-----
ARRGGG...these were not special cases, they were has bash normally
worked in in it's non-posix mode SINCE they were created! (3.0 and
up through 4.0).  

****4.1 breaks the previous standard.**** -- it's not compatible with
bash 3.0 or 4.0 in this regard

Example:  from 2 different linux systems, one w/bash 4.0 and one w/
the broken 4.1 (which will likely be reverted to 4.0 very soon if 4.1
doesn't get a fix)..

Here is a working 'bash (4.0) vs.  current, below:

   Astarte:/tmp> rpm -q bash
   bash-4.0-18.4.1.i586
   Astarte:/tmp> ( set -e ; ((a=0)); echo "are we here?"  )
   are we here?
   Astarte:/tmp>

Now for the current behavior:

   Ishtar:/tmp> rpm -q bash
   bash-4.1-20.25.1.x86_64
   Ishtar:/tmp> ( set -e ; ((a=0)); echo "are we here?" )
   Ishtar:/tmp>

----
You see the difference?   In 4.0, the assignment didn't cause
an errexit. -- ((a=0)) has NEVER cause an errexit since it
was introduced in bash 3.x[0?]    This is the now broken behavior
and it was done to make one of bash's extended features compatible
with POSIX -- which is a very BAD reason, as Bash has a posix mode
for that -- and that POSIX mode changes shouldn't be
contaminating the BASH-extended set.

That's what I referred to about w/Chet being on the posix
committee, he might be losing perspective about the 'extended part'
of bash which has never been required to be posix compliant --
that's what the "--posix flag was for.

I'm not asking for something "new", I'm asking for compatibility with
the versions 3.0 -> 4.0

Here's the quote from 4.0 on set -e:

      set ....
             -e      Exit immediately if a pipeline (which may consist of a
                     single  simple  command),  a subshell command enclosed
                     in parentheses, or one of  the  commands  executed  as
                     part  of  a command list enclosed by braces (see SHELL
                     GRAMMAR above) exits  with  a  non-zero  status.   The
                     shell  does not exit if the command that fails is part
                     of the command list immediately following a  while  or
                     until  keyword,  part  of the test following the if or
                     elif reserved words, part of any command executed in a
                     &&  or  || list except the command following the final
                     && or ||, any command in a pipeline but the  last,  or
                     if  the  command's return value is being inverted 
with !

-----------------

Note the above -- says it will exit on a "pipeline".....
as 'let' and '(())' did not take or accept I/O, they wouldn't
normally be considered part of a pipeline -- and Greg has
mentioned that ((1)), is a 'complex' command not a simple command
(but it can't be used as part of a pipeline...)


> Ranting, inferring that people have 'little minds', aren't good
> or skilled programmers, etc., does little to make things better.
> Excessive verbosity, lingo, abbrevs, etc., don't help either. ;
>   
----
   Ranting -- ?  I've only been continuing because no one seems
to know that "-e" *worked* in 3.0-4.0  in a reasonably reliable and
respectable manner.   4.1 broke that.


   In regards to 'little minds',  in Hemingway's day it
referred more to someone who wasn't likely to think "outside
the box"  -- i.e. too rigid and run by the 'rules of consistency'
in their head...  It's wasn't about intelligence, at least that's
not my impression.