Is bash dying or dead (was Re: 4.1 is "$((( ))) an 'official operator, if $(( )) isn't?

[Linda Walsh]

Chet Ramey wrote:
>  Yes.  It's a case of not saving and restoring enough state across
>  possibly-
>  recursive calls to the shell parser.  (The assignment statement is the
>  key
>  in this case.)
>
> > So, I compared subst.c files from bash-4.1-9 and bash-4.2-10 and was
> > able
> > to build a patch that it seems to make it work.
> > So to all you Bash guru's, can this patch be applied with no extra
> > consequences ?
>
>  No.  The code is in there for a reason.  It's part of the fix for
>  Posix
>  interpretation 217 (http://austingroupbugs.net/view.php?id=217).
>
>  The right fix is to save and restore the right shell context around
>  recursive calls to the parser.  The attached patch does that, and the
>  result passes the rest of the test suite (which obviously needs to be
>  augmented).
----

   Is this a fluke, due to the above changes NOT being 4.1?  Or is this
construction going to break in 4.2:

   '$((( )))'

I wanted to evaluate something and assign result to a var.

so:
  a=$(((-48-16+2**6)))
gives me 'a=0', but
  a=$( ((-48-16+2**6)) )
will give 'a=<nothing>' -- understandable since the arith expression
merely sets status, it doesn't yield up it's value.

Is the first case going to be **'fixed'** to return 'nothing' in 4.2?  
If I understand your response I quoted above, it seems that a space will
be inserted and effectively turn the 1st statement above into the 2nd.

How do I assign something to a?

If I use:
  ((a=-48-16+2**6))    ; throws an error. if -e is on, script exits

Since 'let' functions the same as the above, then

  let a=-48-16+2**6;    ; ALSO throws error.  If -e is on, script exits

Seems like POSIX has made bash as useful (or less so in some ways) as
borne shell.


One of the reasons for 'bash': 'Bo[u]rn[e]' again shell", was to have
bourne shell compat, but have additions that made it more useful and
easier to program in.

It seems like POSIX is trying to kill off the usefulness of Bash -- and
that Bash is becoming 'sh+', rather than 'Bash'.

Unless you change the way you are doing things drastically (may be too
late), I think 'bash' is dead as 'bash' -- and is being 'dumbed down' to
the level of 'sh'.

POSIX is braindead.
Bash shouldn't follow posix unless in --posix mode, as posix mode is
worthless to program in -- as evidenced by the fact that you can no
longer do any calculation safely with let or (()), without fear that
your script will randomly die (oh just don't use command-exit-error
checking...) and you can no longer call functions safely.

Checking the return value of an *external* command that returns a
status, is VERY different than doing a calculation OR calling an
internal function.

I found a problem in one area, where I called a function that saved
state, and toggled tracing or not.  It returned no status -- WRONG!...  
It returned whatever the flag had been set to as the value, so the
caller would get an immediate error that gets handled 'randomly'
depending on how it is called.  When I say randomly, it's not really
'random' in the non-deterministic sense (is anything really random?),
it's just that there are so many odd situations where the error is
caught or not caught it *appears random*  (like events we think are
'really' 'random', they appear so because we don't know the antecedents,
or causes leading up to the event).

I've seen
  if [!] func 'testval'; then
    xxx
  else
    yyy
  fi

Both work AND exit immediately in different pieces of code (have no clue
why -- but in larger prog, the else isn't taken, in a small prog, it is.  
I don't know whether to try to look for a problem in my code, develop a
workaround, nor do I know if anything I code will work in the next
release.


Bash is becoming very unstable -- programs that work in 3.1 won't
necessarily work in 3.2, those in 3.2 aren't compat with 4.0, 4.0 is
different than 4.1, and now 4.2 is different than 4.1.

How can people write stable scripts in an enironment of constant change?  
This is creating the exact opposite of what POSIX is supposed to help!

A 'study in perl', might be useful about now...

By Default, the scripts run for multiple versions -- eventually giving
warnings if something has to be 'deprecated' -- and for new
functionality that might be incompat with old, you have to explicitly  
enable the new feature use ':5.10';...  use 'xxx' (new feature).

Here, we are having an increasingly strict and incompatible POSIX syntax
forced upon bash that is definitely going to cause old programs to fail
or act unpredicatably with little or no warning.

Some of these scripts manage vital system functions -- and now they will
do something 'different' than originally programmed due to added new
   posix 'enhancements'[sic].

Please people, am I being 'over-reactive'?   Or are these valid
concerns?

I don't know what the solution(s) are...  Chet, you are by far the best
qualified to be the lead of the bash project, but your objectivity
appears to have been 'tainted' by your being part of a committee, that
appears to be trying to reduce bash's functionality.   Where as bash was
created to excel, exceed and transcend the reduced functionality of a
strict posix compliant shell yet still offer a posix compatibility mode
for those who desired such reduced functionality.

That's been lost.  Bash is becoming 'posix'.  and the enhanced parts are
being made to conform to posix, killing compat and functionality.

While I see it possible for someone with extremely integrous boundaries,
it is extremely difficult (and, frankly not possible for most people) to
maintain a dual-mind state of being part of the Posix standard creation
and supporting it, and at the same time, having it not affect the
initial mission/purpose for which bash was created.

Can you do it?  Can you fix bash so it's not harmed by the posix
additions in non-posix mode and keep the two missions/purposes separate?   
It would require a high degree of self-monitoring -- creating a 'chinese
wall' in your mind to partition the two parts so influence from one area
wouldn't spill over "oh, that posix justification makes so much sense,
it should be in 'bash's normal mode"....Bzzzt!...Error.

Need to set the integrity level of 'bash's normal devel mode 'higher'
than the Posix mode -- so Posix ideas can't be 'written to (influence)
the 'bash-normal dev', and at the same time, the 'bash-normal dev',
can't use lower-integrity information from the posix-design let it be
'corrupted'...

A real-life example of integrity levels in use is when IE runs in it's
'secure' (not privacy mode) mode.  It runs with a low-integrity (and
uses special dir 'locallow').  The dir it uses has lower integrity!  It
can't write to a normal-user dir as they have 'normal' integrity.  And
normal user processes running at normal integrity can't read files from
local low (as that's where the 'low-integrity', or 'suspect' information
is).

Anyway, doing this stuff in one's head is not something that currently
appears is being done.  I believe it vital that it be done as bash is
becomeing more unstable and less usable w/each release -- and more
previously working scripts 'die'...

And NO ONE can say , well if your scripts were posix compliant...blah
blah blah -- they whole reason they were written in bash and not 'sh',
is to make use of the non-posix compliant features!, so posix
compatibility is a completely invalid point.  It was written for 'bash'
compat, as that is the shell I use everywhere (even on windows), Even
suse's startup scripts use bash features not present in posix.   I
wonder how vendor's scripts will fair with all these changes...

Ideally, you'd have enough influence to move the posix standard to
support more of bash, but given the numbers, I don't see that being
likely.


Ideas?

Comments?


p.s. the current system of 'all or nothing' compat(v), doesn't work --  
since people will want to cherry pick new features, but NOT enable full  
on posix compat, so some sort of bash-level pragma 'use xxxx' or
whatever, would be very useful.