Hi I have been in a world of pain playing around with compound control structures e.g. this only works as a single line (is that true?) if (( $1 == 4 )) { echo good } else { echo bad } just wondered where I could read up on this? f(){if (($1==4)){echo ok} else {echo nok} } or joe(){ [[ $1 > 4 ]] && echo big || echo small } or fred(){ if [[ $1 =~ fred ]] { echo ok} else {echo nok} } There seems to be some arbitrariness as to when spaces are required zzapper
Hi David, > e.g. this only works as a single line (is that true?) > if (( $1 == 4 )) { echo good } else { echo bad } i'm not sure what a "single line" is. the "else" keyword should not appear at the very begin of an expression but all the rest is ok. meaning those are correct if (( $1 == 4 )) { echo good } else { echo bad } if (( $1 == 4 )) { echo good } else { echo bad } this is not if (( $1 == 4 )) { echo good } else { echo bad } > just wondered where I could read up on this? all the following examples works fine there. i'm even surprised about this one > joe(){ [[ $1 > 4 ]] && echo big || echo small } this is a math expression so i would have written joe(){ (( $1 > 4 )) && echo big || echo small } regards marc
On Tue, Apr 20, 2021, at 11:19 AM, Marc Chantreux wrote:
> all the following examples works fine there. i'm even surprised about
> this one
>
> > joe(){ [[ $1 > 4 ]] && echo big || echo small }
>
> this is a math expression so i would have written
>
> joe(){ (( $1 > 4 )) && echo big || echo small }
You'd be right because the original version is wrong (unless OP
*wants* lexicographic comparison and just didn't say so).
% joe(){ [[ $1 > 4 ]] && echo big || echo small }
% joe 5
big
% joe 10
small
--
vq
> You'd be right because the original version is wrong (unless OP
> *wants* lexicographic comparison and just didn't say so).
> % joe(){ [[ $1 > 4 ]] && echo big || echo small }
ohh ... indeed :)
thanks
marc
On Tue, Apr 20, 2021, at 10:40 AM, david wrote:
> Hi
>
> I have been in a world of pain playing around with compound control
> structures
>
> e.g. this only works as a single line (is that true?)
>
> if (( $1 == 4 )) { echo good } else { echo bad }
>
> just wondered where I could read up on this?
The zshmisc(1) man page, section "ALTERNATE FORMS FOR COMPLEX
COMMANDS". It assumes familiarity with lists, so probably also
look at "SIMPLE COMMANDS & PIPELINES".
--
vq
On 20/04/2021 16:19, Marc Chantreux wrote:
>
> not appear at the very begin of an expression but all the rest is ok.
>
> meaning those are correct
>
> if (( $1 == 4 )) { echo good } else { echo bad }
>
> if (( $1 == 4 )) {
> echo good
> } else {
> echo bad
> }
>
> this is not
>
> if (( $1 == 4 )) {
> echo good
> }
> else {
> echo bad
> }
This is very helpful & clarifies. I 'd forgotten that shells are more
strict in their response to 'white space' than programming languages .
While playing golf I've noticed that the 'else' clause is particularly
intolerant it needs '} else {'
[-- Attachment #1: Type: text/plain, Size: 1939 bytes --] On 20/04/2021 16:33, Lawrence Velázquez wrote: > SIMPLE COMMANDS & PIPELINES A /sublist/ is either a single pipeline, or a sequence of two or more pipelines separated by ‘&&’ or ‘||’. If two pipelines are separated by ‘&&’, the second pipeline is executed only if the first succeeds (returns a zero status). If two pipelines are separated by ‘||’, the second is executed only if the first fails (returns a nonzero status). Both operators have equal precedence and are left associative. The value of the sublist is the value of the last pipeline executed. For example, dmesg | grep panic && print yes is a sublist consisting of two pipelines, the second just a simple command which will be executed if and only if the grep command returns a zero status. If it does not, the value of the sublist is that return status, else it is the status returned by the print (almost certainly zero). A /list/ is a sequence of zero or more sublists, in which each sublist is terminated by ‘;’, ‘&’, ‘&|’, ‘&!’, or a newline. This terminator may optionally be omitted from the last sublist in the list when the list appears as a complex command inside ‘(...)’ or ‘{...}’. When a sublist is terminated by ‘;’ or newline, the shell waits for it to finish before executing the next sublist. If a sublist is terminated by a ‘&’, ‘&|’, or ‘&!’, the shell executes the last pipeline in it in the background, and does not wait for it to finish (note the difference from other shells which execute the whole sublist in the background). A backgrounded pipeline returns a status of zero. More generally, a list can be seen as a set of any shell commands whatsoever, including the complex commands below; this is implied wherever the word ‘list’ appears in later descriptions. For example, the commands in a shell function form a special sort of list. lv thanks will digest [-- Attachment #2: Type: text/html, Size: 2929 bytes --]
> While playing golf I've noticed that the 'else' clause is particularly
> intolerant it needs '} else {'
'else' is not the problem: expressions are :) (problem of priority?)
this is ok
if {true} {echo ok} else {echo nope}
those are syntax errors
if{true} {echo ok} else {echo nope}
if {true}{echo ok} else {echo nope}
if {true} {echo ok} else{echo nope}
this does not echoes what you expected :)
if {true} {echo ok}else {echo nope}
regards
marc
On 21/04/2021 11:41, Marc Chantreux wrote:
> this does not echoes what you expected:)
>
> if {true} {echo ok}else {echo nope}
I'd come across this when I was tying myself up in knots it's quite
logical really when you think about it LOL
On Wed, Apr 21, 2021 at 1:46 AM zzapper <zsh@rayninfo.co.uk> wrote:
>
> While playing golf I've noticed that the 'else' clause is particularly
> intolerant it needs '} else {'
Actually it only needs "} else", the next statement can appear on a
new line. In fact the next statement doesn't even have to be enclosed
in braces.
I believe the only case where all three must be on the same line is
} always {
Le Wed, Apr 21, 2021 at 01:32:00PM +0100, zzapper a écrit :
> On 21/04/2021 11:41, Marc Chantreux wrote:
> > this does not echoes what you expected:)
> > if {true} {echo ok}else {echo nope}
> I'd come across this when I was tying myself up in knots it's quite logical
> really when you think about it LOL
i don't think so :) i guess this behavior isn't intentional at the
begining but stay there because of retrocompatibility.
regards
Le Wed, Apr 21, 2021 at 01:32:00PM +0100, zzapper a écrit :
>
> On 21/04/2021 11:41, Marc Chantreux wrote:
> > this does not echoes what you expected:)
> > if {true} {echo ok}else {echo nope}
> I'd come across this when I was tying myself up in knots it's quite logical
> really when you think about it LOL
i don't think so. i guess it is unintentional but kept that way for
compatibility reasons?
regards
marc