Re: [osol-discuss] Weird bash behaviour

2010-02-02 Thread Henrik
The shell forks, and the child process tries to execute child.sh using execve(). If this succeeds, the arguments you see in ptree show the child script. If it fails (because there is no #! line), the child process interprets the script, but the process args still match those of the

Re: [osol-discuss] Weird bash behaviour

2010-02-02 Thread Joerg Schilling
Henrik henrik.lyngga...@gmail.com wrote: Why doesn't the child process change the process name after the failed execve() ? is it just history or is this a feature ? The process name cannot be changed. THe only way is to create a new process with a new name. You can change argv[] for a

[osol-discuss] Weird bash behaviour

2010-02-01 Thread Henrik
Hi I have seen a weird behaviour from bash both under Solaris and Linux, most likely it is a feature but I can't seem to find the answer with google :-\ I have two scripts test.sh: #!/usr/bin/bash echo parent ./child.sh sleep 120 child.sh: echo child sleep 120 If I run the two scripts like

Re: [osol-discuss] Weird bash behaviour

2010-02-01 Thread Edward Ned Harvey
test.sh: #!/usr/bin/bash echo parent ./child.sh sleep 120 child.sh: echo child sleep 120 If you omit the #!/bin/bash from child.sh, I suspect the original bash will look at the file, recognize it's executable, but since the file doesn't specify a new command interpreter, it's

Re: [osol-discuss] Weird bash behaviour

2010-02-01 Thread Henrik
If you omit the #!/bin/bash from child.sh, I suspect the original bash will look at the file, recognize it's executable, but since the file doesn't specify a new command interpreter, it's equivalent to . ./child.sh meaning the parent script simply sources the child script. Not in a new

Re: [osol-discuss] Weird bash behaviour

2010-02-01 Thread Scott Rotondo
Henrik wrote: If you omit the #!/bin/bash from child.sh, I suspect the original bash will look at the file, recognize it's executable, but since the file doesn't specify a new command interpreter, it's equivalent to . ./child.sh meaning the parent script simply sources the child script. Not in