Simple way to get parent process name?

Simple way to get parent process name?

[Ken Lareau]

At my current job I compile a lot of various packages, and tend to log
my configuration, compilation and installation procedures for future
reference, using the 'script' command.  To keep myself from getting con-
fused as to whether I was in a 'script' process or not, I would have the
shell prompt change to something else while running 'script'.

In ksh, I'd found no easier way to do this other than:

  ppid() { /bin/ps -o ppid -p $1 | tail -1; };
  pname () { /bin/ps -o comm -p $1 | tail -1; };

for functions to get the PPID and the name, and then testing

  $(pname $(ppid $$))

to see if it was equal to 'script'.  For Solaris 5.4, the two previous
functions were even worse:

  ppid() { /bin/ps -lp $1 | tail -1 | tr -s ' ' | cut -c2- | cut -d' ' -f5; };
  pname() { /bin/ps -p $1 | tail -1 | tr -s ' ' | cut -c2- | cut -d' ' -f4; };

So my question is, now that I'm using zsh as my shell at work, is there
a simpler way to do this?  I know zsh has PPID, but I need the actual
process name as well.

Any suggestions?


Ken Lareau
elessar@numenor.org

Re: Simple way to get parent process name?

[Dan Nelson]

In the last episode (Sep 15), Ken Lareau said:
> At my current job I compile a lot of various packages, and tend to
> log my configuration, compilation and installation procedures for
> future reference, using the 'script' command.  To keep myself from
> getting confused as to whether I was in a 'script' process or not, I
> would have the shell prompt change to something else while running
> 'script'.

How about

script () { 
  export INSCRIPT 
  (( INSCRIPT ++ )) 
  command script "$@"
  (( INSCRIPT -- ))
}

then when you set your prompt, test to see if $INSCRIPT is > 0.

There's no portable way to find the parent's process name, as far as I
know.

	-Dan Nelson
	dnelson@emsphone.com

Re: Simple way to get parent process name?

[Ken Lareau]

In message <19980915151323.A5205@emsphone.com>, Dan Nelson writes:
>In the last episode (Sep 15), Ken Lareau said:
>> At my current job I compile a lot of various packages, and tend to
>> log my configuration, compilation and installation procedures for
>> future reference, using the 'script' command.  To keep myself from
>> getting confused as to whether I was in a 'script' process or not, I
>> would have the shell prompt change to something else while running
>> 'script'.
>
>How about
>
>script () { 
>  export INSCRIPT 
>  (( INSCRIPT ++ )) 
>  command script "$@"
>  (( INSCRIPT -- ))
>}
>
>then when you set your prompt, test to see if $INSCRIPT is > 0.

Thanks for the response; however, a more insidious problem has reared
it's head: both the above and my former method (modified to zsh, of
course) does not work, since the forking of a subshell doesn't reread
the startup scripts when 'script' is executed.

I have been unsuccessful in figuring out why this seems to happen, as
the documentation I've read doesn't give a clue... anyone have any 
ideas on how to get around this little problem?


Ken Lareau
elessar@numenor.org

/usr/bin/script annoyance

[Dan Nelson]

In the last episode (Sep 16), Ken Lareau said:
> Thanks for the response; however, a more insidious problem has reared
> it's head: both the above and my former method (modified to zsh, of
> course) does not work, since the forking of a subshell doesn't reread
> the startup scripts when 'script' is executed.
> 
> I have been unsuccessful in figuring out why this seems to happen, as
> the documentation I've read doesn't give a clue... anyone have any
> ideas on how to get around this little problem?

I've noticed this too.  zsh-3.0.5 does not source _any_ startup scripts
inside a 'script' run on the following OS's: FreeBSD 2.2, SCO 5.0.4,
OSF/1 4.0, SunOS 4.1.  It _does_ source startup scripts under Linux (RH
4.2).

Oh weird.  I just looked at the source to typescript under FreeBSD, and
it reads in part:

	char *shell;

	shell = getenv("SHELL");
	if (shell == NULL)
		shell = _PATH_BSHELL;

	execl(shell, "sh", "-i", NULL);

So argv[0] is "sh", and it's entering /bin/sh compatibility mode.  This
is almost _exactly_ the problem Paul Lew reported to the zsh list on
Aug 11 (mailinglist article archive/latest/4298).  Both Bart Schaefer
and zefram posted ugly workarounds :)

I checked the whole FreeBSD source tree, and this is the only place
that exec(zzz, "sh") was called where zzz was not "/bin/sh" or
_PATH_BSHELL.  I guess this does count as a /usr/bin/script bug, but
every OS (besides Linux) exhibits the same weird behaviour, and it's
sort of hard to change the SCO, OSF, and SunOs binaries.

	-Dan Nelson
	dnelson@emsphone.com

Re: /usr/bin/script annoyance

[Ken Lareau]

In message <19980916110804.A19057@emsphone.com>, Dan Nelson writes:
>In the last episode (Sep 16), Ken Lareau said:
>> Thanks for the response; however, a more insidious problem has reared
>> it's head: both the above and my former method (modified to zsh, of
>> course) does not work, since the forking of a subshell doesn't reread
>> the startup scripts when 'script' is executed.
>> 
>> I have been unsuccessful in figuring out why this seems to happen, as
>> the documentation I've read doesn't give a clue... anyone have any
>> ideas on how to get around this little problem?
>
>I've noticed this too.  zsh-3.0.5 does not source _any_ startup scripts
>inside a 'script' run on the following OS's: FreeBSD 2.2, SCO 5.0.4,
>OSF/1 4.0, SunOS 4.1.  It _does_ source startup scripts under Linux (RH
>4.2).

I happen to be using zsh 3.1.4, actually, but I'm sure the code is
similar enough in this case...

>Oh weird.  I just looked at the source to typescript under FreeBSD, and
>it reads in part:
>
>	char *shell;
>
>	shell = getenv("SHELL");
>	if (shell == NULL)
>		shell = _PATH_BSHELL;
>
>	execl(shell, "sh", "-i", NULL);
>
>So argv[0] is "sh", and it's entering /bin/sh compatibility mode.  This
>is almost _exactly_ the problem Paul Lew reported to the zsh list on
>Aug 11 (mailinglist article archive/latest/4298).  Both Bart Schaefer
>and zefram posted ugly workarounds :)

Hmm... I did a 'truss' on the 'script <file>' command and dumped it to
a file, and here's what I see when it calls the shell:

  execve("/software/bin/zsh", 0xEFFFF918, 0xEFFFFA60)  argc = 2

Of course I have no idea what the 2nd and 3rd arguments are to the
execve command, but it would seem to me that it should start up as
a regular zsh shell, no?  (Please tell me if I'm missing something
blatently obvious here.)


Ken Lareau
elessar@numenor.org

Re: /usr/bin/script annoyance

[Dan Nelson]

In the last episode (Sep 16), Ken Lareau said:
>> Oh weird.  I just looked at the source to typescript under FreeBSD,
>> and it reads in part:
>>
>>	char *shell;
>>
>>	shell = getenv("SHELL");
>>	if (shell == NULL)
>>		shell = _PATH_BSHELL;
>>
>>	execl(shell, "sh", "-i", NULL);
>>
>> So argv[0] is "sh", and it's entering /bin/sh compatibility mode. 
>> This is almost _exactly_ the problem Paul Lew reported to the zsh
>> list on Aug 11 (mailinglist article archive/latest/4298).  Both Bart
>> Schaefer and zefram posted ugly workarounds :)
> 
> Hmm... I did a 'truss' on the 'script <file>' command and dumped it
> to a file, and here's what I see when it calls the shell:
> 
>   execve("/software/bin/zsh", 0xEFFFF918, 0xEFFFFA60)  argc = 2
> 
> Of course I have no idea what the 2nd and 3rd arguments are to the
> execve command, but it would seem to me that it should start up as a
> regular zsh shell, no?  (Please tell me if I'm missing something
> blatently obvious here.)

The prototype for the execve syscall is usually

execve(const char *path, char *const argv[], char *const envp[])

and the string that determines sh compatibility mode for zsh is not
'path', but 'argv[0]'.  If you were to run script under dbx and break
on the execve call, I'd bet anything that the contents of the string at
0xEFFFF918 is "sh".

Zefram's solution to this problem is the shortest:

> Alternatively, set your SHELL to be the executable of this program:
>
>        extern char **environ;
>        int main(int argc, char **argv)
>        {
>            if(argc != 0)
>                argv[0] = "zsh";
>            execve("/usr/local/bin/zsh", argv, environ);
>            _exit(1);
>        }

That'll guarantee that zsh gets called as "zsh".

	-Dan Nelson
	dnelson@emsphone.com

Re: /usr/bin/script annoyance

[Ken Lareau]

In message <19980916114138.A23822@emsphone.com>, Dan Nelson writes:
>The prototype for the execve syscall is usually
>
>execve(const char *path, char *const argv[], char *const envp[])
>
>and the string that determines sh compatibility mode for zsh is not
>'path', but 'argv[0]'.  If you were to run script under dbx and break
>on the execve call, I'd bet anything that the contents of the string at
>0xEFFFF918 is "sh".

That would make sense, lucky me. :)

>Zefram's solution to this problem is the shortest:
>
>> Alternatively, set your SHELL to be the executable of this program:
>>
>>        extern char **environ;
>>        int main(int argc, char **argv)
>>        {
>>            if(argc != 0)
>>                argv[0] = "zsh";
>>            execve("/usr/local/bin/zsh", argv, environ);
>>            _exit(1);
>>        }
>
>That'll guarantee that zsh gets called as "zsh".

I did this, and thankfully, it worked.  Really screwed up way to do it,
but it works. :)  Thanks for the help, it was greatly appreciated.

Of course, this brings up one more question... is this something that
can be fixed eventually in zsh?


Ken Lareau
elessar@numenor.org

Re: /usr/bin/script annoyance

[Ken Lareau]

In message <199809161653.MAA06850@mailhost2.squonk.net>, Ken Lareau writes:
>
>[program set to SHELL for 'script' process working]
>
>Of course, this brings up one more question... is this something that
>can be fixed eventually in zsh?

Okay, that wasn't a bright thing to say, as I realized it was probably
script's fault, not zsh's.  Sure enough, a truss on the script process
(with a few extra options) shows that argv is set to 'sh -i'.  Time to
talk to Sun, it seems.

Sorry about that.


Ken Lareau
elessar@numenor.org

Re: /usr/bin/script annoyance

[Bart Schaefer]

On Sep 16, 12:53pm, Ken Lareau wrote:
} Subject: Re: /usr/bin/script annoyance
}
} In message <19980916114138.A23822@emsphone.com>, Dan Nelson writes:
} >Zefram's solution to this problem is the shortest:
} >> Alternatively, set your SHELL to be the executable of this program:
} >>
} >>        extern char **environ;
} >>        int main(int argc, char **argv)
} >>        {
} >>            if(argc != 0)
} >>                argv[0] = "zsh";
} >>            execve("/usr/local/bin/zsh", argv, environ);
} >>            _exit(1);
} >>        }

It might be better like this:

    main(int argc, char **argv, char **envp)
    {
      if (argc > 0)
	argv[0] = (**argv == '-') ? "-zsh" : "zsh";
      execve("/usr/local/bin/zsh", argv, envp);
      _exit(1);
    }

That handles login shells, which Zefram's doesn't.

} Of course, this brings up one more question... is this something that
} can be fixed eventually in zsh?

The only reasonable runtime fix I can think of would be an environment
variable to specify the emulation mode, which would take precedence over
argv[0].  That would potentially also solve the argv[0]="su" problem for
which I posted a patch some months ago.

An option to compile out argv[0]-based emulation would be possible, but
didn't receive an enthusiastic response the last time it was suggested.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com