alias hygiene

alias hygiene

[Ray Andrews]

     [ some test ] && alias _grep="egrep --color=always  "$string""
                             || alias _grep="egrep --color=always 
"^|$1|$string""

... the alias will end up downstream from a pipe which is why there's no 
filespec.

Is that sort of thing sanitary?  It seems to work and it's simpler than 
making a function call but it makes me feel queasy. I'd like to use one 
line after cobbling together the argument string based on the test, but 
"^|$1|$string"   is only understandable to egrep so we can't pre-digest 
it.  It seems I need the two lines.   I'm leery of some gotcha, but it 
seems ok so far.

Re: alias hygiene

[Daniel Shahaf]

Ray Andrews wrote on Wed, 14 Feb 2018 08:09 -0800:
> 
>      [ some test ] && alias _grep="egrep --color=always  "$string""
>                              || alias _grep="egrep --color=always "^|$1|$string""
> 
> ... the alias will end up downstream from a pipe which is why there's no 
> filespec.
> 
> Is that sort of thing sanitary?

I don't understand your question, but allow me to review this code _without_
knowing its context or purpose:

0. It's a syntax error.

1. Calling the alias «_grep» clashes with compsys's function of that name.

2. Aliases don't have positional parameters.  That «$1» is syntactically valid
but I am not sure whether it does what you want (or, rather, whether it would
do what you want after you fix #4).

3. Do not interpolate strings into command strings; that's a bobby tables bug.

4. Those pipe characters are not quoted so they create a pipeline, which you
did not intend.  It would appear that you have not tested that codepath.

More information:

0. «||» is invalid at the start of a logical line.  Either there is an error
message you did not tell us about or there is a difference between what you ran
and what you posted.

1. That matters because aliases and functions are both invoked by entering their
name in command position.  It's possible this doesn't have any effect (depends
on how you autoload compinit) but it's still a bug.

2. «$1» would be fine in specific circumstances, but it's usually a mistake.  If
that code is in zshrc toplevel then the use of «$1» is definitely a mistake.

3. «alias foo='egrep --color=always -- ${(q)string}'» would be better (although
I do not vouch that that --color=always switch is correct in the wider context).
In other contexts arrays can be used (but not here).

4. The command string «print -lr "foo "bar baz" qux"» has four words: «print», «-lr»,
«foo bar», and «baz qux».

Re: alias hygiene

[Ray Andrews]

On 16/02/18 04:30 PM, Daniel Shahaf wrote:
>
> I don't understand your question, but allow me to review this code _without_
> knowing its context or purpose:
Thanks Daniel, I did suspect it would not be kosher.  Is there some way 
to see how this looks to the parser after expansion?  That way I'd 
probably be able to understand the issue better.
>
> 0. It's a syntax error.
>
> 1. Calling the alias «_grep» clashes with compsys's function of that name.
Ah!  So I could  just rename it as far as that goes?  It does seem to 
work fine, but this sounds like a gotcha.
>
> 2. Aliases don't have positional parameters.  That «$1» is syntactically valid
> but I am not sure whether it does what you want (or, rather, whether it would
> do what you want after you fix #4).
Actually that's the reason for the alias, I want it to pick up the 
parameters inline after the alias is expanded.   It does what I want but 
I question its safety.  In practical terms the 
"^|$string|$second_string"   construction is not something I want to try 
passing to a function so I thought to just leave it there for the 
expanded alias to eat, that is, for egrep to eat.  So I guess I'm being 
a bit chicken not using a function.
>
> 3. Do not interpolate strings into command strings; that's a bobby tables bug.
This is what I had expected the issue would be.  Mind, I cobble strings 
together into command strings all the time and I've gotten used to the 
little tweaks needed.  How can I read up on this 'bobby tables'?  I 
might have developed some bad habits.
>
> 4. Those pipe characters are not quoted so they create a pipeline, which you
> did not intend.  It would appear that you have not tested that codepath.

I suspect the context would show that all right, I do end up with my 
pipes working ok.  It's rather convoluted, sorry if the snip was not 
satisfactory, I was essentially worried about the conditional alias 
being a good idea from the getgo, not about the subsequent details which 
are not complete.  I don't think I've ever seen a conditional alias before.

>
> More information:
>
> 0. «||» is invalid at the start of a logical line.  Either there is an error
> message you did not tell us about or there is a difference between what you ran
> and what you posted.

Right, context again, I should only show what is strictly relevant to 
the question.
>
> 1. That matters because aliases and functions are both invoked by entering their
> name in command position.  It's possible this doesn't have any effect (depends
> on how you autoload compinit) but it's still a bug.
>
> 2. «$1» would be fine in specific circumstances, but it's usually a mistake.  If
> that code is in zshrc toplevel then the use of «$1» is definitely a mistake.
>
> 3. «alias foo='egrep --color=always -- ${(q)string}'» would be better (although
> I do not vouch that that --color=always switch is correct in the wider context).
> In other contexts arrays can be used (but not here).

Thanks, I forget about ' (q) '.
>
> 4. The command string «print -lr "foo "bar baz" qux"» has four words: «print», «-lr»,
> «foo bar», and «baz qux».
>

Re: alias hygiene

[Daniel Shahaf]

Ray Andrews wrote on Fri, 16 Feb 2018 19:14 -0800:
> On 16/02/18 04:30 PM, Daniel Shahaf wrote:
> >
> > I don't understand your question, but allow me to review this code _without_
> > knowing its context or purpose:
> Thanks Daniel, I did suspect it would not be kosher.  Is there some way 
> to see how this looks to the parser after expansion?  That way I'd 
> probably be able to understand the issue better.

You could use a widget such as:

[[[
f() {
  local arg
  for arg in ${(z)1}; do
    print -r -l -- «${(Q)arg}»
  done
}
show-buffer-parse() {
  zle -M "$(f "$PREBUFFER$LBUFFER")"
}
zle -N show-buffer-parse
bindkey '^T' show-buffer-parse
]]]

There may be plugins that could help, too.

> >
> > 0. It's a syntax error.
> >
> > 1. Calling the alias «_grep» clashes with compsys's function of that name.
> Ah!  So I could  just rename it as far as that goes?  It does seem to 
> work fine, but this sounds like a gotcha.

Yes, just rename it.

> > 2. Aliases don't have positional parameters.  That «$1» is syntactically valid
> > but I am not sure whether it does what you want (or, rather, whether it would
> > do what you want after you fix #4).
> Actually that's the reason for the alias, I want it to pick up the 
> parameters inline after the alias is expanded.

That does not require using $1:

    % alias x='echo foo'
    % x qux

However, note also:

    % alias x='echo foo; echo bar'
    % x qux

If you wanted that to print «foo qux», you would have had to use a function.

The use of $1 in your excerpt is a latent bug.

> It does what I want but 
> I question its safety.  In practical terms the 
> "^|$string|$second_string"   construction is not something I want to try 
> passing to a function

You really, really have to learn quoting and escaping.  There is no problem at
all with strings that contain variable substitutions and shell and extendedglob
metacharacters, provided that they are quoted.

I refer you again to the second point #4 in my previous email.  Without running
that command, what do you expect it to output?  Now run it.  Do you understand
why it behaved as it did?

> so I thought to just leave it there for the 
> expanded alias to eat, that is, for egrep to eat.

That pipe is not quoted, hence it is syntactical.  Alias definitions are simple
command so they end at a command separator — which includes «;» and «&&» and
«|», among others.

> >
> > 3. Do not interpolate strings into command strings; that's a bobby tables bug.
> This is what I had expected the issue would be.  Mind, I cobble strings 
> together into command strings all the time and I've gotten used to the 
> little tweaks needed.  How can I read up on this 'bobby tables'?  I 
> might have developed some bad habits.

You might do a web search for that term.

> > More information:
> >
> > 0. «||» is invalid at the start of a logical line.  Either there is an error
> > message you did not tell us about or there is a difference between what you ran
> > and what you posted.
> 
> Right, context again, I should only show what is strictly relevant to 
> the question.

I was trying to point out that your report was either incomplete or inaccurate,
not that it had excessive detail.

Re: alias hygiene

[Ray Andrews]

On 17/02/18 05:54 AM, Daniel Shahaf wrote:


Thanks.  There's a lot of homework in your post, I'll get on it. For now 
I take it that one can legitimately have an alias definition conditional 
on some test, at least in theory, however much the alias itself could 
stand improvement.  The hidden danger of course is that one might do 
something that seems to work at the time but that is fundamentally 
flawed and liable to blow up later.

Re: alias hygiene

[Daniel Shahaf]

Ray Andrews wrote on Sat, 17 Feb 2018 07:20 -0800:
> Thanks.  There's a lot of homework in your post, I'll get on it. For now 
> I take it that one can legitimately have an alias definition conditional 
> on some test, at least in theory,

Yes.  Example:

case $OSNAME in
  (linux*) alias ls='ls --color';;
  (freebsd*) alias ls='ls -G';;
esac

> however much the alias itself could 
> stand improvement.  The hidden danger of course is that one might do 
> something that seems to work at the time but that is fundamentally 
> flawed and liable to blow up later.

Yes.

Re: alias hygiene

[Ray Andrews]

On 17/02/18 07:30 AM, Daniel Shahaf wrote:
> Ray Andrews wrote on Sat, 17 Feb 2018 07:20 -0800:
>> Thanks.  There's a lot of homework in your post, I'll get on it. For now
>> I take it that one can legitimately have an alias definition conditional
>> on some test, at least in theory,
> Yes.  Example:
Ok, that at least is good to know.  Now I have to figure out from your 
example what a widget is, I've heard the term but so far I have no clue 
what sort of critter they might be.

Re: alias hygiene

[Bart Schaefer]

On Sat, Feb 17, 2018 at 7:42 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Ok, that at least is good to know.  Now I have to figure out from your
> example what a widget is, I've heard the term but so far I have no clue what
> sort of critter they might be.

A "widget" is just an arbitrary thing that you've built.  It's like
using the word "foo" as a placeholder for an abstract value.  As far
back as I remember, a "widget" was used in economics to refer to an
unspecified object, such as a consumer good or a machine part, that
was manufactured by a hypothetical factory or sold by a hypothetical
wholesaler or retailer, but you can probably find earlier meanings
with an etymology search.  When windowing UIs became a thing back in
the 80s it got retconned into a portmanteau of "window gadget" and
used to describe components of the desktop.  Zsh borrowed the term to
refer to the chunk of programming, whether C or shell function, that
implements a named and therefore bindable operation in the ZLE editor.

Re: alias hygiene

[Ray Andrews]

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

On 17/02/18 02:04 PM, Bart Schaefer wrote:
> On Sat, Feb 17, 2018 at 7:42 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Ok, that at least is good to know.  Now I have to figure out from your
>> example what a widget is, I've heard the term but so far I have no clue what
>> sort of critter they might be.
> A "widget" is just an arbitrary thing that you've built.  It's like
> using the word "foo" as a placeholder for an abstract value.  As far
> back as I remember, a "widget" was used in economics to refer to an
> unspecified object, such as a consumer good or a machine part, that
> was manufactured by a hypothetical factory or sold by a hypothetical
> wholesaler or retailer, but you can probably find earlier meanings
> with an etymology search.  When windowing UIs became a thing back in
> the 80s it got retconned into a portmanteau of "window gadget" and
> used to describe components of the desktop.  Zsh borrowed the term to
> refer to the chunk of programming, whether C or shell function, that
> implements a named and therefore bindable operation in the ZLE editor.
>
That doesn't sound too terrible, not some actualnew construction? So a 
function can be a widget? Show me one that I can understand and then 
I'll stop imagining that it's some new horror.  When would I call 
something a widget, not a function? When it's associated with ZLE?  
Yeah, that sounds about right.

Re: alias hygiene

[Bart Schaefer]

On Feb 17,  4:17pm, Ray Andrews wrote:
}
} That doesn't sound too terrible, not some actualnew construction? So a 
} function can be a widget?

Sort of.  A function can be one component of a widget.  The other parts
of a widget are the bit of zsh internals that explains how it works in
ZLE, and the name used to refer to the whole composite.  A "user-defined"
widget has a shell function, those internals, and a name.  A "builtin"
widget has C code, internals, and a name.

} Show me one that I can understand

Daniel tried to do so a few messages ago, in users/23134.  You create a
widget with either "zle -N" (which sets up the internals for a "normal"
widget and attaches the name) or "zle -C" (which sets up internals for
completion and names it).

Once you have one of those objects you can use its name in "bindkey".

} When would I call 
} something a widget, not a function? When it's associated with ZLE?

Approximately, yes.  Most of the time it's convenient if the widget and
the function that implements it have the same name, but that's not a
requirement; for example, many function that implement searches or line
motions can handle going both forward and backward, so there will be
two widget names but only one function.

Re: alias hygiene

[Ray Andrews]

On 17/02/18 06:10 PM, Bart Schaefer wrote:
> } Show me one that I can understand
>
> Daniel tried to do so a few messages ago, in users/23134.
Yeah, I'll chew on that anyway, but I thought it might be ad hoc, so I'm 
angling for
something actually in play so I can see how it works by fiddling with 
it.  As I always
say, if it ain't broke, break it, then you find out how it works ;-)
> You create a
> widget with either "zle -N" (which sets up the internals for a "normal"
> widget and attaches the name) or "zle -C" (which sets up internals for
> completion and names it).
Ok, that's what I wasn't getting with Daniel's example.  So these things 
really are a unique functionality, I'd not be calling some function I 
wrote a widget 'cuz I think its cute.  Thanks Bart, that gives me an 
honest start.

Re: alias hygiene

[Bart Schaefer]

On Feb 17,  7:38pm, Ray Andrews wrote:
}
} I'm angling for
} something actually in play so I can see how it works by fiddling with 
} it.

Most of the functions in Functions/Zle are intended to implement ZLE
widgets.  Unfortunately most of them are also implementing complex
operations, so the widget details get lost in the woods.

Try looking at Functions/Zle/move-line-in-buffer for probably the
simplest example.

Re: alias hygiene

[Vincent Lefevre]

On 2018-02-17 15:30:45 +0000, Daniel Shahaf wrote:
> Ray Andrews wrote on Sat, 17 Feb 2018 07:20 -0800:
> > Thanks.  There's a lot of homework in your post, I'll get on it. For now 
> > I take it that one can legitimately have an alias definition conditional 
> > on some test, at least in theory,
> 
> Yes.  Example:
> 
> case $OSNAME in
>   (linux*) alias ls='ls --color';;
>   (freebsd*) alias ls='ls -G';;
> esac

And I even have an alias generator that can redefine existing aliases:

use-pager()
{
  local -a cmd
  cmd=(pager-wrapper)
  while [[ $1 == -* ]]
  do
    cmd+=${(q)1}
    shift
  done
  local i
  for i in $@
  do
    whence $i > /dev/null &&
      alias $i="$cmd ${(Q)"${$(alias $i)#*=}":-$i}"
  done
}

I hope that's correct.

The goal is to alias commands to use a pager when possible
(the pager-wrapper function uses a pager only when the output
is sent to a terminal).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: alias hygiene

[Ray Andrews]

On 27/02/18 05:48 AM, Vincent Lefevre wrote:
> And I even have an alias generator that can redefine existing aliases: 
...
> The goal is to alias commands to use a pager when possible
> (the pager-wrapper function uses a pager only when the output
> is sent to a terminal).
>
It's a cool way of reshaping a command to fit some real time 
circumstance, this gives one a bunch of interesting options that can 
only be available to interpreted code.   It's the sort of thing one 
can't find in the scrolls.

Re: alias hygiene

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, 17 Feb 2018 13:54 +0000:
> However, note also:
> 
>     % alias x='echo foo; echo bar'
>     % x qux

By the way, this alias definition isn't quite good either; it would be
better with braces or as a function, to avoid unexpected parsing.  This
is similar to the need for «do { ... } while (0)» loops in C statement macros.

Re: alias hygiene

[Bart Schaefer]

On Fri, Feb 16, 2018 at 7:14 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> How can I read up on this 'bobby tables'?

https://xkcd.com/327/
https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables

Re: alias hygiene

[Ray Andrews]

On 17/02/18 01:40 PM, Bart Schaefer wrote:
> On Fri, Feb 16, 2018 at 7:14 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> How can I read up on this 'bobby tables'?
> https://xkcd.com/327/
> https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables
>
Ha. Well heck, there could have really been bobby tables for all I 
know.  We have hash tables after all.  Good news tho, that's one less 
huge chasm in my knowledge.  I won't get off so lightly with widgets, 
they are real.

Re: alias hygiene

[Bart Schaefer]

To add a few remarks here ...

On Feb 17, 12:30am, Daniel Shahaf wrote:
} Subject: Re: alias hygiene
}
} Ray Andrews wrote on Wed, 14 Feb 2018 08:09 -0800:
} > 
} >      [ some test ] && alias _grep="egrep --color=always  "$string""
} >                              || alias _grep="egrep --color=always "^|$1|$string""
} 
} I don't understand your question

The way the quoting is arranged here is funny.  If we look at the first
line only, the quotes are such that $string must have a value at the
time the alias is defined (rather than when it is used) and there is a
useless empty quote pair at the end of the line.  Although it may seem
you can nest double quotes when using $(...) or some ${...} syntax --
	echo "Outer and $(echo "inner also") quotes"
-- the presence of the $(...) is important.  In the absence of any of
the balanced-parens or balanced-braces inside, quotes do not nest.

} 1. Calling the alias "_grep" clashes with compsys's function of that name.

This isn't really important; the completion system disables aliases, and
it would not make sense to use the _grep function outside completion, so
in practice there's no conflict.

} 2. Aliases don't have positional parameters.

True (and different from csh aliases which can make history references
to simulate positionals) but ever since the introduction of argument
processing in anonymous functions it has been possible to write

    alias _grep='() { egrep --color=always "^|$1|$string" }'

There are a few reasons (e.g., the previously mentioned clash with a
completion function) why one might prefer this over defining a named
function, and a few other reasons why one might avoid it (see below).

To be pedantic, in the above example

    _grep foo

woould expand to

    () { egrep --color=always "^|$1|$string" } foo

which would pass "foo" to the anonymous sub as "$1".

} 3. Do not interpolate strings into command strings; that's a bobby
} tables bug.

I think this was unintentional, and that instead there's confusion about
the nesting of the quotes.  I think Ray meant to write

    alias _grep='egrep --color=always  "$string"'

(although in that case I'm not sure where $string comes from).

} 4. Those pipe characters are not quoted so they create a pipeline

Another likely case of incorrect quote nesting.

} More information:
} 
} 0. "||" is invalid at the start of a logical line.

Most likely line wrap added in a syntactically invalid place.  (Aside:
The discussion that led up to the ability to make aliases for command
separators was spawned by a desire to be able to put "||" at the start
of a logical line.)

} 1. ... (depends on how you autoload compinit)

No.  Even if compinit is loaded with aliases enabled, there's no explicit
reference to any of the _* functions to cause confusion with the alias,
and aliasing is turned off during _main_complete.  You'd have to jump
through hoops to deliberately break it.

====

One other remark about aliases with anonymous functions:  It's dangerous
to do this with global aliases.  Example:

    alias -g BODY='() { echo I am a function body }'
    echo this is a BODY

will (with default setopts) create four functions (echo, this, is, a)
all with the same definition -- and that "echo" function calls itself.

Re: alias hygiene

[Ray Andrews]

On 18/02/18 10:28 PM, Bart Schaefer wrote:
> To add a few remarks here ...
There's meat here even though the bone itself was not really cooked, I 
was just interested in the elementary question of a conditional alias, 
the rest of it was so raw as to not even reflect my own level of knowledge.

> If we look at the first
> line only, the quotes are such that $string must have a value at the
> time the alias is defined (rather than when it is used)
Right, I do understand that, the whole point of the alias was to capture 
some values at the time of definition and others at the time of 
execution.  I've since moved on to a function and it's much more 
robust.  As I said, I was just chicken about passing: "^|$1|^$string"   
... to a function, I was sure it would ruin my life as the parser tried 
to eat it.   I've gotten over that.  Big boys don't cry.
>   and there is a
> useless empty quote pair at the end of the line.

Useless he says!  Sheesh, half my problems are not having enough quotes, 
so I tend to try to solve every problem by throwing more quotes at 
things ;-)  *then*, once it works, I see how many I can pull out.
> Although it may seem
> you can nest double quotes when using $(...) or some ${...} syntax --
> 	echo "Outer and $(echo "inner also") quotes"
> -- the presence of the $(...) is important.  In the absence of any of
> the balanced-parens or balanced-braces inside, quotes do not nest.
You can see how that's logical,  $() must have quotes within as 
unaffected by quotes without.  I can't explain it, but I know it's 
true.  Still it's the sort of thing one tattoos on one's arm: quotes do 
not nest.
>
> } 1. Calling the alias "_grep" clashes with compsys's function of that name.
>
> This isn't really important; the completion system disables aliases, and
> it would not make sense to use the _grep function outside completion, so
> in practice there's no conflict.
It was actually   "  _ggrep   "  so no issue anyway.   I like to 
deliberately misspell any identifier that might be confused with a 
normal word or some other standard identifier.

>
>      alias _grep='() { egrep --color=always "^|$1|$string" }'
That is a revelation, we can have our cake and eat it too!
>
>
>      () { egrep --color=always "^|$1|$string" } foo
>
> which would pass "foo" to the anonymous sub as "$1".
Right, it's even intuitive.  Bloody marvellous.
>
>
> } 4. Those pipe characters are not quoted so they create a pipeline
>
> Another likely case of incorrect quote nesting.
Yeah, I got all that sorted out.  Sorry again for the half-cooked snip.
>
> } More information:
> }
> } 0. "||" is invalid at the start of a logical line.
>
> Most likely line wrap added in a syntactically invalid place.  (Aside:
> The discussion that led up to the ability to make aliases for command
> separators was spawned by a desire to be able to put "||" at the start
> of a logical line.)
I remember querying that some time ago.  IIRC there were subtly 
different rules for " && " and " || " anyway no matter, line 
continuation solves all issues.
> One other remark about aliases with anonymous functions:  It's dangerous
> to do this with global aliases.  Example:
>
>      alias -g BODY='() { echo I am a function body }'
>      echo this is a BODY
>
> will (with default setopts) create four functions (echo, this, is, a)
> all with the same definition -- and that "echo" function calls itself.
>
Holy Cow.  Best to avoid the deeper magic.