[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Christian Faulhammer]

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

"Joe Peterson (lavajoe)" <lavajoe@gentoo.org>:
>   Modified:             ChangeLog
>   Added:                genlop-0.30.8.ebuild
>   Version bump for portability of -c option to non-GNU/Linux
> platforms (bug #172839) and better -r option performance/fixes

> 	dobin genlop || die

 Could use a die message.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Joe Peterson]

Thanks for the tip.  I added "failed to install genlop (via dobin)" -
not sure if there is a standard way to do this, as it seems many ebuilds
just do "dobin failed", and some do "failed to install ...".

						-Joe


Christian Faulhammer wrote:
> "Joe Peterson (lavajoe)" <lavajoe@gentoo.org>:
>>   Modified:             ChangeLog
>>   Added:                genlop-0.30.8.ebuild
>>   Version bump for portability of -c option to non-GNU/Linux
>> platforms (bug #172839) and better -r option performance/fixes
> 
>> 	dobin genlop || die
> 
>  Could use a die message.
> 
> V-Li
> 

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Christian Faulhammer]

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

Joe Peterson <lavajoe@gentoo.org>:

> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> not sure if there is a standard way to do this, as it seems many
> ebuilds just do "dobin failed", and some do "failed to install ...".

 It is mainly to localise which die command caused the halt.  So I know
of no standard.

V-Li 

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

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

On Wednesday 26 September 2007, Christian Faulhammer wrote:
> Joe Peterson <lavajoe@gentoo.org>:
> > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > not sure if there is a standard way to do this, as it seems many
> > ebuilds just do "dobin failed", and some do "failed to install ...".
>
>  It is mainly to localise which die command caused the halt.  So I know
> of no standard.

if there is just one call to die in a function, then i usually dont bother ... 
but if there are multiple ones (possibly nested), then it can easily save 
time
-mike

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Donnie Berkholz]

On 16:11 Wed 26 Sep     , Mike Frysinger wrote:
> On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > Joe Peterson <lavajoe@gentoo.org>:
> > > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > > not sure if there is a standard way to do this, as it seems many
> > > ebuilds just do "dobin failed", and some do "failed to install ...".
> >
> >  It is mainly to localise which die command caused the halt.  So I know
> > of no standard.
> 
> if there is just one call to die in a function, then i usually dont bother ... 
> but if there are multiple ones (possibly nested), then it can easily save 
> time

Cardoe was just telling me that die messages are not that useful or 
time-saving because portage posts the line number of the failure 
already. That prompts the question, should we get rid of die messages?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

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

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 16:11 Wed 26 Sep     , Mike Frysinger wrote:
> > On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > > Joe Peterson <lavajoe@gentoo.org>:
> > > > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > > > not sure if there is a standard way to do this, as it seems many
> > > > ebuilds just do "dobin failed", and some do "failed to install ...".
> > >
> > >  It is mainly to localise which die command caused the halt.  So I know
> > > of no standard.
> >
> > if there is just one call to die in a function, then i usually dont
> > bother ... but if there are multiple ones (possibly nested), then it can
> > easily save time
>
> Cardoe was just telling me that die messages are not that useful or
> time-saving because portage posts the line number of the failure
> already.

true, since portage has added this traceback feature (it hasnt always been 
there), the need for the message has decreased ... i want to say however that 
it still isnt 100% correct in some nested situations, but i may be 
remembering things wrong or outdated ...

also, ebuilds do change over time, so what line # may be correct one day may 
not be relevant the next ...

> That prompts the question, should we get rid of die messages? 

perhaps de-emphasize their general worth, but not get rid of them
-mike

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Ferris McCormick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 1677 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 26 Sep 2007 13:42:08 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> On 16:11 Wed 26 Sep     , Mike Frysinger wrote:
> > On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > > Joe Peterson <lavajoe@gentoo.org>:
> > > > Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > > > not sure if there is a standard way to do this, as it seems many
> > > > ebuilds just do "dobin failed", and some do "failed to install ...".
> > >
> > >  It is mainly to localise which die command caused the halt.  So I know
> > > of no standard.
> > 
> > if there is just one call to die in a function, then i usually dont bother ... 
> > but if there are multiple ones (possibly nested), then it can easily save 
> > time
> 
> Cardoe was just telling me that die messages are not that useful or 
> time-saving because portage posts the line number of the failure 
> already. That prompts the question, should we get rid of die messages?
> 
> Thanks,
> Donnie

No.  They might contain useful information.  Just the line
number of the failure is just frustrating:  You don't really
necessarily know what went wrong, and you have to go read the ebuild to
find out.  Users might not appreciate that.
> -- 
> gentoo-dev@gentoo.org mailing list
> 
Regards,

- -- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG+sspQa6M3+I///cRAr1QAJ9e1rGHNFBavGgR7pIxr1Xzaw12GgCg4lAK
k5/iP9fH0kcmYlBdjTKcYrY=
=BEej
-----END PGP SIGNATURE-----
éí¢‡^¾\a§¶Š(®	šŠX§‚X¬

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Doug Goldstein]

Christian Faulhammer wrote:
> Joe Peterson <lavajoe@gentoo.org>:
>
>   
>> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
>> not sure if there is a standard way to do this, as it seems many
>> ebuilds just do "dobin failed", and some do "failed to install ...".
>>     
>
>  It is mainly to localise which die command caused the halt.  So I know
> of no standard.
>
> V-Li 
>
>   
Except that's completely pointless since Portage and the other package
managers print the EXACT line number where the call was made. So this
thinking that a die message is required to identify which die was called
is flawed.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Doug Goldstein]

Ferris McCormick wrote:
> On Wed, 26 Sep 2007 13:42:08 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>
> > On 16:11 Wed 26 Sep     , Mike Frysinger wrote:
> >> On Wednesday 26 September 2007, Christian Faulhammer wrote:
> >>> Joe Peterson <lavajoe@gentoo.org>:
> >>>> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> >>>> not sure if there is a standard way to do this, as it seems many
> >>>> ebuilds just do "dobin failed", and some do "failed to install ...".
> >>>  It is mainly to localise which die command caused the halt.  So I
> know
> >>> of no standard.
> >> if there is just one call to die in a function, then i usually dont
> bother ...
> >> but if there are multiple ones (possibly nested), then it can
> easily save
> >> time
> > Cardoe was just telling me that die messages are not that useful or
> > time-saving because portage posts the line number of the failure
> > already. That prompts the question, should we get rid of die messages?
>
> > Thanks,
> > Donnie
>
> No.  They might contain useful information.  Just the line
> number of the failure is just frustrating:  You don't really
> necessarily know what went wrong, and you have to go read the ebuild to
> find out.  Users might not appreciate that.
> > --
> > gentoo-dev@gentoo.org mailing list
>
> Regards,
die "dobin failed" or something equally vague and pointless is no less
or more frustrating or informative then a line number. And arguably if
there's multiple statements that contain die "dobin failed" in an ebuild
it can set you on the wrong path and is equally and if not more frustrating.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Doug Goldstein]

Mike Frysinger wrote:
> On Wednesday 26 September 2007, Donnie Berkholz wrote:
>   
>> On 16:11 Wed 26 Sep     , Mike Frysinger wrote:
>>     
>>> On Wednesday 26 September 2007, Christian Faulhammer wrote:
>>>       
>>>> Joe Peterson <lavajoe@gentoo.org>:
>>>>         
>>>>> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
>>>>> not sure if there is a standard way to do this, as it seems many
>>>>> ebuilds just do "dobin failed", and some do "failed to install ...".
>>>>>           
>>>>  It is mainly to localise which die command caused the halt.  So I know
>>>> of no standard.
>>>>         
>>> if there is just one call to die in a function, then i usually dont
>>> bother ... but if there are multiple ones (possibly nested), then it can
>>> easily save time
>>>       
>> Cardoe was just telling me that die messages are not that useful or
>> time-saving because portage posts the line number of the failure
>> already.
>>     
>
> true, since portage has added this traceback feature (it hasnt always been 
> there), the need for the message has decreased ... i want to say however that 
> it still isnt 100% correct in some nested situations, but i may be 
> remembering things wrong or outdated ...
>   
I thought these issues were worked out already?

> also, ebuilds do change over time, so what line # may be correct one day may 
> not be relevant the next ...
>   
True. I will concede this point. I could attempt to argue this is why
it's important to know the version and revision of the package you are
emerging. But the counter point is evident, times when the ebuild is
changed without a bump pose a problem.

Which could bring up a point of would it be useful to see if we can
print out the actual line that caused the die. Now, I don't know if this
feasible or something the Portage devs want to do. But again, in the
effort to streamline this might be something to consider.

>   
>> That prompts the question, should we get rid of die messages? 
>>     
>
> perhaps de-emphasize their general worth, but not get rid of them
> -mike
>   
Which is what I'm after. Let's not force people to put a pointless
message in there if it's going to be pointless. Essentially, the
argument here is let's be consistent and put a message always. But a
better plan of action is let's use common sense and add it as needed.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Ferris McCormick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 26 Sep 2007 17:42:01 -0400
Doug Goldstein <cardoe@gentoo.org> wrote:

> Ferris McCormick wrote:
> > On Wed, 26 Sep 2007 13:42:08 -0700
> > Donnie Berkholz <dberkholz@gentoo.org> wrote:
> >
> > > On 16:11 Wed 26 Sep     , Mike Frysinger wrote:
> > >> On Wednesday 26 September 2007, Christian Faulhammer wrote:
> > >>> Joe Peterson <lavajoe@gentoo.org>:
> > >>>> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
> > >>>> not sure if there is a standard way to do this, as it seems many
> > >>>> ebuilds just do "dobin failed", and some do "failed to install ...".
> > >>>  It is mainly to localise which die command caused the halt.  So I
> > know
> > >>> of no standard.
> > >> if there is just one call to die in a function, then i usually dont
> > bother ...
> > >> but if there are multiple ones (possibly nested), then it can
> > easily save
> > >> time
> > > Cardoe was just telling me that die messages are not that useful or
> > > time-saving because portage posts the line number of the failure
> > > already. That prompts the question, should we get rid of die messages?
> >
> > > Thanks,
> > > Donnie
> >
> > No.  They might contain useful information.  Just the line
> > number of the failure is just frustrating:  You don't really
> > necessarily know what went wrong, and you have to go read the ebuild to
> > find out.  Users might not appreciate that.
> > > --
> > > gentoo-dev@gentoo.org mailing list
> >
> > Regards,
> die "dobin failed" or something equally vague and pointless is no less
> or more frustrating or informative then a line number. And arguably if
> there's multiple statements that contain die "dobin failed" in an ebuild
> it can set you on the wrong path and is equally and if not more frustrating.
> 
Well, I was talking about useful die messages of course.  'die "dobin
failed"' is the same as no die message at all.  Whoever wrote
'dobin ... || die "dobin failed"' certainly knows more than that.  'die
"dobin failed"' of course might as well be omitted, but better, it
seems to me, is to make it same something intelligent.
> 
> -- 
> gentoo-dev@gentoo.org mailing list
> 


- -- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG+ttGQa6M3+I///cRAjFwAKDeMoVxlrBaZG2t98ZTzfCMuWtdEACfUZ1I
NivmnTpQL+eztQB3BOVs3CA=
=pVt8
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Donnie Berkholz]

On 17:53 Wed 26 Sep     , Doug Goldstein wrote:
> Mike Frysinger wrote:
> > Donnie Berkholz wrote:
> > also, ebuilds do change over time, so what line # may be correct one day may 
> > not be relevant the next ...
> >   
> True. I will concede this point. I could attempt to argue this is why
> it's important to know the version and revision of the package you are
> emerging. But the counter point is evident, times when the ebuild is
> changed without a bump pose a problem.
> 
> Which could bring up a point of would it be useful to see if we can
> print out the actual line that caused the die. Now, I don't know if this
> feasible or something the Portage devs want to do. But again, in the
> effort to streamline this might be something to consider.

The backtrace code is in ebuild.sh:dump_trace(). If you can find a way 
in bash to print the source line, that would be great. I took another 
glance through the bash man page and didn't see much from that end. But 
since we do have the source file and line number, we could just grab it 
with some hack like:

sed -ne "${lineno}p" ${filename}

Anyone got something better?

> >> That prompts the question, should we get rid of die messages? 
> >>     
> >
> > perhaps de-emphasize their general worth, but not get rid of them
> > -mike
> >   
> Which is what I'm after. Let's not force people to put a pointless
> message in there if it's going to be pointless. Essentially, the
> argument here is let's be consistent and put a message always. But a
> better plan of action is let's use common sense and add it as needed.

That sounds reasonable. Anyone reviewing code, please ensure there's a 
reason if you're suggesting addition of a trivial die message, 
particularly if we can figure out how to start printing the actual bash 
code.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Joe Peterson]

Ferris McCormick wrote:
> On Wed, 26 Sep 2007 17:42:01 -0400
> Doug Goldstein <cardoe@gentoo.org> wrote:
> 
>> Ferris McCormick wrote:
>>> On Wed, 26 Sep 2007 13:42:08 -0700
>>> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>>>
>>>> On 16:11 Wed 26 Sep     , Mike Frysinger wrote:
>>>>> On Wednesday 26 September 2007, Christian Faulhammer wrote:
>>>>>> Joe Peterson <lavajoe@gentoo.org>:
>>>>>>> Thanks for the tip.  I added "failed to install genlop (via dobin)" -
>>>>>>> not sure if there is a standard way to do this, as it seems many
>>>>>>> ebuilds just do "dobin failed", and some do "failed to install ...".
>>>>>>  It is mainly to localise which die command caused the halt.  So I
>>> know
>>>>>> of no standard.
>>>>> if there is just one call to die in a function, then i usually dont
>>> bother ...
>>>>> but if there are multiple ones (possibly nested), then it can
>>> easily save
>>>>> time
>>>> Cardoe was just telling me that die messages are not that useful or
>>>> time-saving because portage posts the line number of the failure
>>>> already. That prompts the question, should we get rid of die messages?
>>>> Thanks,
>>>> Donnie
>>> No.  They might contain useful information.  Just the line
>>> number of the failure is just frustrating:  You don't really
>>> necessarily know what went wrong, and you have to go read the ebuild to
>>> find out.  Users might not appreciate that.
>>>> --
>>>> gentoo-dev@gentoo.org mailing list
>>> Regards,
>> die "dobin failed" or something equally vague and pointless is no less
>> or more frustrating or informative then a line number. And arguably if
>> there's multiple statements that contain die "dobin failed" in an ebuild
>> it can set you on the wrong path and is equally and if not more frustrating.
> 
> Well, I was talking about useful die messages of course.  'die "dobin
> failed"' is the same as no die message at all.  Whoever wrote
> 'dobin ... || die "dobin failed"' certainly knows more than that.  'die
> "dobin failed"' of course might as well be omitted, but better, it
> seems to me, is to make it same something intelligent.

Looks like almost 1/2 of them are simply "dobin failed":

find /usr/portage -name "*.ebuild" | xargs grep dobin | grep die | grep
'"dobin failed"$' | wc
     262    1885   24194

find /usr/portage -name "*.ebuild" | xargs grep dobin | grep die | grep
"\"$" | wc
     548    4183   54643

						-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

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

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 17:53 Wed 26 Sep     , Doug Goldstein wrote:
> > Mike Frysinger wrote:
> > > Donnie Berkholz wrote:
> > > also, ebuilds do change over time, so what line # may be correct one
> > > day may not be relevant the next ...
> >
> > True. I will concede this point. I could attempt to argue this is why
> > it's important to know the version and revision of the package you are
> > emerging. But the counter point is evident, times when the ebuild is
> > changed without a bump pose a problem.
> >
> > Which could bring up a point of would it be useful to see if we can
> > print out the actual line that caused the die. Now, I don't know if this
> > feasible or something the Portage devs want to do. But again, in the
> > effort to streamline this might be something to consider.
>
> The backtrace code is in ebuild.sh:dump_trace(). If you can find a way
> in bash to print the source line, that would be great. I took another
> glance through the bash man page and didn't see much from that end. But
> since we do have the source file and line number, we could just grab it
> with some hack like:
>
> sed -ne "${lineno}p" ${filename}
>
> Anyone got something better?

that's probably about the best ... the trace was invoked because of the call 
to `die`, not the previous call and i dont think the stack stuff in bash 
tracks history, just the current execution tree

that sed will probably work about half the time since it'll only work on one 
liners ...
-mike

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Rémi Cardona]

Mike Frysinger wrote:
> On Wednesday 26 September 2007, Donnie Berkholz wrote:
>> sed -ne "${lineno}p" ${filename}
>>
>> Anyone got something better?
>
> that sed will probably work about half the time since it'll only work on one 
> liners ...

Print one or two lines before and after ${lineno} and highlight ${lineno} ?

Rémi
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

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

On Wednesday 26 September 2007, Donnie Berkholz wrote:
> On 17:53 Wed 26 Sep     , Doug Goldstein wrote:
> > Mike Frysinger wrote:
> > > Donnie Berkholz wrote:
> > > also, ebuilds do change over time, so what line # may be correct one
> > > day may not be relevant the next ...
> >
> > True. I will concede this point. I could attempt to argue this is why
> > it's important to know the version and revision of the package you are
> > emerging. But the counter point is evident, times when the ebuild is
> > changed without a bump pose a problem.
> >
> > Which could bring up a point of would it be useful to see if we can
> > print out the actual line that caused the die. Now, I don't know if this
> > feasible or something the Portage devs want to do. But again, in the
> > effort to streamline this might be something to consider.
>
> The backtrace code is in ebuild.sh:dump_trace(). If you can find a way
> in bash to print the source line, that would be great. I took another
> glance through the bash man page and didn't see much from that end. But
> since we do have the source file and line number, we could just grab it
> with some hack like:
>
> sed -ne "${lineno}p" ${filename}
>
> Anyone got something better?

how about this:
+	eerror "The specific snippet of code:"
+	# This scans the file that called die and prints out the logic that
+	# ended in the call to die.  This really only handles lines that end
+	# with '|| die' and any preceding lines with line continuations (\).
+	# This tends to be the most common usage though, so let's do it.
+	# Due to the usage of appending to the hold space (even when empty),
+	# we always end up with the first line being a blank (thus the 2nd sed).
+	sed -n \
+		-e "# When we get to the line that failed, append it to the
+		    # hold space, move the hold space to the pattern space,
+		    # then print out the pattern space and quit immediately
+		    ${BASH_LINENO[0]}{H;g;p;q}" \
+		-e '# If this line ends with a line continuation, append it
+		    # to the hold space
+		    /\\$/H' \
+		-e '# If this line does not end with a line continuation,
+		    # erase the line and set the hold buffer to it (thus
+		    # erasing the hold buffer in the process)
+		    /[^\]$/{s:^.*$::;h}' \
+		${BASH_SOURCE[1]} \
+		| sed -e '1d' \
+		| (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; eerror "  
${n}") ; done)
-mike

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Ulrich Mueller]

>>>>> On Thu, 27 Sep 2007, Mike Frysinger wrote:

> how about this:
> [...]
> +		| (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; eerror "  
> ${n}") ; done)

This is rather ugly. These IFS games are to allow for leading
whitespace, right?

Can't you do something like "xargs -d'\n' -n1 eerror"?

Ulrich
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

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

On Thursday 27 September 2007, Ulrich Mueller wrote:
> >>>>> On Thu, 27 Sep 2007, Mike Frysinger wrote:
> >
> > how about this:
> > [...]
> > +		| (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; eerror "
> > ${n}") ; done)
>
> This is rather ugly. These IFS games are to allow for leading
> whitespace, right?

exactly

> Can't you do something like "xargs -d'\n' -n1 eerror"?

the BSD wankers would complain their xargs doesnt support -d
-mike

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Ulrich Mueller]

>>>>> On Thu, 27 Sep 2007, Mike Frysinger wrote:

>> > +		| (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; eerror "
>> > ${n}") ; done)

>> Can't you do something like "xargs -d'\n' -n1 eerror"?

> the BSD wankers would complain their xargs doesnt support -d

That's true. Then:
   sed 's/^/X/' | while read -r n; do eerror "${n#X}"; done
(The substitution can be included in the previous sed command.)

Ulrich
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Roy Marples]

On Thursday 27 September 2007 14:00:37 Mike Frysinger wrote:
> the BSD wankers

Better to wank over the Devil instead of being buggered by a pengiun :P
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Steve Long]

Donnie Berkholz wrote:
> On 17:53 Wed 26 Sep     , Doug Goldstein wrote:
>> Mike Frysinger wrote:
>> > Donnie Berkholz wrote:
>> > also, ebuilds do change over time, so what line # may be correct one
>> > day may not be relevant the next ...
>> >   
>> 
>> Which could bring up a point of would it be useful to see if we can
>> print out the actual line that caused the die. Now, I don't know if this
>> feasible or something the Portage devs want to do. But again, in the
>> effort to streamline this might be something to consider.
> 
> The backtrace code is in ebuild.sh:dump_trace(). If you can find a way
> in bash to print the source line, that would be great. I took another
> glance through the bash man page and didn't see much from that end. But
> since we do have the source file and line number, we could just grab it
> with some hack like:
> 
> sed -ne "${lineno}p" ${filename}
> 
> Anyone got something better?
>
This is from abort() in update (unreleased):
abort() {
        f="Internal error in ${FUNCNAME[1]}(${BASH_LINENO[0]})"
        n=${#FUNCNAME[@]}
        if ((n>3)); then
                for ((i=2;i<n-1;i++)); do
                        f+=" :${FUNCNAME[i]}(${BASH_LINENO[i-1]})"
                done
                f+=" : line ${BASH_LINENO[i-1]}"
        fi
        echo "!! $prog: $f"
}
- which provides a stacktrace for a bash script calling abort in the same
way as die is used. It _really_ helps for debugging (it doesn't always get
used, depending on how abort is called.)
HTH.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/genlop: ChangeLog genlop-0.30.8.ebuild

[Mike Frysinger]

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

On Thursday 27 September 2007, Ulrich Mueller wrote:
> >>>>> On Thu, 27 Sep 2007, Mike Frysinger wrote:
> >> >
> >> > +		| (OFS=${IFS} IFS=$'\n'; while read -r n ; do (IFS=${OFS}; eerror "
> >> > ${n}") ; done)
> >>
> >> Can't you do something like "xargs -d'\n' -n1 eerror"?
> >
> > the BSD wankers would complain their xargs doesnt support -d
>
> That's true. Then:
>    sed 's/^/X/' | while read -r n; do eerror "${n#X}"; done
> (The substitution can be included in the previous sed command.)

yeah, that works nicely, thanks

time to commit !
-mike

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