From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-26415-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 26725 invoked from network); 24 Jan 2009 17:39:06 -0000
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.2.5
Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88)
  by ns1.primenet.com.au with SMTP; 24 Jan 2009 17:39:06 -0000
Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts)
Received: (qmail 4309 invoked from network); 24 Jan 2009 17:38:59 -0000
Received: from sunsite.dk (130.225.247.90)
  by a.mx.sunsite.dk with SMTP; 24 Jan 2009 17:38:59 -0000
Received: (qmail 14465 invoked by alias); 24 Jan 2009 17:38:53 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 26415
Received: (qmail 14445 invoked from network); 24 Jan 2009 17:38:52 -0000
Received: from bifrost.dotsrc.org (130.225.254.106)
  by sunsite.dk with SMTP; 24 Jan 2009 17:38:52 -0000
Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48])
	by bifrost.dotsrc.org (Postfix) with ESMTP id BF3A380271F0
	for <zsh-workers@sunsite.dk>; Sat, 24 Jan 2009 18:38:45 +0100 (CET)
Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout02-winn.ispmail.ntl.com
          (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP
          id <20090124173844.NFX4080.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>
          for <zsh-workers@sunsite.dk>; Sat, 24 Jan 2009 17:38:44 +0000
Received: from pws-pc ([81.107.42.185]) by aamtaout01-winn.ispmail.ntl.com
          (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP
          id <20090124173844.ZTBX19264.aamtaout01-winn.ispmail.ntl.com@pws-pc>
          for <zsh-workers@sunsite.dk>; Sat, 24 Jan 2009 17:38:44 +0000
Date: Sat, 24 Jan 2009 17:38:36 +0000
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@sunsite.dk
Subject: Re: sourcing a sh file in zsh
Message-ID: <20090124173836.64403fdc@pws-pc>
In-Reply-To: <200901241859.30029.arvidjaar@gmail.com>
References: <BD9D2405-AD6A-4336-9C8A-85149165B6B8@gmail.com>
	<200901161939.54651.arvidjaar@newmail.ru>
	<090116102934.ZM22119@torch.brasslantern.com>
	<200901241859.30029.arvidjaar@gmail.com>
X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.5; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Cloudmark-Analysis: v=1.0 c=1 a=NLZqzBF-AAAA:8 a=XpOveyXUMwn-HiwGWLcA:9 a=VZ7NhPXWMyg3KfItQ86SGMqZg_wA:4 a=LY0hPdMaydYA:10
X-Virus-Scanned: ClamAV 0.92.1/8899/Sat Jan 24 14:06:33 2009 on bifrost
X-Virus-Status: Clean

On Sat, 24 Jan 2009 18:59:27 +0300
Andrey Borzenkov <arvidjaar@gmail.com> wrote:
> On 16 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2009 21:29:34 Bart Schaefer wr=
ote:
> > Another possibility would be to extend the "emulate" command into a
> > precommand modifier sort of thing, where arguments following the name
> > of the emulation are treated as a command to execute.  Perhaps
> > require another option to make this active, to avoid any compatibily
> > issue.
> >
> >   emulate -LRE srh source file.sh
> >
>=20
> What about the following patch. It simply eval's any code after setting=20
> requested emulation. As a bonus it prints current emulation if no argumen=
t=20
> is specified. Neither should be of compatibility issues as emulate always=
=20
> allowed exactly one argument.
>=20
> Comments?

Certainly looks like it's going the right way---as you say there
shouldn't be any compatibility issues, so we can probably roll it out
and see what happens.  You need quotes for defining functions in an
emulation, or to creating a separate file.  Hmm... I wonder if we should
allow code from stdin for things like:

emulate -LRE sh <<HERE
function foo {
  ...
}
HERE

?

It would be good to get some tests, even ideas for tests, to tease out
any subtle cases where things are/aren't being set incorrectly.


There's still the issue of retaining the emulation mode for functions
defined in that mode; I agree we really ought to tackle that to make the
new functionality properly useful.  I expect Bart has ideas on the next
step; how far will we need to go?  The simplest idea would be for shell
functions to get a flag giving the emulation mode (with the default
being don't change emulation as now); we could set a global flag while
the "emulate" eval is being run that the mode flag for a function needs
to be inherited from the emulation.  Would this need another flag to
"emulate", or would it be good enough always to inherit the emulation
mode when "emulate -E" is in effect?  I don't think functions should
*always* inherit the emulation because it changes the current behaviour
too much---we would be resetting a whole load of options before every
function call.

I would guess we don't want to apply it to autoloaded functions which
already have their own rules.  We can also add commands to tweak the
emulation mode for individual functions, but that can be done
separately.

We do need to be quite clear on the rules to avoid tying ourselves in
knots with things like "emaulate -LRE sh autoload foo".  "foo", in my
interpretation, would not inherit sh behaviour here.  I think nested
"emulate"s should be unproblematic, however.

--=20
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/