From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id FAA09260 for ; Wed, 3 Jul 1996 05:16:10 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id PAA01191; Tue, 2 Jul 1996 15:08:35 -0400 (EDT) Resent-Date: Tue, 2 Jul 1996 15:08:35 -0400 (EDT) From: "Bart Schaefer" Message-Id: <960702120736.ZM4601@candle.brasslantern.com> Date: Tue, 2 Jul 1996 12:07:32 -0700 In-Reply-To: Anthony Heading "Tag functions with shell options?" (Jul 2, 1:05pm) References: <199607021205.NAA18450@gmp-etpres1.uk.jpmorgan.com> <199607021537.RAA16181@hydra.ifh.de> <12475.199607021517@stone.dcs.warwick.ac.uk> <199607021658.RAA22275@gmp-etpres1.uk.jpmorgan.com> In-Reply-To: Peter Stephenson "Re: Tag functions with shell options?" (Jul 2, 5:37pm) In-Reply-To: Zefram "Re: Tag functions with shell options?" (Jul 2, 4:17pm) In-Reply-To: Anthony Heading "Re: Tag functions with shell options?" (Jul 2, 5:57pm) Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.607 07jun96) To: Anthony Heading , Peter Stephenson , Zefram , zsh-workers@math.gatech.edu Subject: Re: Tag functions with shell options? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"3LdVq2.0.XI.oENsn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1511 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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"