Xref: utzoo comp.sys.pyramid:302 comp.unix.wizards:14319
Path: utzoo!attcan!uunet!munnari!vuwcomp!apmpyr!pgfdp
From: pgfdp@nzapmb.co.nz (Paul Fox )
Newsgroups: comp.sys.pyramid,comp.unix.wizards
Subject: Is SVR2 /bin/sh backwards compatible to v7?
Message-ID: <165@apmpyr.nzapmb.co.nz>
Date: 24 Jan 89 23:25:28 GMT
Organization: NZ Apple and Pear Marketing Board, Wellington, NZ
Lines: 40



	We're running a Pyramid dual universe system (i.e. we have both
	the AT&T and the Berkeley worlds, complete and intact -- no
	modifications or enhancements to either).  For various reasons,
	our development and our applications all run in the "ucb" universe,
	so they see the Berkeley filesystem contents.  When writing
	shell scripts and makefiles, it would be nice if we could make use
	of the bug fixes and enhancements that have gone into /bin/sh since
	v7, that is, be able to run the AT&T /bin/sh instead of the UCB /bin/sh.
	(Examples:  shell functions, proper behaviour of failing "if" statements
	in makefiles)

	Of course, one can do this on a per-script basis with:
		#!/bin/att /bin/sh
	which flops you into the other universe before running the script.
	However, we don't usually want the universe to change.  So another
	method is:
		#!/.attbin/sh
	which gets us the AT&T executable in the current (UCB) universe.  That's
	okay (except for aesthetics), but it still doesn't fix the problem for
	make, which of course always invokes "/bin/sh" literally.

	Does anyone see a problem with simply _replacing_ the UCB /bin/sh
	(i.e. the one called /.ucbbin/sh) with the AT&T shell (the one
	called /.attbin/sh)?  Is the SVR2 shell sufficiently backwards
	compatible with the v7 (i.e. Berkeley) shell to allow this without
	breaking anything?  Offhand I can't think of anything that has
	been broken, but can anyone else?  We'll probably try it, but 
	could save some effort if forewarned of problems...

	thanks...

	Paul Fox, New Zealand Apple and Pear Marketing Board, Wellington, NZ
	pgfdp@apmpyr.nzapmb.co.nz


	p.s. If I'm wrong about the Berkeley /bin/sh being equivalent to the
	v7 /bin/sh, feel free to correct me, but only if you can also offer 
	some insight into my problem...