zsh-users
 help / color / mirror / code / Atom feed
From: Jim <linux.tech.guy@gmail.com>
To: "Lawrence Velázquez" <larryv@zsh.org>, zsh <zsh-users@zsh.org>
Subject: Re: anonymous function question
Date: Mon, 22 Aug 2022 23:54:07 -0500	[thread overview]
Message-ID: <CA+rB6GKT0DrMK_evTyr5gcVRrKX2nVbRWb-x71i0VrbS3+cmNg@mail.gmail.com> (raw)
In-Reply-To: <4f73130d-1d7b-46af-ab04-72a04fc89727@www.fastmail.com>

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

On Mon, Aug 22, 2022 at 10:36 PM Lawrence Velázquez <larryv@zsh.org> wrote:

> On Mon, Aug 22, 2022, at 10:11 PM, Jim wrote:
> is normal for an anonymous function?
>
> This is not just about anonymous functions.  You can observe the
> same behavior with regular functions and other complex commands.
>
>
Lawrence,

Thanks for responding.

Guess this is what I get for always having interactive_comments set
while in interactive mode. Just assumed it was the way it should work.
You know what they say about assuming. DON'T!

- Comment removal is performed during parsing.  Thus, setting and
>   unsetting INTERACTIVE_COMMENTS changes how parsing is done.
> - A complex command is parsed *in its entirety* before *any* of its
>   commands are executed.  Thus, a command within a complex command
>   cannot affect how the rest of the complex command is parsed.
>
> Therefore, a complex command cannot enable or disable comments
> within itself.  It can affect subsequent commands, though:
>

Need to let this sink in a bit.  Having a problem with how 'parsing' takes
place with interactive/complex commands. If this is the case, it is what
it is then.

I don't know whether any of this is explicitly described in the
> documentation.
>

I did find this. Missed it on previous searches do to the hyphenation.

COMMENTS
       In  non-interactive  shells, or in interactive shells with the
INTERAC‐
       TIVE_COMMENTS option set, a word beginning with the third character
 of
       the  histchars  parameter (`#' by default) causes that word and all
the
       following characters up to a newline to be ignored.

Blanket statement for sure. Doesn't get into any detail.

Regards,

Jim

[-- Attachment #2: Type: text/html, Size: 2750 bytes --]

  reply	other threads:[~2022-08-23  4:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-23  2:11 Jim
2022-08-23  3:36 ` Lawrence Velázquez
2022-08-23  4:54   ` Jim [this message]
2022-08-23  7:21   ` Roman Perepelitsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+rB6GKT0DrMK_evTyr5gcVRrKX2nVbRWb-x71i0VrbS3+cmNg@mail.gmail.com \
    --to=linux.tech.guy@gmail.com \
    --cc=larryv@zsh.org \
    --cc=linuxtechguy@gmail.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).