Mailing List Archive

On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty <betelgeuse@gentoo.org>
wrote:
| It already works in ~arch so will hit stable too sometime in the
| future.

Better to say, you might soon be able to get away with it, but don't
rely upon it actually working...

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

Ciaran McCreesh kirjoitti:
> On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty <betelgeuse@gentoo.org>
> wrote:
> | It already works in ~arch so will hit stable too sometime in the
> | future.
>
> Better to say, you might soon be able to get away with it, but don't
> rely upon it actually working...
>

Well one valid usage I can think of are eclass functions that are called
are called like FOO="$(eclassfunc)".

Regards,
Petteri

On Mon, 01 Jan 2007 22:28:10 +0200 Petteri Räty <betelgeuse@gentoo.org>
wrote:
| Ciaran McCreesh kirjoitti:
| > On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty
| > <betelgeuse@gentoo.org> wrote:
| > | It already works in ~arch so will hit stable too sometime in the
| > | future.
| >
| > Better to say, you might soon be able to get away with it, but don't
| > rely upon it actually working...
|
| Well one valid usage I can think of are eclass functions that are
| called are called like FOO="$(eclassfunc)".

Which is all nice and pretty, when it works, yes. But whilst my die
trick is a lot smarter than Aron's, it's still not entirely reliable.
In particular, if you do $(foo || die ; bar ), there's a race condition
which means bar might be executed anyway, and if you do enough arcane
shell voodoo then the die might still end up being lost completely (we
had this with eselect at one point...).

So basically, don't rely upon it working. It means you're much less
likely to be screwed over if you *do* accidentally do a subshell die,
but it doesn't mean that subshell die works.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

Ciaran McCreesh kirjoitti:
> On Mon, 01 Jan 2007 22:28:10 +0200 Petteri Räty <betelgeuse@gentoo.org>
> wrote:
> | Ciaran McCreesh kirjoitti:
> | > On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty
> | > <betelgeuse@gentoo.org> wrote:
> | > | It already works in ~arch so will hit stable too sometime in the
> | > | future.
> | >
> | > Better to say, you might soon be able to get away with it, but don't
> | > rely upon it actually working...
> |
> | Well one valid usage I can think of are eclass functions that are
> | called are called like FOO="$(eclassfunc)".
>
> Which is all nice and pretty, when it works, yes. But whilst my die
> trick is a lot smarter than Aron's, it's still not entirely reliable.
> In particular, if you do $(foo || die ; bar ), there's a race condition
> which means bar might be executed anyway, and if you do enough arcane
> shell voodoo then the die might still end up being lost completely (we
> had this with eselect at one point...).
>
> So basically, don't rely upon it working. It means you're much less
> likely to be screwed over if you *do* accidentally do a subshell die,
> but it doesn't mean that subshell die works.
>

Well at least seeing the stack trace should alarm some bells. If you
have a suggestion on how to to call an eclass function and having die
working, please share it with the rest of us.

Regards,
Petteri

On Monday 01 January 2007 15:12, Petteri Räty wrote:
> It already works in ~arch so will hit stable too sometime in the future.

until it completely works (versus just mostly works), why mention this ? it'd
be better to continue on with the 'dont use subshells' especially since it
hasnt really been limiting us in terms of ebuild development
-mike

Mike Frysinger kirjoitti:
> On Monday 01 January 2007 15:12, Petteri Räty wrote:
>> It already works in ~arch so will hit stable too sometime in the future.
>
> until it completely works (versus just mostly works), why mention this ? it'd
> be better to continue on with the 'dont use subshells' especially since it
> hasnt really been limiting us in terms of ebuild development
> -mike

Well I was under the impression from zmedico that it completely works.
The message was more meant as maybe some stuff will pop up that was
always dieing before but was not noticed.

Regards,
Petteri

On Tue, 02 Jan 2007 18:28:05 +0200 Petteri Räty <betelgeuse@gentoo.org>
wrote:
| Well I was under the impression from zmedico that it completely works.

zmedico has too much faith in my powers. I'd like to remind him that
I'm only Jesus, not the big guy himself.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Tuesday 02 January 2007 11:36, Ciaran McCreesh wrote:
> On Tue, 02 Jan 2007 18:28:05 +0200 Petteri Räty <betelgeuse@gentoo.org>
> | Well I was under the impression from zmedico that it completely works.
>
> zmedico has too much faith in my powers. I'd like to remind him that
> I'm only Jesus, not the big guy himself.

as long as you can turn water into fun, that's good enough for me
-mike

Ciaran McCreesh wrote:
> On Tue, 02 Jan 2007 18:28:05 +0200 Petteri Räty <betelgeuse@gentoo.org>
> wrote:
> | Well I was under the impression from zmedico that it completely works.
>
> zmedico has too much faith in my powers. I'd like to remind him that
> I'm only Jesus, not the big guy himself.
>

Is it me or is it getting a little stuffy in here? Can someone open a
window and let out some of Ciaran's ego?

--
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/


--
gentoo-dev@gentoo.org mailing list

On Wednesday 03 January 2007 01:26, Doug Goldstein wrote:
> Can someone open a window and let out some of Ciaran's ego?

then you'll let in the bees ;(
-mike

On Wed, 03 Jan 2007 01:26:03 -0500 Doug Goldstein <cardoe@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > On Tue, 02 Jan 2007 18:28:05 +0200 Petteri Räty
| > <betelgeuse@gentoo.org> wrote:
| > | Well I was under the impression from zmedico that it completely
| > | works.
| >
| > zmedico has too much faith in my powers. I'd like to remind him that
| > I'm only Jesus, not the big guy himself.
|
| Is it me or is it getting a little stuffy in here? Can someone open a
| window and let out some of Ciaran's ego?

Last time someone opened the window your sense of humour and ability to
recognise when someone is not being literal flew out. Wouldn't want a
repeat of that accident...

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Wed, 03 Jan 2007 22:07:54 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| Ciaran you're right in that it was obvious you were joking. I'd like
| to ask: did you implement this?

History of the die function, probably containing inaccuracies:

In the really early days, it was called 'try', and it was prefix. You'd
do things like:

try make

and it would either work or explode. Except if you tried to use
environment variables, or quoting, or anything like that, in which case
you'd encounter problems.

Then agriffis invented the original die, along with assert (which no-one
seems to use these days...). It avoided the quoting and environment
problems with try, and it was good. However, it doesn't work inside
subshells, which is only a mild annoyance so long as you know your
shell scripting (which most devs don't...).

Then along came eselect (or eclectic, as it was known back then), which
had a requirement for considerably more complex shell scripting than
your typical ebuild. In particular, we *had* to support die inside
various $( ) and ( ) constructs. Sooooo...

I came up with this really nasty hack of a die function that first
tries using signals and then falls back to the exit. It works in
subshells under certain circumstances, but not in others. It also
printed much nicer backtraces than the original ebuild style die.

When creating Paludis, I based assert and die upon the eselect code
rather than the Portage code (but with tweaks to make them ebuild
compatible). Those innovations (the way the function works, not
the exact code) have now made their way back into Portage.

The problem... is that most people don't realise a) when they're
triggering a subshell, b) how die works (read the source, it's about
twenty lines) or c) how unix signals work. This is why it's dangerous to
claim that "die now works inside subshells" -- yes, it does work,
*sometimes*, but because of all the limitations imposed by signals, it
cannot be considered a complete solution.

| One thing bothers me tho: you must have known that you'd get that
| kind of response by now, surely? For a start a lot of the gentoo
| crowd seem to be US citizens, and they're typically a hard crowd when
| you start taking the piss out of their religion. On top of that you
| seem to have fallen out with a lot of devs in the past. Although from
| the archives you have put in a sh*t load of work, and personally I
| have agreed with much of what you have said, and the way you have
| said it *in context*, you gotta be aware that kind of joke wouldn't
| go down well.

Oh, I dunno. Most people appreciate it. Those that don't need to remove
the sticks from their asses. They're the same kind that get upset when
someone says "Happy Christmas". Taking them seriously only adds to the
problem.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Wed, 03 Jan 2007 21:59:57 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| Ignoring the religious debate for a sec, can I just ask how this is
| being done? I thought an exit from a subshell took out the parent
| too, so I'm curious.

At the top level, we set an environment variable to the pid of the main
ebuild process. Then we install a signal trap handler, which, thanks to
how bash works, is allowed to exit the main process. Then we make die
first try to signal that trap handler, via kill (hence why we need the
main pid), and then fall back to an exit.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Wed, 03 Jan 2007 23:59:23 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| Ciaran McCreesh wrote:
| > At the top level, we set an environment variable to the pid of the
| > main ebuild process. Then we install a signal trap handler, which,
| > thanks to how bash works, is allowed to exit the main process. Then
| > we make die first try to signal that trap handler, via kill (hence
| > why we need the main pid), and then fall back to an exit.
|
| Wicked; was just re-reading about bash portability in the autobook:
| http://sources.redhat.com/autobook/autobook/autobook_210.html#SEC210
| Handy stuff to know if you don't already.

There is no portability. The trick will work in bash, and only in bash,
and only until upstream randomly changes something that breaks some
side effect of signal handling upon which we rely.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Thu, 04 Jan 2007 00:06:20 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| > The problem... is that most people don't realise a) when they're
| > triggering a subshell, b) how die works (read the source, it's about
| > twenty lines) or c) how unix signals work. This is why it's
| > dangerous to claim that "die now works inside subshells" -- yes, it
| > does work, *sometimes*, but because of all the limitations imposed
| > by signals, it cannot be considered a complete solution.
|
| Sorry, where is the source; which package and file?

Portage:

http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/ebuild.sh?view=markup

Portage, the old way:

http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/ebuild.sh?rev=5390&view=markup

Eselect:

http://sources.gentoo.org/viewcvs.py/eselect/trunk/bin/eselect.in?view=markup
http://sources.gentoo.org/viewcvs.py/eselect/trunk/libs/core.bash.in?view=markup

Paludis:

http://svn.pioto.org/viewvc/paludis/trunk/ebuild/ebuild.bash?view=markup

| I've read up a bit on signals- iirc they don't always get thru.

And they don't always get through quite when you'd expect them to
either.

| Can I ask you- have you got an entire system building in Paludis, and
| do others? How well does it run from an install?

Yupyup. Quite a few of us have been using it exclusively for a while
now. It'll work better off a fresh install than off a crufty old
install that's been around for zillions of years and has lots of broken
vdb entries created by old Portage versions...

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

Ignoring the religious debate for a sec, can I just ask how this is being
done? I thought an exit from a subshell took out the parent too, so I'm
curious.


--
gentoo-dev@gentoo.org mailing list

Ciaran McCreesh wrote:

> On Wed, 03 Jan 2007 01:26:03 -0500 Doug Goldstein <cardoe@gentoo.org>
> wrote:
> | Ciaran McCreesh wrote:
> | > On Tue, 02 Jan 2007 18:28:05 +0200 Petteri Räty
> | > <betelgeuse@gentoo.org> wrote:
> | > | Well I was under the impression from zmedico that it completely
> | > | works.
> | >
> | > zmedico has too much faith in my powers. I'd like to remind him that
> | > I'm only Jesus, not the big guy himself.
> |
> | Is it me or is it getting a little stuffy in here? Can someone open a
> | window and let out some of Ciaran's ego?
>
> Last time someone opened the window your sense of humour and ability to
> recognise when someone is not being literal flew out. Wouldn't want a
> repeat of that accident...
>
Ciaran you're right in that it was obvious you were joking. I'd like to ask:
did you implement this? If so, how (see my post above.)

One thing bothers me tho: you must have known that you'd get that kind of
response by now, surely? For a start a lot of the gentoo crowd seem to be
US citizens, and they're typically a hard crowd when you start taking the
piss out of their religion. On top of that you seem to have fallen out with
a lot of devs in the past. Although from the archives you have put in a
sh*t load of work, and personally I have agreed with much of what you have
said, and the way you have said it *in context*, you gotta be aware that
kind of joke wouldn't go down well.

Why do you put yourself there?


--
gentoo-dev@gentoo.org mailing list

Ciaran McCreesh wrote:
> At the top level, we set an environment variable to the pid of the main
> ebuild process. Then we install a signal trap handler, which, thanks to
> how bash works, is allowed to exit the main process. Then we make die
> first try to signal that trap handler, via kill (hence why we need the
> main pid), and then fall back to an exit.
>
Wicked; was just re-reading about bash portability in the autobook:
http://sources.redhat.com/autobook/autobook/autobook_210.html#SEC210
Handy stuff to know if you don't already.


--
gentoo-dev@gentoo.org mailing list

Ciaran McCreesh wrote:
> Then agriffis invented the original die, along with assert (which no-one
> seems to use these days...). It avoided the quoting and environment
> problems with try, and it was good. However, it doesn't work inside
> subshells, which is only a mild annoyance so long as you know your
> shell scripting (which most devs don't...).
>
assert is definitely useful (not only in ebuild context of course)

..
> The problem... is that most people don't realise a) when they're
> triggering a subshell, b) how die works (read the source, it's about
> twenty lines) or c) how unix signals work. This is why it's dangerous to
> claim that "die now works inside subshells" -- yes, it does work,
> *sometimes*, but because of all the limitations imposed by signals, it
> cannot be considered a complete solution.
>
Sorry, where is the source; which package and file?

I've read up a bit on signals- iirc they don't always get thru.

Can I ask you- have you got an entire system building in Paludis, and do
others? How well does it run from an install?

--
gentoo-dev@gentoo.org mailing list

Ciaran McCreesh wrote:

> On Wed, 03 Jan 2007 23:59:23 +0000 Steve Long
> <slong@rathaus.eclipse.co.uk> wrote:
> | Ciaran McCreesh wrote:
> | > At the top level, we set an environment variable to the pid of the
> | > main ebuild process. Then we install a signal trap handler, which,
> | > thanks to how bash works, is allowed to exit the main process. Then
> | > we make die first try to signal that trap handler, via kill (hence
> | > why we need the main pid), and then fall back to an exit.
> |
> | Wicked; was just re-reading about bash portability in the autobook:
> | http://sources.redhat.com/autobook/autobook/autobook_210.html#SEC210
> | Handy stuff to know if you don't already.
>
> There is no portability. The trick will work in bash, and only in bash,
> and only until upstream randomly changes something that breaks some
> side effect of signal handling upon which we rely.
>
I wasn't saying there was in this instance, I was just commenting that I
found the method interesting as I've been reading up on bash. Having said
that, it's good that you've let everyone know to be careful.


--
gentoo-dev@gentoo.org mailing list