[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gnat.eclass

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gnat.eclass

[Donnie Berkholz]

On 20:41 Wed 26 Sep     , George Shapovalov (george) wrote:
> george      07/09/26 20:41:34
> 
>   Modified:             gnat.eclass
>   Log:
>   added get_active_profile helper function

> Revision  Changes    Path
> 1.28                 eclass/gnat.eclass
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnat.eclass?rev=1.28&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnat.eclass?rev=1.28&content-type=text/plain
> diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/gnat.eclass?r1=1.27&r2=1.28

> +# Returns a name of active gnat profile. Peroroms some validity checks. No input
> +# parameters, analyzes the system setup directly.
> +get_active_profile() {
> +	# get common code and settings
> +	. ${GnatCommon} || die "failed to source gnat-common lib"
> +
> +	local profiles=( $(get_env_list) ) 
> +
> +	if [[ ${profiles[@]} == "${MARKER}*" ]]; then 
> +		exit 

I'm surprised to see exit called in a function instead of returning 
nonzero.

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

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gnat.eclass

[George Shapovalov]

Thursday, 27. September 2007, Donnie Berkholz Ви написали:
> > +	if [[ ${profiles[@]} == "${MARKER}*" ]]; then
> > +		exit
>
> I'm surprised to see exit called in a function instead of returning
> nonzero.

This exit here indicates not a very usual but a valid situation, - no gnat 
profile has been activated yet. So, this is not an error, at least not 
always. But yes, returning a non zero also possible, though testing the 
result is not that different from testing for a non-zero string, and the 
latter is not intuitively percieved as an error :).

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gnat.eclass

[Mike Frysinger]

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

On Thursday 27 September 2007, George Shapovalov wrote:
> Thursday, 27. September 2007, Donnie Berkholz Ви написали:
> > > +	if [[ ${profiles[@]} == "${MARKER}*" ]]; then
> > > +		exit
> >
> > I'm surprised to see exit called in a function instead of returning
> > nonzero.
>
> This exit here indicates not a very usual but a valid situation, - no gnat
> profile has been activated yet. So, this is not an error, at least not
> always. But yes, returning a non zero also possible, though testing the
> result is not that different from testing for a non-zero string, and the
> latter is not intuitively percieved as an error :).

i think more to the point, ebuilds/eclasses should never be calling `exit`

if you want to "return an empty string", then you do `return`
-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 eclass: gnat.eclass

[George Shapovalov]

Thursday, 27. September 2007, Mike Frysinger Ви написали:
> i think more to the point, ebuilds/eclasses should never be calling `exit`
>
> if you want to "return an empty string", then you do `return`
Ok, sorry, will fix.
Any pointers to some description of where each should be used? Is this 
about "the shell closing itself"? They both seem to have exactly the same 
effect in this code..

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gnat.eclass

[Mike Frysinger]

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

On Thursday 27 September 2007, George Shapovalov wrote:
> Thursday, 27. September 2007, Mike Frysinger Ви написали:
> > i think more to the point, ebuilds/eclasses should never be calling
> > `exit`
> >
> > if you want to "return an empty string", then you do `return`
>
> Ok, sorry, will fix.
> Any pointers to some description of where each should be used?

how about:
exit should be used: never
;)

> Is this about "the shell closing itself"?

it's about people in the past incorrectly used `exit` instead of `die` so we'd 
prefer exit not leak back in so that new people dont inadvertently get the 
same idea

> They both seem to have exactly the same effect in this code..

i imagine the way you're using it, that is true (subshelling for output / 
piping), but considering the above, we'd really ask you go with return
-mike

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