anonymous function question

anonymous function question

[Jim]

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

Hi everyone,

I normally have interactive_comments set, but while doing some testing it
got unset.
So now comments within an anonymous functions typed in at the command line,
or
called back from history, outputs different errors depending on what is
commented.
Example:
% ()
function> {
function> #echo interactivecomments test
function> }
Outputs:  (anon):2: bad pattern: #echo

Adding 'setopt interactive_comments' before the echo command within the
anonymous
function has no effect.

Only setting interactive_comments external to the anonymous function stops
an error
from occuring.

This seems to be different then what is expected in a non-anonymous
function. May
have missed something, but do not see anything in the manual indicating
this is the
case. If so sorry for the noise.

QUESTIONS:
Is this normal for an anonymous function?
Why doesn't setting interactive_comments within an anonymous function work?

Thanks, and best regards,

Jim Murphy

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

Re: anonymous function question

[Lawrence Velázquez]

On Mon, Aug 22, 2022, at 10:11 PM, Jim wrote:
> Is this 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.

	% unsetopt INTERACTIVE_COMMENTS
	% foo() {
	function> setopt INTERACTIVE_COMMENTS
	function> #echo test
	function> }
	% foo
	foo:2: command not found: #echo

	% unsetopt INTERACTIVE_COMMENTS
	% (
	subsh> setopt INTERACTIVE_COMMENTS
	subsh> #echo test
	subsh> )
	zsh: command not found: #echo

	% unsetopt INTERACTIVE_COMMENTS               
	% if :; then
	then> setopt INTERACTIVE_COMMENTS
	then> #echo test
	then> fi
	zsh: command not found: #echo


> Why doesn't setting interactive_comments within an anonymous function work?

Someone please correct me if I'm mistaken, but I believe that:

- 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:

	% unsetopt INTERACTIVE_COMMENTS
	% {
	cursh> setopt INTERACTIVE_COMMENTS
	cursh> #echo test
	cursh> }
	zsh: command not found: #echo
	% #echo test
	%

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

-- 
vq

Re: anonymous function question

[Jim]

[-- 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 --]

Re: anonymous function question

[Roman Perepelitsa]

On Tue, Aug 23, 2022 at 5:37 AM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> - 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:

That's basically correct. Note that *all* options stay constant during
parsing, not just INTERACTIVE_COMMENTS. Also note that functions are
always parsed in their entirety and only once and aliases are expanded
during parsing. This often surprises people. Consider this script:

    alias foo='echo 1'

    function bar() {
      foo
      alias foo='echo 2'
    }

    bar
    bar
    bar
    foo

This script prints "1" three times followed by "2". If you add
`functions bar` at the bottom to print the body of function bar, it'll
reveal what's going on:

    bar () {
      echo 1
      alias foo='echo 2'
    }

As you can see, the alias within the function has been expanded during parsing.

There are several more options (in addition to INTERACTIVE_COMMENTS
and ALIASES) that affect parsing: SH_GLOB, BRACE_EXPAND, etc.

    # Set unusual options.
    setopt no_brace_expand

    function foo() {
      # Set the usual options.
      emulate -L zsh
      print -- {1,2}
    }

    foo

This prints "{1,2}" rather than "1 2". Options set by a function
affect its execution but not parsing.

Another thing that can be surprising is that zcompile parses the whole
file all at once with the options and aliases that are active at the
time zcompile is invoked. This means that sourcing a file directly may
have a different effect from zcompiling and sourcing it afterwards.

    >script.zsh <<\END
    alias echo='echo 1'
    echo 2
    END

    ( source ./script.zsh )
    zcompile ./script.zsh
    ( source ./script.zsh )

This prints "1 2" followed by "2".

This is one of the reasons I wouldn't recommend zcompiling zsh startup
files. There are other (and more important) reasons, too.


Roman.