Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Andrey Grozin]

On Wed, 24 Dec 2008, Petteri R?ty wrote:
> Who has been removing die statements? Is this a suggested way of action
> somewhere by someone?
As recently discussed on the list, econf dies by itself, and || die should 
better be removed after econf. The same is true for, e.g., eqmake4. It was 
discussed (don't have a reference to the thread at hand) that it would be 
useful to have a table which shows which functions die by themselves, and 
which not.

Andrey

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Jeremy Olexa]

Andrey Grozin wrote:
> On Wed, 24 Dec 2008, Petteri R?ty wrote:
>> Who has been removing die statements? Is this a suggested way of action
>> somewhere by someone?
> As recently discussed on the list, econf dies by itself, and || die 
> should better be removed after econf. The same is true for, e.g., 
> eqmake4. It was discussed (don't have a reference to the thread at hand) 
> that it would be useful to have a table which shows which functions die 
> by themselves, and which not.
> 
> Andrey
> 

I see this asked every X months and never quite figured out why, (this 
isn't personal against you, Andrey)

%% pwd
/usr/lib/portage/bin
%% grep -l die *
ebuild.sh
etc-update
isolated-functions.sh
misc-functions.sh
repoman

So, that means that none of these die:
%% ls do*
dobin*    dodoc*   dohard*  doinitd*  dolib.a*   domo*      dosed*
doconfd*  doenvd*  dohtml*  doins*    dolib.so*  donewins@  dosym*
dodir*    doexe*   doinfo*  dolib*    doman*     dosbin*

or

%% ls new*
newbin*    newdoc*   newexe*    newins*    newlib.so*  newsbin*
newconfd*  newenvd*  newinitd*  newlib.a*  newman*

etc.

Take a look for yourself and you will see why there has never been a 
"table" or anything created. (it is trivial - and you have the source on 
your computer already)

Maybe this should be a question asked on the new dev quizies.."How do I 
tell if something dies on its own or not?"

HTH,
Jeremy

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Ciaran McCreesh]

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

On Wed, 24 Dec 2008 00:19:06 -0600
Jeremy Olexa <darkside@gentoo.org> wrote:
> Take a look for yourself and you will see why there has never been a 
> "table" or anything created. (it is trivial - and you have the source
> on your computer already)

It's even trivialler than you think. If it's an external program, it
can't die.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Ben de Groot]

Jeremy Olexa wrote:
> Andrey Grozin wrote:
>> It was discussed (don't have a reference to the thread at
>> hand) that it would be useful to have a table which shows which
>> functions die by themselves, and which not.
>>
>> Andrey
>>
> 
> I see this asked every X months and never quite figured out why, (this
> isn't personal against you, Andrey)
[...]
> Take a look for yourself and you will see why there has never been a
> "table" or anything created. (it is trivial - and you have the source on
> your computer already)

It shouldn't be necessary to grep the source, if these things would
follow a simple logical rule, in accordance with the principle of least
surprise. It would be handy to be able to say: all e* functions die, but
do* and new* do not. But tommy's list shows that emake is an exception
to the rule. I'm not aware of any other exceptions, but I can't be sure
unless I go digging through the source. Which really should not be
necessary, in my opinion.

-- 
Ben de Groot
Gentoo Linux developer (lxde, media, qt, desktop-misc)
Gentoo Linux Release Engineering PR liaison
______________________________________________________

yngwin@gentoo.org
http://ben.liveforge.org/
irc://chat.freenode.net/#gentoo-media
irc://irc.oftc.net/#lxde
______________________________________________________

[gentoo-dev] Re: Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

[Steve Long]

Ben de Groot wrote:
> Jeremy Olexa wrote:
>> Andrey Grozin wrote:
>>> It was discussed (don't have a reference to the thread at
>>> hand) that it would be useful to have a table which shows which
>>> functions die by themselves, and which not.
>>>
>> I see this asked every X months and never quite figured out why, (this
>> isn't personal against you, Andrey)
> [...]
>> Take a look for yourself and you will see why there has never been a
>> "table" or anything created. (it is trivial - and you have the source on
>> your computer already)
That's more an argument for putting the table on the web than continuing
without adequate documentation. If it's going to change, automate it using
the script you posted (assuming it's watertight.)
> 
> It shouldn't be necessary to grep the source
Agreed.

[gentoo-dev] List of ebuild functions that die/do not die

[Thomas Sachau]

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

As it seems like noone else is doing something about it, i have started a list with some entries[1].
Please send me more functions and their place and error reports directly to me (via mail or irc).

[1]: http://dev.gentoo.org/~tommy/ebuild-functions.txt


-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

Re: [gentoo-dev] List of ebuild functions that die/do not die

[Nirbheek Chauhan]

On Wed, Dec 24, 2008 at 8:27 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> As it seems like noone else is doing something about it, i have started a list with some entries[1].
> Please send me more functions and their place and error reports directly to me (via mail or irc).

I thought that the rules for determination were pretty straightforward:

commands that die:
everything that is implemented as a function (ebuild.sh, eclasses, etc)

commands that don't die:
every external application (do*, cp, etc)


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] List of ebuild functions that die/do not die

[Doug Goldstein]

Nirbheek Chauhan wrote:
> On Wed, Dec 24, 2008 at 8:27 PM, Thomas Sachau <tommy@gentoo.org> wrote:
>   
>> As it seems like noone else is doing something about it, i have started a list with some entries[1].
>> Please send me more functions and their place and error reports directly to me (via mail or irc).
>>     
>
> I thought that the rules for determination were pretty straightforward:
>
> commands that die:
> everything that is implemented as a function (ebuild.sh, eclasses, etc)
>
> commands that don't die:
> every external application (do*, cp, etc)
>
>
>   
Technically the rule is that eclasses shouldn't die. At least that's the 
latest version of the rules that I remember.

Re: [gentoo-dev] List of ebuild functions that die/do not die

[Nirbheek Chauhan]

On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
> Nirbheek Chauhan wrote:
[snip]
>> commands that die:
>> everything that is implemented as a function (ebuild.sh, eclasses, etc)
[snip]
>
> Technically the rule is that eclasses shouldn't die. At least that's the
> latest version of the rules that I remember.
>

eclasses shouldn't die or functions inside eclasses shouldn't die? I
meant the latter:

s/(ebuild.sh/(inside ebuild.sh/

-- 
~Nirbheek Chauhan

[gentoo-dev] Re: List of ebuild functions that die/do not die

[Steve Long]

Nirbheek Chauhan wrote:

> On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
>> Nirbheek Chauhan wrote:
> [snip]
>>> commands that die:
>>> everything that is implemented as a function (ebuild.sh, eclasses, etc)
> [snip]
>>
>> Technically the rule is that eclasses shouldn't die. At least that's the
>> latest version of the rules that I remember.
>>
> 
> eclasses shouldn't die or functions inside eclasses shouldn't die? I
> meant the latter:
> 
> s/(ebuild.sh/(inside ebuild.sh/
> 
The only technical reason not to allow an --or-die (or the equivalent)
switch for everything is the issues with subshell die, for which I sent
some script to test but didn't hear back about, but more cogently that old
GNU heads think xargs is necessary as GNU find didn't implement -exec
correctly (according to POSIX) until a couple of years ago.

In BASH, one would use the equivalent loop (which will cope with any
filename):
while read -rd '' f; do foo --or-die "$f"; done < <(find .. -print0)

I usually show newbs this:
while read -rd ''; do arr+=("$REPLY"); done < <(find .. -print0)
..since it shows a bit more about read and gives the other usual
requirement.

This is compatible with the old broken GNU find as well as BSD, but -print0
is not required by POSIX.

I'm sure I've used that in a function somewhere amongst one of the patches I
filed with someone or the other. TBH a professional BASH scripter would
sneer (I can think of several) at needing to wrap it in a function: it's
like not knowing how to read a file line-by-line in POSIX sh.

Put it this way: if you actually need the filenames, or some other
information elsewhere in the script[1], chances are that the loop has more
meat to it.

I suppose you could pass directories and params for a find command/API
function, eg:
findE --or-die foo dirA/b dirC/d ! \( -type -l -o -name '*~' \)
..or the like, showing --or-die first for consistency but it could of course
come anywhere.

[1] /msg greybot faq disappear