`[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

`[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Thorsten Kampe]

Hi,

this is kind of a follow-up to 
http://www.zsh.org/mla/users/2011/msg00284.html .

Basically the solutions were `((+VAR))` for zsh and `[[ -n 
${VAR+stuff} ]]` for bash and zsh.

Now my question is, isn't `[[ -n $VAR ]]` equivalent to `[[ $VAR ]]`? 
(`[[ -n ${VAR+stuff} ]]` equivalent to `[[ ${VAR+stuff} ]]`)

Thorsten

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

When I run the following

    [[ $VAR ]] && print yes

I get a parse error. Which is what I expected given the documentation in
section "Conditional Expressions" of "man zshall". Are you seeing different
behavior? What makes you think a bare variable is a valid expression?

On Thu, Apr 9, 2015 at 6:23 PM, Thorsten Kampe <thorsten@thorstenkampe.de>
wrote:

> Hi,
>
> this is kind of a follow-up to
> http://www.zsh.org/mla/users/2011/msg00284.html .
>
> Basically the solutions were `((+VAR))` for zsh and `[[ -n
> ${VAR+stuff} ]]` for bash and zsh.
>
> Now my question is, isn't `[[ -n $VAR ]]` equivalent to `[[ $VAR ]]`?
> (`[[ -n ${VAR+stuff} ]]` equivalent to `[[ ${VAR+stuff} ]]`)
>
> Thorsten
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Thorsten Kampe]

* Kurtis Rader (Thu, 9 Apr 2015 18:31:04 -0700)
> When I run the following
> 
>     [[ $VAR ]] && print yes
> 
> I get a parse error. Which is what I expected given the documentation in
> section "Conditional Expressions" of "man zshall". Are you seeing different
> behavior? What makes you think a bare variable is a valid expression?


```
VAR=

if [[ $VAR ]]
then
    printf "something\n"
else
    printf "nothing\n"
fi
```

Works fine in zsh and bash.

Same goes for 
`[[ $VAR ]] && printf "something\n" || printf "nothing\n"`

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Okay, I had forgotten that a bare string is equivalent to "-n string" in
bash. The zsh documentation makes no mention of this "feature". It probably
works for you and not me because of an option that differs between our two
environments. Although for the life of me I can't figure out what that
option is.

On Thu, Apr 9, 2015 at 6:39 PM, Thorsten Kampe <thorsten@thorstenkampe.de>
wrote:

> * Kurtis Rader (Thu, 9 Apr 2015 18:31:04 -0700)
> > When I run the following
> >
> >     [[ $VAR ]] && print yes
> >
> > I get a parse error. Which is what I expected given the documentation in
> > section "Conditional Expressions" of "man zshall". Are you seeing
> different
> > behavior? What makes you think a bare variable is a valid expression?
>
>
> ```
> VAR=
>
> if [[ $VAR ]]
> then
>     printf "something\n"
> else
>     printf "nothing\n"
> fi
> ```
>
> Works fine in zsh and bash.
>
> Same goes for
> `[[ $VAR ]] && printf "something\n" || printf "nothing\n"`
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]

Bart's reply explains why I get a parse error: Mac OS X still has zsh
v5.0.5 which does not support the bash semantics for a bare string inside
[[ ]]. Even if you don't need compatibility with pre v5.0.6 zsh releases I
would discourage that syntax because of its ambiguity.

On Thu, Apr 9, 2015 at 7:02 PM, Kurtis Rader <krader@skepticism.us> wrote:

> Okay, I had forgotten that a bare string is equivalent to "-n string" in
> bash. The zsh documentation makes no mention of this "feature". It probably
> works for you and not me because of an option that differs between our two
> environments. Although for the life of me I can't figure out what that
> option is.
>
> On Thu, Apr 9, 2015 at 6:39 PM, Thorsten Kampe <thorsten@thorstenkampe.de>
> wrote:
>
>> * Kurtis Rader (Thu, 9 Apr 2015 18:31:04 -0700)
>> > When I run the following
>> >
>> >     [[ $VAR ]] && print yes
>> >
>> > I get a parse error. Which is what I expected given the documentation in
>> > section "Conditional Expressions" of "man zshall". Are you seeing
>> different
>> > behavior? What makes you think a bare variable is a valid expression?
>>
>>
>> ```
>> VAR=
>>
>> if [[ $VAR ]]
>> then
>>     printf "something\n"
>> else
>>     printf "nothing\n"
>> fi
>> ```
>>
>> Works fine in zsh and bash.
>>
>> Same goes for
>> `[[ $VAR ]] && printf "something\n" || printf "nothing\n"`
>>
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>



-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Mikael Magnusson]

On Fri, Apr 10, 2015 at 4:05 AM, Kurtis Rader <krader@skepticism.us> wrote:
> On Thu, Apr 9, 2015 at 7:02 PM, Kurtis Rader <krader@skepticism.us> wrote:
>> On Thu, Apr 9, 2015 at 6:39 PM, Thorsten Kampe <thorsten@thorstenkampe.de>
>> wrote:
>>
>>>
>>> ```
>>> VAR=
>>>
>>> if [[ $VAR ]]
>>> then
>>>     printf "something\n"
>>> else
>>>     printf "nothing\n"
>>> fi
>>> ```
>>>
>>> Works fine in zsh and bash.
>>>
>>> Same goes for
>>> `[[ $VAR ]] && printf "something\n" || printf "nothing\n"`
>>
>> Okay, I had forgotten that a bare string is equivalent to "-n string" in
>> bash. The zsh documentation makes no mention of this "feature". It probably
>> works for you and not me because of an option that differs between our two
>> environments. Although for the life of me I can't figure out what that
>> option is.
>
> Bart's reply explains why I get a parse error: Mac OS X still has zsh
> v5.0.5 which does not support the bash semantics for a bare string inside
> [[ ]]. Even if you don't need compatibility with pre v5.0.6 zsh releases I
> would discourage that syntax because of its ambiguity.

(please don't top post, it's a lot of work to fix the mail before replying)
If you mean ambiguity because VAR might be the string "-z" for
example, there is no such ambiguity. The syntax of [[ ... ]] is fully
parsed before any substitutions inside are made (I think, but it's at
least true for this purpose). (This is unlike [ ... ] which is not
syntax but a shell builtin that gets passed arguments after they're
substituted, globbed, expanded and etc).

-- 
Mikael Magnusson

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Thu, Apr 9, 2015 at 7:46 PM, Mikael Magnusson <mikachu@gmail.com> wrote:

> (please don't top post, it's a lot of work to fix the mail before replying)
>

Please don't lecture others. I hate top posting. I'm 54 and hated the
rising popularity of programs like Outlook which encouraged top posting.
Gmail makes top posting the default. So unless I'm responding to more than
a single point in the original message I take the path of least resistance.
We lost the battle of top versus bottom posting twenty years ago. Move on.


> If you mean ambiguity because VAR might be the string "-z" for
> example, there is no such ambiguity. The syntax of [[ ... ]] is fully
> parsed before any substitutions inside are made (I think, but it's at
> least true for this purpose). (This is unlike [ ... ] which is not
> syntax but a shell builtin that gets passed arguments after they're
> substituted, globbed, expanded and etc).
>

No, I mean ambiguous in the sense that a naive reader of the script might
wonder what the author intended. Really, there's no good reason to save a
couple of characters in this situation. Be explicit about what you intend
to avoid confusion.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Mikael Magnusson]

On Fri, Apr 10, 2015 at 4:59 AM, Kurtis Rader <krader@skepticism.us> wrote:
> On Thu, Apr 9, 2015 at 7:46 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> (please don't top post, it's a lot of work to fix the mail before
>> replying)
>
>
> Please don't lecture others. I hate top posting. I'm 54 and hated the rising
> popularity of programs like Outlook which encouraged top posting. Gmail
> makes top posting the default. So unless I'm responding to more than a
> single point in the original message I take the path of least resistance. We
> lost the battle of top versus bottom posting twenty years ago. Move on.

Okay, I will never reply to your mails again.

-- 
Mikael Magnusson

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Thorsten Kampe]

* Kurtis Rader (Thu, 9 Apr 2015 19:59:56 -0700)
> 
> On Thu, Apr 9, 2015 at 7:46 PM, Mikael Magnusson <mikachu@gmail.com> wrote:
> 
> > (please don't top post, it's a lot of work to fix the mail before replying)
> >
> 
> Please don't lecture others. I hate top posting. I'm 54 and hated the
> rising popularity of programs like Outlook which encouraged top posting.
> Gmail makes top posting the default. So unless I'm responding to more than
> a single point in the original message I take the path of least resistance.
> We lost the battle of top versus bottom posting twenty years ago. Move on.

I kind of agree. The bad thing is that top-posting and not snipping 
the parts you are responding to, massively decreases the readibility 
and usefullness of email. 

You just read the first paragraph of an email and ignore all the 
rest. I do it, the person I'm responding to does it. Kind of like a 
lose-lose situation. Of course, the person that seeks help loses 
more.

Thorsten

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Ray Andrews]

On 04/09/2015 11:06 PM, Thorsten Kampe wrote:
>
> (please don't top post, it's a lot of work to fix the mail before replying)
>
>> We lost the battle of top versus bottom posting twenty years ago. Move on.
> I kind of agree. The bad thing is that top-posting and not snipping
> the parts you are responding to, massively decreases the readibility
> and usefullness of email.
>
> You just read the first paragraph of an email and ignore all the
> rest. I do it, the person I'm responding to does it. Kind of like a
> lose-lose situation. Of course, the person that seeks help loses
> more.
My two cents is that each has it's place.  If I'm replying to an email 
in the most 'general'
way--something like "Ok, thanks."--I top post, but if replying to 
specific points, then I
always interleave or bottom post--doing anything else seems strange. 
What I myself
can't stand is the eternally incrementing email that you see more and 
more of.

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Roman Neuhauser]

# rayandrews@eastlink.ca / 2015-04-13 09:52:33 -0700:
> My two cents is that each has it's place.  If I'm replying to an email 
> in the most 'general' way--something like "Ok, thanks."--I top post,

what's the point of sending back the whole thing in such a situation?

-- 
roman

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Ray Andrews]

On 04/13/2015 10:36 AM, Roman Neuhauser wrote:
> # rayandrews@eastlink.ca / 2015-04-13 09:52:33 -0700:
>> My two cents is that each has it's place.  If I'm replying to an email
>> in the most 'general' way--something like "Ok, thanks."--I top post,
> what's the point of sending back the whole thing in such a situation?
>
I never said I'd include the entire previous text, probably only the 
first few lines
for reference.

But Bart will be on our  case for being off topic here ;-)

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Bart Schaefer]

On Apr 13,  4:58pm, Ray Andrews wrote:
}
} But Bart will be on our  case for being off topic here ;-)

Your penance is to write a shell script that Mikael can use to convert
top-posts into bottom-posts.

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Ray Andrews]

On 04/13/2015 06:27 PM, Bart Schaefer wrote:
> On Apr 13,  4:58pm, Ray Andrews wrote:
> }
> } But Bart will be on our  case for being off topic here ;-)
>
> Your penance is to write a shell script that Mikael can use to convert
> top-posts into bottom-posts.
>
The 13th labor of Hercules!

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Thu, Apr 9, 2015 at 7:46 PM, Mikael Magnusson <mikachu@gmail.com> wrote:

> If you mean ambiguity because VAR might be the string "-z" for
> example, there is no such ambiguity. The syntax of [[ ... ]] is fully
> parsed before any substitutions inside are made (I think, but it's at
> least true for this purpose). (This is unlike [ ... ] which is not
> syntax but a shell builtin that gets passed arguments after they're
> substituted, globbed, expanded and etc).
>

Your last statement is only partially true. It is true that most modern
shells implement the single bracket form as a builtin (the double bracket
form has always been a builtin in ksh, zsh, etc.). However, historically
the "[" command was simply an alias (usually a file system hard-link) for
/bin/test. The original Bourne shell simply executed that external command
and checked its exit status. Check your /bin or /usr/bin directory and
you'll likely see a file named "[" (although it may not be a link to
/bin/test these days). The fact the "[" was historically an external
command is why you have to jump through hoops to quote variable expansions
and use tricks like

if [ "${var}x" = x ]; then

so that if $var was unset or the empty string you still had a valid
expression.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?

[Bart Schaefer]

On Apr 10,  3:23am, Thorsten Kampe wrote:
} Subject: `[[ -n $VAR ]]` equal to `[[ $VAR ]]`?
}
} this is kind of a follow-up to 
} http://www.zsh.org/mla/users/2011/msg00284.html .

Note 2011.

} Now my question is, isn't `[[ -n $VAR ]]` equivalent to `[[ $VAR ]]`? 
} (`[[ -n ${VAR+stuff} ]]` equivalent to `[[ ${VAR+stuff} ]]`)

The answer is zsh-version-dependent.

In all releases prior to May 2014, [[ $var ]] was a parse error.  In all
later releases, [[ $var ]] is the same as [[ -n $var ]].  That means
zsh 5.0.6 and later support the bash-equivalent syntax.