[gentoo-dev] lastpipe

[gentoo-dev] lastpipe

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

As many are probably aware, Bash 4.2 adds a shopt feature to enable not 
running the last command of a pipeline in a subshell (POSIX leaves it up to 
the shell to decide). Aside from being a slight optimization, it allows some 
syntactic convenience such as reduced reliance upon process substitutions and 
redundant command grouping workarounds. I believe it is generally considered 
that the lastpipe behavior is superior. zsh and ksh do this by default, while 
mksh, bash, and dash do not. Only Bash has it as a configurable option.

If it were made a policy now that ebuilds and eclasses cannot depend upon the 
subshell (for example, to set temporary positional parameters or isolate 
temporary variables), then maybe someday in the distant future this could be 
made the default, and in the meantime, an option for those with new enough 
shells. Since dependence on the subshell isn't very common, I think this 
should be feasible, and of course as a workaround all that's required is to 
wrap any such commands in parentheses.

Any opinions?
-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] lastpipe

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Fri, 25 May 2012 15:02:32 -0500
Dan Douglas <ormaaj@gmail.com> wrote:
> If it were made a policy now that ebuilds and eclasses cannot depend
> upon the subshell (for example, to set temporary positional
> parameters or isolate temporary variables), then maybe someday in the
> distant future this could be made the default, and in the meantime,
> an option for those with new enough shells. Since dependence on the
> subshell isn't very common, I think this should be feasible, and of
> course as a workaround all that's required is to wrap any such
> commands in parentheses.

We'll be able to turn that on in a controlled way in EAPI 6. Having
said that, if we're reaching the point where speed of bash code is
at all relevant, then ebuilds are doing something wrong...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] lastpipe

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

On Friday, May 25, 2012 11:33:43 PM Ciaran McCreesh wrote:
> On Fri, 25 May 2012 15:02:32 -0500
> Dan Douglas <ormaaj@gmail.com> wrote:
> > If it were made a policy now that ebuilds and eclasses cannot depend
> > upon the subshell (for example, to set temporary positional
> > parameters or isolate temporary variables), then maybe someday in the
> > distant future this could be made the default, and in the meantime,
> > an option for those with new enough shells. Since dependence on the
> > subshell isn't very common, I think this should be feasible, and of
> > course as a workaround all that's required is to wrap any such
> > commands in parentheses.
> 
> We'll be able to turn that on in a controlled way in EAPI 6.

Ah didn't know that. That's a solution for ebuilds anyway. How about for eclasses and user bashrc files? Does whatever EAPI setting is in effect for a particular ebuild apply to them? It isn't really worth toggling it on and off for individual files or functions in order to not break certain eclasses that conflict.

> Having
> said that, if we're reaching the point where speed of bash code is
> at all relevant, then ebuilds are doing something wrong...
>

That point was reached when someone decided a custom Bash parser just for ebuilds was necessary. :)

-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] lastpipe

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1130 bytes --]

On Friday 25 May 2012 18:33:43 Ciaran McCreesh wrote:
> On Fri, 25 May 2012 15:02:32 -0500 Dan Douglas wrote:
> > If it were made a policy now that ebuilds and eclasses cannot depend
> > upon the subshell (for example, to set temporary positional
> > parameters or isolate temporary variables), then maybe someday in the
> > distant future this could be made the default, and in the meantime,
> > an option for those with new enough shells. Since dependence on the
> > subshell isn't very common, I think this should be feasible, and of
> > course as a workaround all that's required is to wrap any such
> > commands in parentheses.
> 
> We'll be able to turn that on in a controlled way in EAPI 6. Having
> said that, if we're reaching the point where speed of bash code is
> at all relevant, then ebuilds are doing something wrong...

i don't think speed is the main motivator, but rather avoiding behavior that 
bites new people all the time:
	count=0
	printf '%s\n' a b c | \
	while read line ; do
		: $(( count++ ))
	done
	echo $count

w/out lastpipe, that shows 0.  w/lastpipe, that shows 3.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] lastpipe

[Dan Douglas]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

On Friday, May 25, 2012 08:52:00 PM Mike Frysinger wrote:
> On Friday 25 May 2012 18:33:43 Ciaran McCreesh wrote:
> > On Fri, 25 May 2012 15:02:32 -0500 Dan Douglas wrote:
> > > If it were made a policy now that ebuilds and eclasses cannot depend
> > > upon the subshell (for example, to set temporary positional
> > > parameters or isolate temporary variables), then maybe someday in the
> > > distant future this could be made the default, and in the meantime,
> > > an option for those with new enough shells. Since dependence on the
> > > subshell isn't very common, I think this should be feasible, and of
> > > course as a workaround all that's required is to wrap any such
> > > commands in parentheses.
> > 
> > We'll be able to turn that on in a controlled way in EAPI 6. Having
> > said that, if we're reaching the point where speed of bash code is
> > at all relevant, then ebuilds are doing something wrong...
> 
> i don't think speed is the main motivator, but rather avoiding behavior that 
> bites new people all the time:
> 	count=0
> 	printf '%s\n' a b c | \
> 	while read line ; do
> 		: $(( count++ ))
> 	done
> 	echo $count
> 
> w/out lastpipe, that shows 0.  w/lastpipe, that shows 3.
> -mike

Right, performance is just a nice side-effect. It makes a number of things 
cleaner (especially if the printf in that case were replaced with something 
more complicated), and is more intuitive for beginners .

However, all involved code needs to be able to expect lastpipe to always be 
either one way or the other, not mix-and-match. This means either EAPI 6 
requires Bash 4.2, or if Bash version detection is involved, a lot of the 
benefit to lastpipe is lost. Code which can't predict the behavior has to be 
written not only as though lastpipe were disabled, but also to account for the 
possility that it is enabled to avoid name conflicts.

In that example it would mean adding an explicit subshell, or saving and 
restoring the value of "line" before/after, or putting it into a function and 
using locals, or always making sure code executed after the loop initializes 
"line" to a known state.
-- 
Dan Douglas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]