/usr/bin/script annoyance

[Dan Nelson <dnelson@emsphone.com>]

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