Re: status on $[arith] for eval arith vsl $((arith))??

[Maarten Billemont]

On 08 Apr 2012, at 01:47, Chet Ramey wrote:
> On 4/7/12 4:45 PM, Linda Walsh wrote:
>> 
>> 
>> 
>> In modifying some released code on my distro,I ran into the extensive use
>> of   $[arith]  as a means for returning arithmetic evaluations of the
>> expression.
>> 
>> I vaguely remember something like that from years ago, but never see any
>> reference to
>> it -- yet it works, and old code seems to rely on it -- and
>> "$[(1+2)/3]"  looks cleaner than "$(((1+2)/3))".  So what's up with that?
> 
> It dates from Posix circa 1990 (1003.2d9, of which I've lost my paper
> copy).  I implemented it after the Berkeley guys, mostly Marc
> Teitelbaum, put it into Posix.  It ended up getting dropped in favor
> of the ksh $((...)) expansion, at which point everyone deprecated the
> old $[...].  I removed it from the manual sometime later, but it still
> works as it always has.
> 
> Chet


Any particular reason for not removing old undocumented functionality, or is 
that mostly the nature of this beast - dragging along and maintaining ancient 
code for the sake of compatibility?

smime.p7s
Description: S/MIME cryptographic signature

Re: status on $[arith] for eval arith vsl $((arith))??

[Chris F.A. Johnson]

On Sat, 7 Apr 2012, Linda Walsh wrote:


In modifying some released code on my distro,I ran into the extensive use
of   $[arith]  as a means for returning arithmetic evaluations of the 
expression.


I vaguely remember something like that from years ago, but never see any 
reference to

it -- yet it works, and old code seems to rely on it -- and
"$[(1+2)/3]"  looks cleaner than "$(((1+2)/3))".  So what's up with that?


   At the minor expense of a few extra keystrokes, $(( (1+2) / 3 ))
   looks just as clean, and has the added cachet of being portable.

--
   Chris F.A. Johnson, 
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Re: status on $[arith] for eval arith vsl $((arith))??

[Chet Ramey]

On 4/8/12 3:02 PM, Maarten Billemont wrote:

> Any particular reason for not removing old undocumented functionality, or is 
> that mostly the nature of this beast - dragging along and maintaining ancient 
> code for the sake of compatibility?=

Because, as Linda discovered, there is still working code out there using
it.  Maybe we'll get to a point where it's all gone, but we're not there
yet.
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: status on $[arith] for eval arith vsl $((arith))??

[dethrophes]

ever thought of going the depreciation route.
Something like what microsoft do with vc.

I.e. give a warning for depreciated constructs. With a hint as to how to 
do it better?


Am 08.04.2012 21:30, schrieb Chet Ramey:

On 4/8/12 3:02 PM, Maarten Billemont wrote:


Any particular reason for not removing old undocumented functionality, or is 
that mostly the nature of this beast - dragging along and maintaining ancient 
code for the sake of compatibility?=

Because, as Linda discovered, there is still working code out there using
it.  Maybe we'll get to a point where it's all gone, but we're not there
yet.

Re: semicolon at beginning of line

[Steven W. Orr]

On 4/7/2012 4:00 PM, Elliott Forney wrote:

I wish bash would happily execute lines that begin with a semicolon,
i.e., treat it as a no-op followed by a command.  The following
examples come to mind:

$ infloop&  echo hello
[2] 11361
hello
$ infloop&; echo hello
bash: syntax error near unexpected token `;'

$ echo hello; echo world
hello
world
$ echo hello;; echo world
bash: syntax error near unexpected token `;;'

$ ; echo hello world
bash: syntax error near unexpected token `;'

Any thoughts?

Thanks,
   Elliott Forney


Just use a colon.

: echo Hello world.

I use it all the time to 'park' a command in my history. Then when I'm ready, I 
just back up to it and remove the colon.



--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

Re: semicolon at beginning of line

[Joseph Fredette]

Could also use a #, no?

On Sun, Apr 8, 2012 at 8:46 PM, Steven W. Orr  wrote:

> On 4/7/2012 4:00 PM, Elliott Forney wrote:
>
>> I wish bash would happily execute lines that begin with a semicolon,
>> i.e., treat it as a no-op followed by a command.  The following
>> examples come to mind:
>>
>> $ infloop&  echo hello
>> [2] 11361
>> hello
>> $ infloop&; echo hello
>> bash: syntax error near unexpected token `;'
>>
>> $ echo hello; echo world
>> hello
>> world
>> $ echo hello;; echo world
>> bash: syntax error near unexpected token `;;'
>>
>> $ ; echo hello world
>> bash: syntax error near unexpected token `;'
>>
>> Any thoughts?
>>
>> Thanks,
>>   Elliott Forney
>>
>
> Just use a colon.
>
> : echo Hello world.
>
> I use it all the time to 'park' a command in my history. Then when I'm
> ready, I just back up to it and remove the colon.
>
>
> --
> Time flies like the wind. Fruit flies like a banana. Stranger things have
>  .0.
> happened but none stranger than this. Does your driver's license say Organ
> ..0
> Donor?Black holes are where God divided by zero. Listen to me! We are all-
> 000
> individuals! What if this weren't a hypothetical question?
> steveo at syslang.net
>
>

Re: status on $[arith] for eval arith vsl $((arith))??

[Maarten Billemont]

On 08 Apr 2012, at 21:30, Chet Ramey wrote:
> On 4/8/12 3:02 PM, Maarten Billemont wrote:
> 
>> Any particular reason for not removing old undocumented functionality, or is 
>> that mostly the nature of this beast - dragging along and maintaining 
>> ancient code for the sake of compatibility?=
> 
> Because, as Linda discovered, there is still working code out there using
> it.  Maybe we'll get to a point where it's all gone, but we're not there
> yet.


IMO, the working code out there that relies on $[...] either runs on older 
versions of bash, or if the sysadmin decided to upgrade bash, he can assume the 
responsibility to fix the code.  I suppose a deprecation route would make such 
a scenario least painful.  Though I don't think bash has ever taken this 
approach yet (removal of features), it will be unexpected and people will 
likely complain.  In the end one must decide between a lean code base and 
keeping the 1% happy to upgrade.

smime.p7s
Description: S/MIME cryptographic signature