Spawn independant bash shell?

[Mike Jones]

I need to spawn a bash shell, from a bash shell, that doesn't die when
the original is killed.

From an rxvt, call...

$> rxvt -e somescript.sh

...then kill the parent but leave the child running "somescript.sh"
independantly.

Clues?

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.

[Mike Jones]

Responding to Steve Ackman:

> In <pan.2009.11...@Arizona.Bay>, on Mon, 16 Nov 2009 00:14:31

> GMT, Mike Jones, N...@Arizona.Bay wrote:
>
>> I need to spawn a bash shell, from a bash shell, that doesn't die when
>> the original is killed.
>>
>> From an rxvt, call...
>>
>> $> rxvt -e somescript.sh
>>
>> ...then kill the parent but leave the child running "somescript.sh"
>> independantly.
>>
>> Clues?
>

> $ nohup rxvt -e somescript.sh

Nope. Kill parent, child dies.

Found this though...

$> rxvt -e somescript.sh &

...then, in the same spawning parent rxvt

$> disown -h

So, as a calling script (startsomescript.sh)...

# === Start somescript.sh === #
#!/bin/sh

rxvt -e somescript.sh &
disown -h &
# ==== as orphan process ==== #

This spawns a fresh independant "orphaned" somescript.sh job for each
activation of startsomescript.sh.

It reports "no such job" error but seems to work ok.

Now somebody tell me why this is a really bad idea. ;)

[Benny Nielsen]

Mike Jones wrote:

>
>
> I need to spawn a bash shell, from a bash shell, that doesn't die when
> the original is killed.
>
> From an rxvt, call...
>
> $> rxvt -e somescript.sh
>
> ...then kill the parent but leave the child running "somescript.sh"
> independantly.
>
> Clues?
>

You can use tcsh as the interpreter in the first script:

#!/bin/tcsh

second.sh&

Now second runs when first script exits

[Mike Jones]

Responding to Mike Jones:

Update:

# === Start somescript.sh === #
#!/bin/sh

rxvt -e somescript.sh &

sleep 2;
exit 0

# ==== as orphan process ==== #

...does the job, spawning another rxvt to do the job, and exiting the
parent gracefully without killing the child process.

Now I need to figure out how to do this via ssh from another machine, so
that once started, the ssh connection can be dropped.

The logical

ssh USER@ADDRESS COMMAND &

...only works while the ssh session is connected, even for a script that
calls another script on the target machine.

For some reason there is a difference between calling a binary, and
calling a bash script. If I can figure out what that is and account for
it, I can do spawning of independant scripted processes via ssh on a
remote machine.

[Mike Jones]

Responding to Steve Ackman:

> In <pan.2009.11...@Arizona.Bay>, on Mon, 16 Nov 2009 11:12:46

> GMT, Mike Jones, N...@Arizona.Bay wrote:
>> Responding to Steve Ackman:
>>
>>> In <pan.2009.11...@Arizona.Bay>, on Mon, 16 Nov 2009 00:14:31
>>> GMT, Mike Jones, N...@Arizona.Bay wrote:
>>>
>>>> I need to spawn a bash shell, from a bash shell, that doesn't die
>>>> when the original is killed.
>>>>
>>>> From an rxvt, call...
>>>>
>>>> $> rxvt -e somescript.sh
>>>>
>>>> ...then kill the parent but leave the child running "somescript.sh"
>>>> independantly.
>>>>
>>>> Clues?
>>>
>>> $ nohup rxvt -e somescript.sh
>>
>>
>> Nope. Kill parent, child dies.
>

> Right you are. Wrong assumptions and all that...
> something I *thought* I'd been making progress at. ;-)

# === Start somescript.sh === #
#!/bin/sh

rxvt -e somescript.sh &

sleep 2;
exit 0

# ==== as orphan process ==== #

...seems to work ok, but now I need to activate this through an ssh
connection. More fun! %)

[jellybean stonerfish]

On Mon, 16 Nov 2009 00:14:31 +0000, Mike Jones wrote:

> I need to spawn a bash shell, from a bash shell, that doesn't die when
> the original is killed.
>
> From an rxvt, call...
>
> $> rxvt -e somescript.sh
>
> ...then kill the parent but leave the child running "somescript.sh"
> independantly.
>
> Clues?

Does your target machine have 'screen'?

[Mike Jones]

Responding to jellybean stonerfish:

Already covered now.

The trick I needed was to sleep the parent script 2 before exiting.

Rough hack, yes, but it saved things tripping over each other, which
seemed to be the problem on this particular carpy MOBO. ;\

Cheers.