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