zsh-users
 help / color / mirror / code / Atom feed
From: Roman Neuhauser <neuhauser@sigpipe.cz>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: chpwd, precmd hooks have "zsh" in $0
Date: Thu, 12 Aug 2021 06:40:02 +0200	[thread overview]
Message-ID: <YRSmIo0N4vu3zZ4h@isis.sigpipe.cz> (raw)
In-Reply-To: <CAH+w=7bQN-uuaW-hthX0Wi5J1mmsyB4AsWN0JP75vG0z_zwmRw@mail.gmail.com>

# schaefer@brasslantern.com / 2021-08-10 10:31:00 -0700:
> On Tue, Aug 10, 2021 at 4:33 AM Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
> > and is it too late to reverse the course, gut the half-assed implementation
> > with one written using shell functions?
> 
> There's no need to be offensive about it, but yes, it's too late.  The
> implementation actually has all the interfaces it needs to populate
> FUNCTION_ARGZERO properly, it was just never noticed/found necessary
> to do so.

sorry, i didn't think much about the wording, and didn't mean to be offencisve.
if you (someone) can finish it i'll be grateful.
 
> > > I'm not sure what the desired behavior is here.  callhookfunc() could
> > > dummy up a LinkNode any time its lnklst argument is empty, and then
> > > all the hooks would behave in the manner preexec behaves when history
> > > is enabled; or doshfunc() could do the same, in which case every
> > > hook-array function would have its own name in $0; or neither of the
> > > above is appropriate and we should document the current behavior.
> >
> > what are the downsides of (2) for users of the shell?
> 
> Theoretically, a function might prefer to know that it was being
> called as a consequence of being found in a given hook list, vs. being
> called directly.  That might argue for (1).

yes, but there's other ways to let a function know it's being called as
part of a particular hook array.  there's only one reasonable way
of letting a function know the name it was called with.

> >     function a b { ... } > ab.log
> >     precmd_functions=(a)
> >     preexec_functions=(b)
> >
> > calls the function with $0 == "a" in precmd, "b" in preexec,
> > and that their runtime output goes to ab.log.  hooks do neither
> > and TRAPNAL functions only the first. :(
> 
> I'm not sure what "the first" is here?

use the correct name for a function defined with multiple names.
 
> Anyway, having output redirections on function definitions is another
> thing that was added quite late in the long history of the shell --

i know, it was me who asked for it back then.

  Date: Thu, 24 Jul 2014 14:23:31 +0200
  From: Roman Neuhauser <neuhauser@sigpipe.cz>
  To: zsh-users@zsh.org
  Subject: io-redirect in function definitions

> originally, the redirect would have been connected to the "function"
> command itself -- so there may be circumstances where you have to
> write
> 
>   function a b { { ... } > ab.log }
> 
> to be sure of getting what you meant there.  PWS may have more to say about it.

sure, a workaround exists and it's just a pair of braces and
an indentation level away.  my bitching here isn't motivated by
difficulty to achieve the effect with existing means.  i want the
shell to be simpler, conceptually smaller by having one kind of
functions: those that have their name in $0 and which don't forget
redirections defined after their body.

requests for changes "just" for the sake of some principles may be
annoying so i'll add that this conversation exists because i wanted
to use a single function in several hooks and modify its behavior
based on the hook name:

function generic-hook
{
  local hooks=${1}_functions
  work with ${(P)hooks}
}

-- 
roman


  reply	other threads:[~2021-08-12  4:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-09 20:15 Roman Neuhauser
2021-08-09 21:26 ` Bart Schaefer
2021-08-10 11:33   ` Roman Neuhauser
2021-08-10 17:31     ` Bart Schaefer
2021-08-12  4:40       ` Roman Neuhauser [this message]
2021-08-15 21:10         ` Bart Schaefer

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=YRSmIo0N4vu3zZ4h@isis.sigpipe.cz \
    --to=neuhauser@sigpipe.cz \
    --cc=schaefer@brasslantern.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).