From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-26420-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 11997 invoked from network); 24 Jan 2009 23:27:21 -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.5 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 23:27:21 -0000
Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts)
Received: (qmail 4520 invoked from network); 24 Jan 2009 23:27:17 -0000
Received: from sunsite.dk (130.225.247.90)
  by a.mx.sunsite.dk with SMTP; 24 Jan 2009 23:27:17 -0000
Received: (qmail 23712 invoked by alias); 24 Jan 2009 23:27:11 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 26420
Received: (qmail 23697 invoked from network); 24 Jan 2009 23:27:10 -0000
Received: from bifrost.dotsrc.org (130.225.254.106)
  by sunsite.dk with SMTP; 24 Jan 2009 23:27:10 -0000
Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7])
	by bifrost.dotsrc.org (Postfix) with ESMTP id B6827802720F
	for <zsh-workers@sunsite.dk>; Sun, 25 Jan 2009 00:27:05 +0100 (CET)
Received: from torch.brasslantern.com ([96.238.220.215])
 by vms173007.mailsrvcs.net
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPA id <0KE000BUU121XHO1@vms173007.mailsrvcs.net> for
 zsh-workers@sunsite.dk; Sat, 24 Jan 2009 17:25:18 -0600 (CST)
Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1])
	by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n0ONQhN0024165	for
 <zsh-workers@sunsite.dk>; Sat, 24 Jan 2009 15:26:44 -0800
Received: (from schaefer@localhost)	by torch.brasslantern.com
 (8.13.1/8.13.1/Submit) id n0ONQhR8024164	for zsh-workers@sunsite.dk; Sat,
 24 Jan 2009 15:26:43 -0800
Date: Sat, 24 Jan 2009 15:26:43 -0800
From: Bart Schaefer <schaefer@brasslantern.com>
Subject: Re: sourcing a sh file in zsh
In-reply-to: <20090124173836.64403fdc@pws-pc>
To: zsh-workers@sunsite.dk
Message-id: <090124152643.ZM24163@torch.brasslantern.com>
MIME-version: 1.0
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
Content-type: text/plain; charset=us-ascii
References: <BD9D2405-AD6A-4336-9C8A-85149165B6B8@gmail.com>
	<200901161939.54651.arvidjaar@newmail.ru>
	<090116102934.ZM22119@torch.brasslantern.com>
	<200901241859.30029.arvidjaar@gmail.com>	<20090124173836.64403fdc@pws-pc>
Comments: In reply to Peter Stephenson <p.w.stephenson@ntlworld.com>
 "Re: sourcing a sh file in zsh" (Jan 24,  5:38pm)
X-Virus-Scanned: ClamAV 0.92.1/8899/Sat Jan 24 14:06:33 2009 on bifrost
X-Virus-Status: Clean

On Jan 24,  5:38pm, Peter Stephenson wrote:
} Subject: Re: sourcing a sh file in zsh
}
} You need quotes for defining functions in an
} emulation, or to creating a separate file.

Yeah, that was one of my reasons for pondering making it a reserved
word or the like.

} Hmm... I wonder if we should allow code from stdin

That'd at least need another option, otherwise "emulate -E" would always
read standard input, which would be bad if it appeared in a script and
started evaluating whatever was written at it.

} for things like:
} 
} emulate -LRE sh <<HERE
} function foo {
}   ...
} }
} HERE

You can always do

emulate -LRE sh $(<<-\HERE
	function foo {
	 ...
	}
	HERE)

I'm not sure offhand if you could double-quote all of that, easily ...

} 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?

I refer you to workers/26336 where Phil makes some comments about how
he'd modify the wordcode to handle this.

} [...] 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 think the latter.

} 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 agree.

} I would guess we don't want to apply it to autoloaded functions which
} already have their own rules.

Also agreed, which would imply:

} 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.