Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

lastpipe

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


ormaaj at gmail

May 25, 2012, 1:02 PM

Post #1 of 7 (157 views)
Permalink
lastpipe

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
Attachments: signature.asc (0.19 KB)


iteratee at gmail

May 25, 2012, 2:05 PM

Post #2 of 7 (152 views)
Permalink
Re: lastpipe [In reply to]

I like it. There would be plenty of time for migration considering the 4.2
requirement. Unfortunately, writing a QA check for violations would be
nearly impossible.


ciaran.mccreesh at googlemail

May 25, 2012, 3:33 PM

Post #3 of 7 (153 views)
Permalink
Re: lastpipe [In reply to]

On Fri, 25 May 2012 15:02:32 -0500
Dan Douglas <ormaaj [at] gmail> 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
Attachments: signature.asc (0.19 KB)


ormaaj at gmail

May 25, 2012, 5:11 PM

Post #4 of 7 (153 views)
Permalink
Re: lastpipe [In reply to]

On Friday, May 25, 2012 11:33:43 PM Ciaran McCreesh wrote:
> On Fri, 25 May 2012 15:02:32 -0500
> Dan Douglas <ormaaj [at] gmail> 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
Attachments: signature.asc (0.19 KB)


vapier at gentoo

May 25, 2012, 5:52 PM

Post #5 of 7 (158 views)
Permalink
Re: lastpipe [In reply to]

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
Attachments: signature.asc (0.82 KB)


ormaaj at gmail

May 25, 2012, 6:56 PM

Post #6 of 7 (154 views)
Permalink
Re: lastpipe [In reply to]

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
Attachments: signature.asc (0.19 KB)


ssuominen at gentoo

May 26, 2012, 12:50 AM

Post #7 of 7 (146 views)
Permalink
Re: Re: lastpipe [In reply to]

On 05/26/2012 12:05 AM, Katie Toreg wrote:
> I like it. There would be plenty of time for migration considering the
> 4.2 requirement. Unfortunately, writing a QA check for violations would
> be nearly impossible.

(Unrelated.)

Please disable HTML from your mail client when posting to Mailing List(s)

Thanks,
Samuli

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.