🚀 go-pugleaf

in article <3865@umbc3.UMBC.EDU>, rouben@math13.math.umbc.edu says:
> -rwxr-xr-x  1 root     system      45056 Apr  1 12:27 /bin/sh
> -rwxr-xr-x  2 root     system     163840 Apr  1 09:56 /usr/bin/sh5

Well, that's amusing. Try:

-rwxr-xr-x  1 root        23552 Nov 19  1987 /bin/sh*
-rwxr-xr-x  1 root        39936 Nov 18  1987 /usr/bin/sh5*

on Ultrix V2.2 Worksystem 1.1 (I forget what model CPU).
-- 
BURNS,JIM
Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
Internet: gt0178a@prism.gatech.edu

>So the executable for sh5 is more than three times larger than that
>of sh.  For quick execution of simple tasks there is a sense of 
>overkill in using sh5.  I guess that's the reason that the folks at
>DEC have not replaced sh with sh5.

I tend to be leery of guesses, perhaps because there may be more than
one possible answer to the question to which you're guessing the answer.
One alternative answer is that they're afraid putting in an S5 shell -
even with changes to make it more V7/BSD-flavored, such as changing the
behavior of "echo" - might break some V7/BSD shell scripts.

Sun took the alternate tack, in SunOS 3.0 (yes, 3.0, not 3.2; it wasn't
done as part of the big S5 compatibility push, it was done to add in the
functionality and bug fixes of the S5R2 shell), by making the
aforementioned changes and making an S5R2-based shell "/bin/sh".  (The
change in 3.2 was to make it act as if it were picking up builtins such
as "echo" and "test"/"[" as programs, based on PATH, so that the
behavior of those builtins depended on whether "/usr/5bin" came before
"/bin" or "/usr/bin" in PATH.)

For comparison, here are the sizes of the 4.3BSD shell source, compiled
on a Sun-4 running 4.0.3 (after fixing the "old-style" initializations
that the SunOS 4.x C compilers no longer accept) and "/usr/bin/sh". 
Both are statically linked, and both are compiled with "-O":

	auspex% size ./sh /usr/bin/sh
	text    data    bss     dec     hex
	40960   8192    0       49152   c000    ./sh
	90112   8192    3160    101464  18c58   /usr/bin/sh

so the code slightly more than doubles in size, but not triples.  I have
no problem with doubling the size of the code, if it means I don't have
to write "least common denominator" shell scripts and don't have to
stick something gross and OS-dependent such as "#! /usr/bin/sh5" at the
front of the script. 

In article <3865@umbc3.UMBC.EDU> rouben@math13.math.umbc.edu writes:

| In a previous article Michael Meissner writes:
| >> How common are sh's that don't understand shell functions?
| >
| > Anything that is BSD based without adding from System V.  For example,
| > the Ultrix DECstation that I'm posting from has the musty BSD shell as
| > /bin/sh and the System V.2 shell with shell functions as /bin/sh5.
| > Another problem with the BSD shell Ultrix uses, is that test (aka '[')
| > is a separate command that you have to fork/exec to get to -- I
| > suspect echo is too.....
| 
| In spite of its shortcommings, ultrix's BSD sh beats sh5 in terms of 
| efficiency.  On a DECstation5000, we have:
| ls -l  /bin/sh  /usr/bin/sh5
| 
| -rwxr-xr-x  1 root     system      45056 Apr  1 12:27 /bin/sh
| -rwxr-xr-x  2 root     system     163840 Apr  1 09:56 /usr/bin/sh5
| 
| So the executable for sh5 is more than three times larger than that
| of sh.  For quick execution of simple tasks there is a sense of 
| overkill in using sh5.  I guess that's the reason that the folks at
| DEC have not replaced sh with sh5.

Just about every 'simple' shell script that I have uses test and/or
echo.  If there are any savings in the V7 shell, they just got lost by
having to do a fork/exec combination.  Also, I remember that when V.2
came out, people measured the 'new' shell with the V.1 shell which was
more or less the V7 shell, and found by doing a reimplementation, it
made the 'new' shell much faster.  I don't remember the numbers, but
it was something like 20% faster, even after factoring out the
builtins.

I finally sovled the problem Guy Harris mentioned in another article
(ie, do you gunk up your shell scripts with #! /bin/sh5 and make them
completely non-portable), by noticing that for the machines I care
about, the Korn Shell was installed in /usr/bin, so I now tend to use
#! /us/bin/ksh, which is still a kludge.

I happen to think that System V integration was real low priority on
Ultrix.  All you have to do is look at how they botched curses
(requiring you to change the source to include cursesX.h instead of
curses.h).  Sun did a much better job of mixing the two.



--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Do apple growers tell their kids money doesn't grow on bushes?

In article <MEISSNER.90Sep3231422@osf.osf.org>,
meissner@osf.org (Michael Meissner) writes...
# I happen to think that System V integration was real low priority on
# Ultrix.  All you have to do is look at how they botched curses
# (requiring you to change the source to include cursesX.h instead of
# curses.h).  Sun did a much better job of mixing the two.

As far as that goes, HP did an even better job than Sun.  And Pyramid
did a better job that ANYBODY.  But why does anybody care about System V?

(Not speaking for DEC -- we seem to care about System V...)
--
Paul Vixie
DEC Western Research Lab	<vixie@wrl.dec.com>
Palo Alto, California		...!decwrl!vixie

In article <3865@umbc3.UMBC.EDU> rouben@math13.math.umbc.edu writes:
>-rwxr-xr-x  1 root     system      45056 Apr  1 12:27 /bin/sh
>-rwxr-xr-x  2 root     system     163840 Apr  1 09:56 /usr/bin/sh5
>
>So the executable for sh5 is more than three times larger than that
>of sh.  For quick execution of simple tasks there is a sense of 
>overkill in using sh5.  I guess that's the reason that the folks at
>DEC have not replaced sh with sh5.

Huh? On our VAX6210 running Ultrix 3.1:

-rwxr-xr-x  1 root        23552 Jan 11  1989 /bin/sh
-rwxr-xr-x  1 root        44032 Jan 11  1989 /bin/sh5

That's not even twice the size!

I suspect that on your machine, sh is stripped, and sh5 is not.

And SOME increase in size is almost necessary for an increase in
functionality :-) ...
-- 
Wolf N. Paul, IIASA, A - 2361 Laxenburg, Austria, Europe
PHONE: +43-2236-71521-465     FAX: +43-2236-71313      UUCP: uunet!iiasa.at!wnp
INTERNET: wnp%iiasa.at@uunet.uu.net      BITNET: tuvie!iiasa!wnp@awiuni01.BITNET
       * * * * Kurt Waldheim for President (of Mars, of course!) * * * *

In article <1990Sep4.063729.27822@wrl.dec.com> vixie@wrl.dec.com (Paul
Vixie) writes:

| In article <MEISSNER.90Sep3231422@osf.osf.org>,
| meissner@osf.org (Michael Meissner) writes...
| # I happen to think that System V integration was real low priority on
| # Ultrix.  All you have to do is look at how they botched curses
| # (requiring you to change the source to include cursesX.h instead of
| # curses.h).  Sun did a much better job of mixing the two.
| 
| As far as that goes, HP did an even better job than Sun.  And Pyramid
| did a better job that ANYBODY.  But why does anybody care about System V?
| 
| (Not speaking for DEC -- we seem to care about System V...)

Because each of the various UNIX camps have good things to offer (such
as the V.2 /bin/sh and curses in the System V case).

IMHO, I think Pyramid's solution (separate att/ucb universes) is the
wrong solution.  I want a merged system, not two systems under the
same roof......
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Do apple growers tell their kids money doesn't grow on bushes?

In article <13289@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes:
>in article <3865@umbc3.UMBC.EDU>, rouben@math13.math.umbc.edu says:
>> -rwxr-xr-x  1 root     system      45056 Apr  1 12:27 /bin/sh
>> -rwxr-xr-x  2 root     system     163840 Apr  1 09:56 /usr/bin/sh5
>
>Well, that's amusing. Try:
>
>-rwxr-xr-x  1 root        23552 Nov 19  1987 /bin/sh*
>-rwxr-xr-x  1 root        39936 Nov 18  1987 /usr/bin/sh5*


     ls -l is pretty useless on executables. What if one executable had its
symbol table stripped, and the other one didn't????

     Try size(1) instead. It has more meaningful output....

text	data	bss	dec	hex
90112	8192	3112	101416	18c28		/bin/sh.bsd

92176   8528    7652    108356  1a744		/bin/shs.sysv

     And here's the ls -l output:

-r-xr-xr-x   1 bin      root      101216 Jun 20 15:25 /bin/sh.sysv
-rwxr-xr-x   1 root     other     133120 Feb 20  1990 /bin/sh.bsd

     Note that the bsd sh is actually smaller according to size(1), but ls -l
shows it is bigger, due to the symbol table.....

In article <1990Sep4.063729.27822@wrl.dec.com> vixie@wrl.dec.com (Paul Vixie) writes:
#In article <MEISSNER.90Sep3231422@osf.osf.org>,
#meissner@osf.org (Michael Meissner) writes...
## I happen to think that System V integration was real low priority on
## Ultrix.  All you have to do is look at how they botched curses
## (requiring you to change the source to include cursesX.h instead of
## curses.h).  Sun did a much better job of mixing the two.
#
#As far as that goes, HP did an even better job than Sun.  And Pyramid
#did a better job that ANYBODY.  But why does anybody care about System V?
#

Well, HP actually started with System V and mixed in BSD...


	Jan D.