zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Anthony Heading <aheading@jpmorgan.com>,
	Peter Stephenson <pws@ifh.de>, Zefram <A.Main@dcs.warwick.ac.uk>,
	zsh-workers@math.gatech.edu
Subject: Re: Tag functions with shell options?
Date: Tue, 2 Jul 1996 12:07:32 -0700	[thread overview]
Message-ID: <960702120736.ZM4601@candle.brasslantern.com> (raw)
In-Reply-To: Anthony Heading <aheading@jpmorgan.com> "Tag functions with shell options?" (Jul  2,  1:05pm)
In-Reply-To: Peter Stephenson <pws@ifh.de> "Re: Tag functions with shell options?" (Jul  2,  5:37pm)
In-Reply-To: Zefram <A.Main@dcs.warwick.ac.uk> "Re: Tag functions with shell options?" (Jul  2,  4:17pm)
In-Reply-To: Anthony Heading <aheading@jpmorgan.com> "Re: Tag functions with shell options?" (Jul  2,  5:57pm)

On Jul 2,  5:37pm, Peter Stephenson wrote:
} Subject: Re: Tag functions with shell options?
}
} aheading@jpmorgan.com wrote:
} > So I think I need some way of marking these functions to be interpreted
} > with SH_WORD_SPLIT turned on locally. Or have I missed something simple?
} 
} This is definitely a weak point in compatibility.  Perhaps in a future
} version we do want special ways of doing things like this.  Some time
} ago, people were suggesting having hooks you could call when a
} function was called etc.; that would do the trick too.

I like the hook idea, but I think something simpler would be sufficient
in this case.

On Jul 2,  4:17pm, Zefram wrote:
} You could wrap the Bourne shell functions in zsh functions that do the
} LOCAL_OPTIONS thing.

That's how I'd approach it, and that's mostly what Peter's sws_fn does.
I've been using this trick in my .zshrc for years:

if typeset -f precmd >& /dev/null
then
    let n=1
    while typeset -f x${n}precmd >& /dev/null; do let n++; done
    eval x${n}"`typeset -f precmd`"
    if [[ "$TERM" = screen ]]
    then
        eval "precmd() { title ; x${n}precmd }"
    else
        eval "precmd() { TMOUT=600 ; title ; x${n}precmd }"
    fi
fi

What that does is rename precmd to a new name that doesn't exist, and
then creates a new precmd which sets the title bar and calls the new
name.  Unfortunately, that doesn't work on autoloaded functions, which
is what most of the work in sws_fn is fixing.

What would be nice is if one of the zsh builtins permitted forcing load
of an autoload function without running the function, and if a builtin
permtitted a function's name to be changed without redefining it.

[Back to PWS again:]
} Another problem arises if the functions get defined at arbitrary
} points during execution (err, like the sws_locate function below, in
} fact).  In that case you're basically stuck without at the least a
} smart script to convert all functions defined inside in the
} appropriate manner.

Right; it doesn't seem that Anthony has given us enough context.  Do
the functions get defined and then executed all within /etc/profile,
for example?  Or do they act as wrappers around actual applications,
so they don't run until you execute them "manually"?  (Sounds like the
latter, but ...)

Are you explicitly sourcing the script that defines those functions,
or are they in a startup script that zsh reads automatically?

If you know the names of all the functions that need to be wrapped,
it seems to me that a much simpler implementation of sws_fn is:

    sws_fn () {
	# \\${1} below is in case of multiple calls to `sws_fn foo`
	# for the same 'foo', to be sure an alias isn't referenced.
	eval "SWS_${1} () { setopt localoptions shwordsplit; \\${1} }"
	alias ${1}=SWS_${1}
    }

The only drawback to this is that other functions that may already have
been defined won't see the alias -- but presumably those functions will
themselves be given the sws_fn treatment, so it's moot.

BTW, does it bother anyone else that, for textually-identical definitions
of `foo':

    foo() {
	bar
    }
    alias bar=baz

Is not equivalent to:

    autoload foo
    alias bar=baz

??

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"



  reply	other threads:[~1996-07-02 19:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-07-02 12:05 Anthony Heading
1996-07-02 13:36 ` Zefram
1996-07-02 14:12   ` Anthony Heading
1996-07-02 15:17     ` Zefram
1996-07-02 15:37 ` Peter Stephenson
1996-07-02 16:57   ` Anthony Heading
1996-07-02 19:07     ` Bart Schaefer [this message]
1996-07-02 19:53       ` Anthony Heading
1996-07-02 21:31         ` Bart Schaefer
1996-07-02 22:27           ` Anthony Heading

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=960702120736.ZM4601@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=A.Main@dcs.warwick.ac.uk \
    --cc=aheading@jpmorgan.com \
    --cc=pws@ifh.de \
    --cc=schaefer@nbn.com \
    --cc=zsh-workers@math.gatech.edu \
    /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).