6.28. Bash-3.2 and exec /bin/bash --login +h
dbn.lists at gmail.com
Sun Sep 2 09:42:19 PDT 2007
On 9/2/07, Trent Shea <tjshea at telus.net> wrote:
> On Sunday 02 September 2007 08:45, Dan Nicholson wrote:
> > It depends what you do with your script and if you keep some kind of
> > progress marker so that the newly invoked script knows where to pick
> > up.
> That's going to be the tricky part. The only ideas I've had so far are:
> 1. Somehow pause the script, pass control of it to the new shell
> (fiddling around with the PID and PPID), and resume the script in the
> new bash. I have a feeling that this may seem sensible to me now, but
> the reality is going to be anything but.
> 2. As you said, some kind of marker to begin execution at the proper
> point when the script is re-invoked; also fun.
Neither one would be that fun in practice, but I could be a good
exercise. 2. is a little more sensible to me, but only because I know
of a very simple way to create the markers.
if [ ! -f $stampdir/$package ]; then
# build $package
Then when the new script started, it would just walk over all the old
cases because the stamp file already existed. You could do something
fancier, too, like putting the version number in the stamp file and
reading it later so you can tell if an update is needed. But that's
More information about the lfs-support