[Top][All Lists]

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

Re: saving bash.....

From: Linda Walsh
Subject: Re: saving bash.....
Date: Wed, 10 Aug 2011 21:39:01 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Thunderbird/ Mnenhy/

Chet Ramey wrote:
> If not, then wouldn't
> $((( ))) be turned into $( (( )) ), meaning the arith returns a
> status,
> and not the calculation.  (I've tested this, and this is the case.

 This is demonstrably false.
   No... you've only proven that you should have a bit of  'compassion'
for my not knowing every sentence of the manpage, as, to paraphrase
you, subbing 'my email, for 'the manpage'

   "When even the briefest reading of [my email] would have revealed:"

1) before the posix quote, I said:

  "Maybe I misunderstood the Posix verbage (not a far stretch), but it
   said: "

[posix quote]

Then I said:

  "It sounded to me like $(( )) would be translated into "$( (xxxx) )",
   turning off arithmetic expansion.  Did I read that ___incorrectly__?

If not, [i.e. if I read it correctly] then wouldn't $((( ))) be turned into $( (( )) ), meaning the arith returns a status, and not
  the calculation.  (I've tested this, and this is the case)."

Which is demonstrably *true*:
 >   a=$(((1+1)));echo "a=\"a\""
 >   a=$( ((1+1)) );echo "a=\"$a\""

I.e. if POSIX was going to require putting spaces inside "$()"
and break up the $(()) construct, it would break expression evaluation.

"*IF* POSIX required inserting spaces", which, if you will note, I sounded
skeptical about (from my '/maybe I misunderstood/' leadin, to the post
question asking if I "read it incorrectly" -- because if I didn't....then: <absurd situation given as example>....

which you then said was "demonstrably false"....  I.e. I asked if I read
it 'incorrectly, and said if not...then  ..."example".

Then you answered my question, with "This is demonstrably false."
Which from the context, I'm pretty sure is not what you meant, you mean
to say "yes, you misread it...it only applies to ....".
If I didn't know better, I'd almost think you have a problem agreeing
with me even when you agree w/me, but I *know* you you aren't like
that, and that you simply missed the previous paragraph -- just like I missed
something in the 5300+ lines of the bash manpage.

So surely you would agree, that having the exact lines one needs from
the bash manpage, memorized and at hand, is something that could be a
bit more challenging that responding to a simple question Now if you
make some minor mistake in reading 6 lines (not counting the posix
quote) or previous quotes), I would hope you'd be able to cut me a little slack if I don't have the entire bash manpage memorized as well
as you!

;-) ? (no insult intended! honest...just asking you (and others) to take a deep breath and not be reactive to what they think I'm am saying but try to focus on what I'm really "trying" (without great success,
but I keep  trying!)  to say...

You have to understand -- I'm frustrated that "paradigms" I've been using for years, are now breaking because bash is "gettin religion" (POSIX) -- which is not IMO, the best way to go for a shell that started out as being a **better** alternative to the POSIX compat shells
available at the time.    I'm _not_ _against_ having a --posix mode
enforce POSIX rules, but some of those rules are 'leaking' into the
"sacred space"  (laugh) of 'useful bash' (which is NOT -- and no one
should confuse  this, is NOT the same as "portable shell script").   If
I wanted to  write in portable shell script, I'd always use --posix, or
just use ksh or bourne shell (or whatever the current standard is)...

That's not why I use bash and that's not where I want to see bash go, as
then we will need a 'ReBash'... (re-bo[u]]rn[e] again...), to overcome
all thew new POSIX limitations introduced into standard bash.

I don't find it useful to have (()) cause exceptions.  It's not a useful
construct -- having it do so means it has to be programmed around.

It's not useful to have a function that is meant to return no value, --
if last calc'ed value was 0, to cause a script to fail....it may be
POSIX, but I'm looking for bash that was useful to write script in and
do some rudimentary programming with -- NOT a POSIX shell, I can get
from Microsoft or any other vendor.

There's no good reason to downgrade the way 'standard bash' works -- people aren't using bash to be 'portable', it has too many 'deluxe
features'...if they want portability, they can turn off the extensions
and force compat w/--posix, but let bash keep it's ***ease of use***,
and, ***comparatively***, user friendly syntax and helpfulness.  Let it
do the 'user-friendly' thing -- NOT the POSIX correctly, which they can
get from any POSIX compat shell or by turning on the "--posix" switch.

People keep talking about how bash'es 'user-friendly' features aren't
POSIX -- most users don't care -- only those who NEED portable scripts
to run on shells other than bash.  And then they can turn on "--posix",
but there's no need to break bash'es current (or now, previous!)
usefulness in the name of POSIX portability, as that wasn't the main
mission of bash -- it wasn't meant to be "just another POSIX
compat/enforcing shell" -- it was meant to be better and easier to user
with more features that users have loved!

Make the POSIX-ification toggle-able via options!  Don't throw out the
original intent and *beauty* that you created in an effort to conform! Allow both to coexist!



reply via email to

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