Seeking feedback word breaks and aliasing of tokens

Seeking feedback word breaks and aliasing of tokens

[Bart Schaefer]

Following a discussion a few weeks ago, a new feature was added to the
"alias" builtin, namely the ability to create aliases for tokens that
are part of the basic pipeline syntax.  The example that led to this
feature was similar to the following:

% alias -g '&&'='; (( $? == 0 )) && '
% && print this is OK
this is OK
% && print and so is this && print also this
and so is this
also this
% 

This feature has already been adopted, with the restrictions (a) that it
applies only to global aliases [-g] and (b) that it is disabled when the
POSIX_ALIASES option is set.

There is an additional effect of this feature, illustrated by:

% alias -g '||'='OR'
% print no||yes
no ORyes
% 

Note that a word break is introduced to the left of the expansion (because
of '||'s original meaning as shell syntax) even though there are no spaces
around the original usage; but no word break occurs to the right of the
expansion.  The proposal is for word breaks on both sides of the expansion
(as is implied by recognition of a separately aliasable word).

This also affects the '{' reserved word, so instead of this:

% alias '{'=echo
% { OK
OK
% {not OK
zsh: command not found: echonot
% 

We would have this:

% {now OK
now OK
% 

(Note that '{' doesn't require "alias -g" because '{' is a reserved word.)

Comments welcome.

Re: Seeking feedback word breaks and aliasing of tokens

[Eric Cook]

It personally looks weird to me on first glance and i wouldn't expect it
to work like that, but i do not oppose the change.

Also, compsys doesn't seem to like it currently:
alias \{=echo
{<tab> # segfaults zsh currently (not sure if someone else brought it up
in the original thread)

Re: Seeking feedback word breaks and aliasing of tokens

[Bart Schaefer]

On Mar 28,  7:58pm, Eric Cook wrote:
}
} It personally looks weird to me on first glance and i wouldn't expect it
} to work like that, but i do not oppose the change.

Sorry, could you clarify which thing looks weird to you?

} Also, compsys doesn't seem to like it currently:
} alias \{=echo
} {<tab> # segfaults zsh currently (not sure if someone else brought it up
} in the original thread)

Again I'm not sure precisely what "it" means, but *without* my patch from
workers/34781, I get this:

torch% alias \{=echo
torch% {<TAB>
zle_tricky.c:668: BUG: 0 <= wb (-3) <= zlemetacs (1) <= we (1) is not true!
Program received signal SIGSEGV, Segmentation fault.
(gdb) where 3
#0  0x080cdb32 in ztrsub (t=0x8b48a35 "", 
    s=0x8b74001 <Address 0x8b74001 out of bounds>)
    at ../../zsh-5.0/Src/utils.c:4491
#1  0x081334ab in docomplete (lst=0)
    at ../../../zsh-5.0/Src/Zle/zle_tricky.c:675
#2  0x081328a9 in completeword (args=0x8171b60)
    at ../../../zsh-5.0/Src/Zle/zle_tricky.c:232
(gdb) up
#1  0x081334ab in docomplete (lst=0)
    at ../../../zsh-5.0/Src/Zle/zle_tricky.c:675
675         if (viinsbegin > ztrsub(zlemetaline + wb, zlemetaline))

*With* 34781, there is no "BUG:" or segmentation fault.  So I think that
is justification enough to commit it, and we can revisit if necessary.

Re: Seeking feedback word breaks and aliasing of tokens

[Bart Schaefer]

> > alias \{=echo
> > {<tab> # segfaults zsh currently (not sure if someone else brought it up
> > in the original thread)

Incidentally, this bug has been present for quite some time, probably for
as long as it has been possible to create an alias for "{".

Re: Seeking feedback word breaks and aliasing of tokens

[Eric Cook]

On 03/29/2015 12:19 AM, Bart Schaefer wrote:
> On Mar 28,  7:58pm, Eric Cook wrote:
> }
> } It personally looks weird to me on first glance and i wouldn't expect it
> } to work like that, but i do not oppose the change.
>
> Sorry, could you clarify which thing looks weird to you?
The additional effect example is what looks weird to me. I was mostly
curious how it would affect completion that relys on $words or $service
since with {-<tab> or {subcommand <tab> there would only be one word on
the line. But i was reminded in IRC that aliases expand before compsys runs.
>
> } Also, compsys doesn't seem to like it currently:
> } alias \{=echo
> } {<tab> # segfaults zsh currently (not sure if someone else brought it up
> } in the original thread)
>
> Again I'm not sure precisely what "it" means, but *without* my patch from
> workers/34781, I get this:
>
> torch% alias \{=echo
> torch% {<TAB>
> zle_tricky.c:668: BUG: 0 <= wb (-3) <= zlemetacs (1) <= we (1) is not true!
> Program received signal SIGSEGV, Segmentation fault.
> (gdb) where 3
> #0  0x080cdb32 in ztrsub (t=0x8b48a35 "", 
>     s=0x8b74001 <Address 0x8b74001 out of bounds>)
>     at ../../zsh-5.0/Src/utils.c:4491
> #1  0x081334ab in docomplete (lst=0)
>     at ../../../zsh-5.0/Src/Zle/zle_tricky.c:675
> #2  0x081328a9 in completeword (args=0x8171b60)
>     at ../../../zsh-5.0/Src/Zle/zle_tricky.c:232
> (gdb) up
> #1  0x081334ab in docomplete (lst=0)
>     at ../../../zsh-5.0/Src/Zle/zle_tricky.c:675
> 675         if (viinsbegin > ztrsub(zlemetaline + wb, zlemetaline))
>
> *With* 34781, there is no "BUG:" or segmentation fault.  So I think that
> is justification enough to commit it, and we can revisit if necessary.
... and that was "it". I tried a build before a commit referencing
workers/34781 was made, ZSH_PATCHLEVEL was zsh-5.0.7-362-gab40656. sorry
about that :D

Re: Seeking feedback word breaks and aliasing of tokens

[Bart Schaefer]

On Mar 29,  1:09pm, Eric Cook wrote:
}
} The additional effect example is what looks weird to me. I was mostly
} curious how it would affect completion that relys on $words or $service
} since with {-<tab> or {subcommand <tab> there would only be one word on
} the line. But i was reminded in IRC that aliases expand before compsys runs.

Yes, the behavior of completion *with* 34781 applied is consistent for
unquoted non-alphanumeric tokens whether or not COMPLETE_ALIASES is set.
That's probably a good thing.

Re: Seeking feedback word breaks and aliasing of tokens

[Oliver Kiddle]

On 27 Mar, Bart wrote:
> "alias" builtin, namely the ability to create aliases for tokens that
> are part of the basic pipeline syntax.

> There is an additional effect of this feature, illustrated by:
> 
> % alias -g '||'='OR'
> % print no||yes
> no ORyes
> % 
> 
> Note that a word break is introduced to the left of the expansion (because
> of '||'s original meaning as shell syntax) even though there are no spaces
> around the original usage; but no word break occurs to the right of the
> expansion.  The proposal is for word breaks on both sides of the expansion
> (as is implied by recognition of a separately aliasable word).

The added word breaks do remove flexibility because you could always
have included them in the alias: alias -g '||'=' OR '

One possible use might be to disable ||, perhaps for a restricted shell
such as with alias -g '||'='\|\|'
in that case you wouldn't want the added spaces.

I'd agree that 34781 made sense in that having the word break on only
one side of the token after alias expansion is not consistent. Was the
preceding word break always there or intentional as part of the recent
changes?

It seems redirections are also covered by this change but this looks
like a bug:
% alias -g '>!'='REDIR'
% echo one>!two
zsh: event not found: two
 prompt.c:1539: BUG: cmdstack empty

You can't alias something like 2>&1 though.

alias -g '&'='&!'
doesn't have the same problem and I could see someone finding that
useful.

Oliver

Re: Seeking feedback word breaks and aliasing of tokens

[Bart Schaefer]

On May 15,  2:41am, Oliver Kiddle wrote:
} Subject: Re: Seeking feedback word breaks and aliasing of tokens
}
} > Note that a word break is introduced to the left of the expansion (because
} > of '||'s original meaning as shell syntax) even though there are no spaces
} > around the original usage; but no word break occurs to the right of the
} > expansion.  The proposal is for word breaks on both sides of the expansion
} > (as is implied by recognition of a separately aliasable word).
} 
} I'd agree that 34781 made sense in that having the word break on only
} one side of the token after alias expansion is not consistent. Was the
} preceding word break always there or intentional as part of the recent
} changes?

It was always there, and nearly impossible to remove without completely
rewriting the parser, as far as I can tell.

} The added word breaks do remove flexibility because you could always
} have included them in the alias: alias -g '||'=' OR '

That introduces a different problem because an alias that explicitly ends
with a space triggers alias expansion on the following word.

} It seems redirections are also covered by this change but this looks
} like a bug:
} % alias -g '>!'='REDIR'
} % echo one>!two
} zsh: event not found: two
}  prompt.c:1539: BUG: cmdstack empty

That has nothing to do with the alias, it's a completely different bug.

schaefer[619] Src/zsh -f
torch% echo one>!two
zsh: event not found: two
../../zsh-5.0/Src/prompt.c:1539: BUG: cmdstack empty

} You can't alias something like 2>&1 though.

Correct, because that's three tokens "2" ">&" "1" and every alias has to
be for a single token.