FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-25-2012, 09:05 PM
Katie Toreg
 
Default lastpipe

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.
 
Old 05-25-2012, 10:33 PM
Ciaran McCreesh
 
Default lastpipe

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
 
Old 05-26-2012, 12:11 AM
Dan Douglas
 
Default lastpipe

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
 
Old 05-26-2012, 12:52 AM
Mike Frysinger
 
Default lastpipe

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
' a b c |
while read line ; do
: $(( count++ ))
done
echo $count

w/out lastpipe, that shows 0. w/lastpipe, that shows 3.
-mike
 
Old 05-26-2012, 01:56 AM
Dan Douglas
 
Default lastpipe

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
' 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
 
Old 05-26-2012, 07:50 AM
Samuli Suominen
 
Default lastpipe

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
 

Thread Tools




All times are GMT. The time now is 10:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org