zsh-users
 help / color / mirror / Atom feed
* syntactic trivia
@ 2021-01-02 14:57 Ray Andrews
  2021-01-02 15:30 ` Stephane Chazelas
  2021-01-02 15:32 ` Stephane Chazelas
  0 siblings, 2 replies; 11+ messages in thread
From: Ray Andrews @ 2021-01-02 14:57 UTC (permalink / raw)
  To: Zsh Users

         [ "$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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 14:57 syntactic trivia Ray Andrews
@ 2021-01-02 15:30 ` Stephane Chazelas
  2021-01-02 17:49   ` Ray Andrews
  2021-01-02 15:32 ` Stephane Chazelas
  1 sibling, 1 reply; 11+ messages in thread
From: Stephane Chazelas @ 2021-01-02 15:30 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 14:57 syntactic trivia Ray Andrews
  2021-01-02 15:30 ` Stephane Chazelas
@ 2021-01-02 15:32 ` Stephane Chazelas
  2021-01-02 18:04   ` Ray Andrews
  1 sibling, 1 reply; 11+ messages in thread
From: Stephane Chazelas @ 2021-01-02 15:32 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 15:30 ` Stephane Chazelas
@ 2021-01-02 17:49   ` Ray Andrews
  2021-01-02 18:05     ` Bart Schaefer
  0 siblings, 1 reply; 11+ messages in thread
From: Ray Andrews @ 2021-01-02 17:49 UTC (permalink / raw)
  To: zsh-users

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 15:32 ` Stephane Chazelas
@ 2021-01-02 18:04   ` Ray Andrews
  2021-01-02 19:13     ` Bart Schaefer
  0 siblings, 1 reply; 11+ messages in thread
From: Ray Andrews @ 2021-01-02 18:04 UTC (permalink / raw)
  To: zsh-users

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.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 17:49   ` Ray Andrews
@ 2021-01-02 18:05     ` Bart Schaefer
  2021-01-02 18:23       ` Ray Andrews
  0 siblings, 1 reply; 11+ messages in thread
From: Bart Schaefer @ 2021-01-02 18:05 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 18:05     ` Bart Schaefer
@ 2021-01-02 18:23       ` Ray Andrews
  2021-01-02 18:32         ` Bart Schaefer
  0 siblings, 1 reply; 11+ messages in thread
From: Ray Andrews @ 2021-01-02 18:23 UTC (permalink / raw)
  To: zsh-users

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.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 18:23       ` Ray Andrews
@ 2021-01-02 18:32         ` Bart Schaefer
  0 siblings, 0 replies; 11+ messages in thread
From: Bart Schaefer @ 2021-01-02 18:32 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

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*


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 18:04   ` Ray Andrews
@ 2021-01-02 19:13     ` Bart Schaefer
  2021-01-02 19:40       ` Bart Schaefer
  2021-01-04  5:34       ` Daniel Shahaf
  0 siblings, 2 replies; 11+ messages in thread
From: Bart Schaefer @ 2021-01-02 19:13 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 19:13     ` Bart Schaefer
@ 2021-01-02 19:40       ` Bart Schaefer
  2021-01-04  5:34       ` Daniel Shahaf
  1 sibling, 0 replies; 11+ messages in thread
From: Bart Schaefer @ 2021-01-02 19:40 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: syntactic trivia
  2021-01-02 19:13     ` Bart Schaefer
  2021-01-02 19:40       ` Bart Schaefer
@ 2021-01-04  5:34       ` Daniel Shahaf
  1 sibling, 0 replies; 11+ messages in thread
From: Daniel Shahaf @ 2021-01-04  5:34 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Ray Andrews, Zsh Users

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-01-04  5:35 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-02 14:57 syntactic trivia Ray Andrews
2021-01-02 15:30 ` Stephane Chazelas
2021-01-02 17:49   ` Ray Andrews
2021-01-02 18:05     ` Bart Schaefer
2021-01-02 18:23       ` Ray Andrews
2021-01-02 18:32         ` Bart Schaefer
2021-01-02 15:32 ` Stephane Chazelas
2021-01-02 18:04   ` Ray Andrews
2021-01-02 19:13     ` Bart Schaefer
2021-01-02 19:40       ` Bart Schaefer
2021-01-04  5:34       ` Daniel Shahaf

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git