syntactic trivia

syntactic trivia

[Ray Andrews]

         [ "$case" = 'insensitive' ] && dirs=( (#i)$1*(/N) ) \
                                     || dirs=(     $1*(/N) )

Since '(#i)' is a modifier of the globing would not this be more intuitive?:

     dirs=( $1*(/N#i) )

Just to understand it, I'm wondering why case filtering would be 
syntactically different from the other filters.

Speaking of intuition:

     [ true ] && do-this\    # No comments here, please.
              || do-that

I wonder how much trouble allowing that would be.  Probably written in 
stone that it will never happen, still, it's an obvious exception and 
I'd guess it would only take five minutes to code, the parser just 
throws out any comment before throwing out the backslash and the 
newline.  A tiny luxury.

Re: syntactic trivia

[Stephane Chazelas]

2021-01-02 06:57:32 -0800, Ray Andrews:
>         [ "$case" = 'insensitive' ] && dirs=( (#i)$1*(/N) ) \
>                                     || dirs=(     $1*(/N) )
> 
> Since '(#i)' is a modifier of the globing would not this be more intuitive?:
> 
>     dirs=( $1*(/N#i) )
> 
> Just to understand it, I'm wondering why case filtering would be
> syntactically different from the other filters.
[...]

(#i) can be applied to part of a pattern:

[[ $x = ((#i)insenstive)-sensitive ]]

-- 
Stephane

Re: syntactic trivia

[Stephane Chazelas]

2021-01-02 06:57:32 -0800, Ray Andrews:
[...]
>     [ true ] && do-this\    # No comments here, please.
>              || do-that
> 
> I wonder how much trouble allowing that would be.  Probably written in stone
> that it will never happen, still, it's an obvious exception and I'd guess it
> would only take five minutes to code, the parser just throws out any comment
> before throwing out the backslash and the newline.  A tiny luxury.
[...]

You can write it:

true &&
  do-this || # comment
  do-that

\ followed by a space is a quoted space like ' '.

-- 
Stephane

Re: syntactic trivia

[Ray Andrews]

On 2021-01-02 7:30 a.m., Stephane Chazelas wrote:
>
> (#i) can be applied to part of a pattern:
>
> [[ $x = ((#i)insenstive)-sensitive ]]
>
I see.  So whereas the glob modifiers are unique to globbing, '(#i)' and 
friends are more broadly useful.  Thanks that's exactly the answer.  So 
'(#i)' is treating '$1*(/N)' simply as a string and doesn't care where 
it came from.  That's quite clear.

Re: syntactic trivia

[Ray Andrews]

On 2021-01-02 7:32 a.m., Stephane Chazelas wrote:
> You can write it:
> true &&
>    do-this || # comment
>    do-that

Sure, I just prefer the visual cleanness of my way:

     [ true ] && do-this\    # No comments here, please.
              || do-that

... it might have been permissible but it ain't.  I expect things like this really are no longer negotiable.

Re: syntactic trivia

[Bart Schaefer]

On Sat, Jan 2, 2021 at 9:50 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> '(#i)' is treating '$1*(/N)' simply as a string and doesn't care where
> it came from.  That's quite clear.

As usual, that's not quite it.  (#i) et al. are part of the pattern,
just like * and ? and [abc] would be.  Conversely, (/N) and so on
refer to characteristics of any files (or their names) that are found
by scanning a directory with the pattern.

Re: syntactic trivia

[Ray Andrews]

On 2021-01-02 10:05 a.m., Bart Schaefer wrote:
>
> As usual, that's not quite it.
zsh is a woman.  You never quite have her figured out.

>   (#i) et al. are part of the pattern,
> just like * and ? and [abc] would be.  Conversely, (/N) and so on
> refer to characteristics of any files (or their names) that are found
> by scanning a directory with the pattern.
>
So it's '(#i)$1*'  forming a pattern and then this pattern is applied to 
whatever files '(/N)' spits out?  So first we'd get a list of 
directories and then we'd filter it with '(#i)$1*' ?  I'm not clear on 
the point at which we  know we are dealing with a list of files at all.  
That could only be '(/N)' because otherwise '$1*' ... na ... nope ... 
what does the asterisk even mean outside a globbing context?  I don't 
get the parsing at all.

Re: syntactic trivia

[Bart Schaefer]

On Sat, Jan 2, 2021 at 10:23 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> So it's '(#i)$1*'  forming a pattern and then this pattern is applied to
> whatever files '(/N)' spits out?

No, that's exactly backwards.  (/N) is applied to whatever files have
names that match (#i)$1*

Re: syntactic trivia

[Bart Schaefer]

On Sat, Jan 2, 2021 at 10:04 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Sure, I just prefer the visual cleanness of my way:
>
>      [ true ] && do-this\    # No comments here, please.
>               || do-that
>
> ... it might have been permissible but it ain't.  I expect things like this really are no longer negotiable.

There was a lengthy discussion about this a couple of years ago and is
the reason that you can now make global aliases for syntactic tokens.

ubuntu% alias -g '||'=';(( ! $? )) ||'
ubuntu% false
ubuntu% || echo no
no
ubuntu% alias -g '&&'=';(( ! $? )) &&'
ubuntu% true
ubuntu% && echo yes
yes
ubuntu% false
ubuntu% && echo yes
ubuntu% || echo no
no
ubuntu% true && echo yes
yes
ubuntu% || echo no
ubuntu%  false && echo yes || echo no
no
ubuntu% true || echo no && echo yes
yes

This only works because in shell language && and || have equal
precedence, it would not work in a C-like language where && binds more
tightly.  Personally I have always thought that aliasing tokens is
rather cringey, I would rather have done

alias -g AND=';(( ! $? )) &&'
alias -g OR=';(( ! $? )) ||'

test-something
 AND do-this
 OR do-that

Restricting ourselves instead to comment placement ...

I'm not certain why you used "No comments here, please" as the text.
Is that intended to convey some information to me as a reader of your
question?

Assuming not, a more reasonable approach would be to allow line
continuation to appear AFTER a comment, e.g.,

  [[ stuff ]] && do-this  # Why did I do this? \
    || do-that

It's unlikely that any significant amount of existing code has
comments ending with a backslash, but such a change would probably
have to be controlled by an option nonetheless.

Re: syntactic trivia

[Bart Schaefer]

On Sat, Jan 2, 2021 at 11:13 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
>   [[ stuff ]] && do-this  # Why did I do this? \
>     || do-that

Incidentally, you can do that specific example this way:

[[ stuff ]] && do-this && : "Why did I do this?" \
  || do-that

There's no nice way to do the ...|| ... && ... variant, though.

Re: syntactic trivia

[Daniel Shahaf]

Bart Schaefer wrote on Sat, 02 Jan 2021 11:13 -0800:
> Assuming not, a more reasonable approach would be to allow line
> continuation to appear AFTER a comment, e.g.,
> 
>   [[ stuff ]] && do-this  # Why did I do this? \
>     || do-that
> 
> It's unlikely that any significant amount of existing code has
> comments ending with a backslash,

I'd actually expect this to be somewhat common in codebases that
restrict themselves to some fixed column width.  For example,
Subversion (which is written in 80-column C) has these:

tools/examples/svnput.c:39: *  cc svnput.c -o svnput \
tools/examples/svnput.c:40: *  -I/usr/local/include/subversion-1 -I/usr/local/apache2/include \
tools/examples/svnput.c:41: *  -L/usr/local/apache2/lib -L/usr/local/lib \
subversion/include/svn_repos.h:2467: * @defgroup svn_repos_hook_wrappers Hook-sensitive wrappers for libsvn_fs \
subversion/include/svn_repos.h:2949: * @defgroup svn_repos_inspection Data structures and editor things for \
subversion/include/svn_client.h:2357: * @defgroup Status Report interesting information about paths in the \
subversion/libsvn_client/merge.c:12314: *         /         \
subversion/libsvn_client/merge.c:12315: *   -----o     prev. \
subversion/libsvn_client/merge.c:12316: *     YCA \    merges \

The first of these examples is probably the most typical one.  (The
second one is Doxygen directives, which may or may not actually need
explicit line continuation.  The third one is an ASCII art diagram.)

> but such a change would probably have to be controlled by an option
> nonetheless.

I can't say I'm a fan of syntax-changing options, and in this case
there's an easy workaround:

if foo # ...
then bar # ...
else baz # ...
fi

Cheers,

Daniel

P.S.  Ray, please use more specific subject lines.  If you wouldn't
have picked a book called "syntactic trivia" from the shelf at a book
shop, then it's not a good subject line.