Thursday, August 11, 2011

Re: Warning (HTML included to show prog shipped w/syntax highlighting).

On Thu, 11 Aug 2011, Ben Fritz wrote:

>
>
> On Aug 11, 10:46 am, Gary Johnson wrote:
>> On 2011-08-11, Ben Fritz wrote:
>>
>>> On Aug 10, 5:23 pm, Linda W wrote:
>>>> If I put a space after $( and before th final ), then...it changes
>>>> the semantics of the statment
>>
>>> I think you just guaranteed I won't learn and start using bash
>>> scripting on a regular basis.
>>
>> Yeah, imagine trying to use a scripting language like that.  Oh,
>> wait...
>>
>>     :w!foo
>>     :w !foo
>>
>
> Touché.
>
> On the other hand this is actually consistent with the way Vim does
> things in general, the first is "force a write" which is consistent
> with "force quit", "force edit", etc. and the second is consistent
> with other external-command commands. It's consistent enough I never
> even thought about the fact that whitespace matters in this way. The
> other good example would be :!start vs. :! start in Windows. This one
> has much less reason behind it.
>
> I'm curious now, is there some decent reason the whitespace in bash
> script matter for semantics in the example given?

The OP explained it, perhaps too succinctly:

"""
, but it changes the semantics of the statment (one does an arith cal,
and reurns value, but with spaces, it does the arith and returns the
status of the of wheither or not the 'calc' returned 0 (fail) or
1(pass).
"""

So, roughly:

( ... ) is "do this in a subshell"
$( ... ) is "do this in a subshell and return the text"
(( ... )) is "do this and return true if non-zero, false otherwise"
$(( ... )) is "do this as an arithmetic expression and return the result"

$((( ... ))) can then be either interpreted as:

$( x ), where x is (( ... ))
or
$(( y )), where y is ( ... )

There was discussion of a parsing problem where '$(( stuff ))' is
ambiguous between '$(x) where x is (subshell)' vs '$((math))' on the
Austin group (POSIX) list (I saw it when it spilled to Zsh¹). I think
POSIX formerly didn't actually specify what would be , so it's a bad
idea to use a subshell-starting parenthesis without a space in general,
if you care about portability².

--
Best,
Ben

¹: http://www.zsh.org/mla/workers/2009/msg01324.html
²: http://wiki.bash-hackers.org/scripting/nonportable

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

No comments: