gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/25/89)
In article <165@apmpyr.nzapmb.co.nz> pgfdp@nzapmb.co.nz (Paul Fox ) writes: > 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)? The main problem you're likely to run into is that the System V sh has "echo" built in, with different semantics. In particular, echo 'main(){printf("Hello, world!\n");}' > foo.c doesn't do what you might expect. We tried the plug-replacement and found that it broke a 4.2BSD kernel makefile. You might consider getting the BRL-enhanced SVR2 Bourne shell, which has the added advantage of supporting job control, EMACS-style command history editing, etc. It can be configured in a number of ways, including 4.2BSD "echo" semantics, by simple edits in its Makefile.
pgfdp@nzapmb.co.nz (Paul Fox ) (01/25/89)
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...
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/03/89)
In article <165@apmpyr.nzapmb.co.nz> pgfdp@nzapmb.co.nz (Paul Fox ) writes: >... our development and our applications all run in the "ucb" universe.... >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. > >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)? This may actually work, if only because most of the shell scripts in BSD are pretty straight-forward. The differences in the System V shell I am aware of are: - test(1) is built in, and returns different values for directories. Since the System V test(1) returns values that are more correct than the BSD test(1), it seems unlikely that this would break anything. - Executable names are hashed. (The C-Shell does this too, although the im- plementation is quite different.) I've seen a number of cases where scripts that create executables and then invoke them work as expected on the old V7 shell, but get confused by the System V shell. There are a few scripts in OSx that are sensitive to this, though all of them I've seen explicitly invoke "#!/bin/att /bin/sh" to force them into the System V shell. - echo(1) is built in, and the semantics are different, per Doug Gwyn's note. This may actually cause some serious trouble for scripts that expect to be run interactively, or that try to get fancy with output formats. I can't think of any OSx scripts that would be sensitive to this. One thing I *would* expect to see get confused are "Configure" programs, that try to guess what system you are running on. Note that Larry Wall's Configure does not have this problem; it isn't surprised to see a System V shell on a Berkeley system, since Sun has been shipping that for years. FYI, if you are on OSx 4.0 or later, the att universe shell is SVR3.0. <csg>
dce@stan.UUCP (David Elliott) (02/04/89)
In article <57653@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >In article <165@apmpyr.nzapmb.co.nz> pgfdp@nzapmb.co.nz (Paul Fox ) writes: >>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)? > >This may actually work, if only because most of the shell scripts in BSD are >pretty straight-forward. The differences in the System V shell I am aware of >are: (differences deleted) There is one other item that bites people. The SVR2 shell added the ability to indent text read in using <<. That is, you can say cat <<-EOF data ... EOF and it works as if it were cat <<EOF data ... EOF The problem is that a number of users got into the habit of using termination strings beginning with -, as in cat <<-E-O-F- ... -E-O-F- This breaks without any kind of warning. It still boggles me as to why the implementors chose the legal '-' instead of an illegal character, such as '#'. -- David Elliott ...!pyramid!boulder!stan!dce
friedl@vsi.COM (Stephen J. Friedl) (02/05/89)
Carl Gutekunst writes: > > The differences in the System V shell I am aware of are: > > - test(1) is built in, and returns different values for directories. Since > the System V test(1) returns values that are more correct than the BSD > test(1), it seems unlikely that this would break anything. I'd like to expand on this a little. In the Sys V Rel 3 shell, test(1) uses stat(2) rather than access(2) to determine accessibility of the mentioned file (not just for directories). For shell scripts called from setuid/setgid systems, this difference is important (in your favor: SVR3 test is indeed "more correct" than the BSD version). Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for you only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl Nancy Reagan on these *stupid* .signatures: "Enough already, OK?"
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/06/89)
In article <1044@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >In the Sys V Rel 3 shell, test(1) uses stat(2) rather than access(2) to >determine accessibility of the mentioned file (not just for directories). Yup. Which is why directories in which you have permission to create new files return "writable" under SVR3 test(1) (seems obvious, doesn't it?), but direc- tories always return non-writable under BSD test(1). Proper suid behavior is nice, too, although I'd argue that suid shells are just too dangerous for most applications, especially when you have to be portable. <csg>
guy@auspex.UUCP (Guy Harris) (02/07/89)
>>In the Sys V Rel 3 shell, test(1) uses stat(2) rather than access(2) to >>determine accessibility of the mentioned file (not just for directories). > >Yup. Which is why directories in which you have permission to create new files >return "writable" under SVR3 test(1) (seems obvious, doesn't it?), but direc- >tories always return non-writable under BSD test(1). Well, actually, the BSD "test" uses "open" for the "-r" and "-w" tests, which is why it says that no directories are writable. Had it used "access", it would have reported that they're writable if the effective UID had write permission, as per the 4.3BSD ACCESS(2) (and probably as per other systems' ACCESS(2) as well): Notice that only access bits are checked. A directory may be indicated as writable by "access", but an attempt to open it for writing will fail (although files may be created there).... >Proper suid behavior is nice, too, Actually, since the BSD one uses "open", it gives proper SUID behavior as well.
consult@osiris.UUCP (Unix Consultation Mailbox ) (02/08/89)
In article <961@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >Had [BSD `test'] used >"access", it would have reported that they're writable if the effective >UID had write permission, as per the 4.3BSD ACCESS(2) My BSD (4.2, via Pyramid OSx 4.0) access uses only real uid, not effective uid. Has this really changed in 4.3? Phil Kos Information Systems ...!uunet!pyrdc!osiris!phil The Johns Hopkins Hospital Baltimore, MD
guy@auspex.UUCP (Guy Harris) (02/08/89)
>...Had it used "access", it would have reported that they're writable >if the effective UID had write permission, as per the 4.3BSD ACCESS(2) >(and probably as per other systems' ACCESS(2) as well):... Oops, sorry, make that "...if the *real* UID had write permission, as per...".