🚀 go-pugleaf

lvc@cbnews.att.com (Lawrence V. Cipriani) wrote:
> ksh 11/16/88e is now available in the AT&T Toolchest; there is a $150
> upgrade for previous purchasers.  Regarding HP-UX 7, this ksh compiles
> and passes regression tests under that OS.

What's the story with SunOS 4.1?  We are upgrading to that from 4.0.? and
our version of ksh doesn't work under that.  Does this one?

-- 
--  Jack Campin   Computing Science Department, Glasgow University, 17 Lilybank
Gardens, Glasgow G12 8QQ, Scotland   041 339 8855 x6044 work  041 556 1878 home
JANET: jack@cs.glasgow.ac.uk    BANG!net: via mcsun and ukc   FAX: 041 330 4913
INTERNET: via nsfnet-relay.ac.uk   BITNET: via UKACRL   UUCP: jack@glasgow.uucp

In article <6432@vanuata.cs.glasgow.ac.uk> jack@cs.glasgow.ac.uk (Jack Campin) writes:

| What's the story with SunOS 4.1?  We are upgrading to that from 4.0.? and
| our version of ksh doesn't work under that.  Does this one?

  I got 88d working nicely under SunOS 4.1 on Sun4s. I'm not sure what I
did, nothing fancy I'm sure.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

In article <6432@vanuata.cs.glasgow.ac.uk>, jack@cs.glasgow.ac.uk (Jack Campin) writes:
> 
> What's the story with SunOS 4.1?  We are upgrading to that from 4.0.? and
> our version of ksh doesn't work under that.  Does this one?

Don't know, but ksh88 has been compiled and beta tested on the following
systems.  An asterisk signifies that ksh has been installed as /bin/sh on
this machine.

*    System V Release  2, 3, & 4 on AT&T 3B's.
*    System V Release 2 on UNIX-PC.
*    System V Release 3.[12] on AT&T 6386.
     System V Release 2 on Vaxen.
     System V Release 2 on Amdahl UTS.
*    System V Release 3 on Counterpoint CP-19.
*    BSD 4.3 on Vax 8650
*    BSD 4.3 on CCI.
     Version 9 on Vax 785.
*    Sun 3.5 on Sun 3's.
*    Sun 4.0 on Sun 3's and Sun 4's.
     Sun 4.0 on Sun 386-i.
     Unicos on Cray-2.
     UNIX on Masscomp 5400 in ucb universe.
     HP/UX 2.0 on HP-9000.
     Ultrix 2.0 on Microvax.
     Domain/IX on Apollo 3000.
     Custonmuix 4.1 on Alliant.
     UIMPS 3.1 on a MIPS 120-5
     5.0 on a Pyramid in ucb universe.
-- 
Larry Cipriani, att!cbdkc1!larry or larry@cbdkc1.att.com
             "Save a logger, eat an owl"

In article <1990Sep28.205053.16456@cbnews.att.com> lvc@cbnews.att.com
(Lawrence V. Cipriani) writes:

   ksh 11/16/88e is now available in the AT&T Toolchest; there
   is a $150 upgrade for previous purchasers.

   [rest of yucky advertising deleted]

   Okay, okay, this is a blatant advertisment!  What of it!?

There are several things wrong with this blatant advertisement:

	1) It has always been frowned upon to post ads to regular
	groups, and some people are actively hostile to it.  Most
	netters try to be more objective about mentioning products, so
	that even if they talk about their own product, they mention
	pros and cons WRT other products.

	2) The ksh is a miserable piece of junk, when compared to the
	GNU superset shell, BASH (which supports ksh-like vi-type
	editing, and built-in help, among other things).  GNU is free,
	with modifiable source; ksh costs money.

	3) People don't want junk postings any more than they want
	junk mail.  There is a newsgroup for this stuff, you know.
	I'll let you read news.announce.NEWUSERS to find out what it
	is.

Please refrain from this in the future.
--
Mark Towfigh, Racal InterLan, Inc.                 towfiq@interlan.Interlan.COM
W: (508) 263-9929 H: (617) 488-2818                       uunet!interlan!towfiq

  "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah

In article <TOWFIQ.90Oct2112703@lcxserver.InterLan.COM> towfiq@interlan.Interlan.COM (Mark Towfiq) writes:
>	2) The ksh is a miserable piece of junk, when compared to the
>	GNU superset shell, BASH (which supports ksh-like vi-type
>	editing, and built-in help, among other things).  GNU is free,
>	with modifiable source; ksh costs $150.

OK...so it's not OK to blatantly advertise commercial products, but it's OK to
blatantly advertise the soi-disant Free Software Foundation's products. I get
it now.

GNU stuff is *not* free. It costs something other than money, though: it costs
your freedom to do as you like with your code if you include even a line of
their code. $150 sure sounds cheap by comparison.

-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@thesis1.hsch.utexas.edu  | adequately be explained by stupidity.
"It's a hardware bug!" "It's a    +---------------------------------------
software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_

towfiq@interlan.Interlan.COM (Mark Towfiq) writes:

>	3) People don't want junk postings any more than they want
>	junk mail.  There is a newsgroup for this stuff, you know.
>	I'll let you read news.announce.NEWUSERS to find out what it
>	is.
>
>Please refrain from this in the future.

Please speak for yourself.  I found this a valuable posting as we have been
waiting some time for ksh88e to be released.  

/pbp
--
         Paul Pomes

UUCP: {att,iuvax,uunet}!uiucuxc!paul   Internet, BITNET: paul@uxc.cso.uiuc.edu
US Mail:  UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801-2910

In article <4140@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
>
>OK...so it's not OK to blatantly advertise commercial products, but it's OK to
>blatantly advertise the soi-disant Free Software Foundation's products. I get
>it now.

That's right.  In the former case, a comercial entity gains advantage
at the expense of the USENET community.  In the latter, everyone
benefits and no profits are made at the expense of others.

>GNU stuff is *not* free. It costs something other than money, though: it costs
>your freedom to do as you like with your code if you include even a line of
>their code. $150 sure sounds cheap by comparison.

Yes, their are restrictions on what you can do with *their*
code--you're free to do whatever you want with your own code--but
isn't that only fair?  And there is absolutely no reason why one would
need to include a modified bash in their product, so the fear of it
causing you to give your precious code away is baseless.

-- 
Dave Sill (de5@ornl.gov)
Martin Marietta Energy Systems
Workstation Support

In article <4140@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
   GNU stuff is *not* free. It costs something other than money, though: it costs
   your freedom to do as you like with your code if you include even a line of
   their code. $150 sure sounds cheap by comparison.

Wait a minute.  Engage brain before fingers.  Just how much do you
think it will cost you if you include any AT&T code in your product?
Especially if you don't ask them about it first.  Lawyers ain't
exactly cheap.

I believe that the statement is:  the GNU stuff doesn't cost you
anything to install.  The AT&T stuff costs bucks and "doesn't work as
well"  (no comment on that last since I run the GNU stuff and haven't
tried the AT&T stuff in ages).
-- 
Rich Kaul                         | It wouldn't be research if we
kaul@icarus.eng.ohio-state.edu    | knew what we were doing.

lvc@cbnews.att.com (Lawrence V. Cipriani) writes:

>ksh 11/16/88e is now available in the AT&T Toolchest; there
>is a $150 upgrade for previous purchasers.

Not quite, though I wish it were so. Checking the Toolchest board I find
that those licensed to the older 1986 version of ksh-i or the even earlier
ksh can update for $1,650 plus transmission costs. Those licensed to the
earlier ksh-88 can update for $150 plus transmission costs. [Of course,
if Lawrence considered only these latter to be "previous purchasers",
consider this a clarification.]

In article <4140@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
   GNU stuff is *not* free. It costs something other than money, though: it costs
   your freedom to do as you like with your code if you include even a line of
   their code. $150 sure sounds cheap by comparison.

Just out of curiosity, when did AT&T start allowing people to freely
redistribute their code if it's part of a derived work? At least,
you're implying that I'm free to do what I want with my code if it
includes AT&T's code, which generally includes redistribution.

	<mike
--
How many times do you have to fall			Mike Meyer
While people stand there gawking?			mwm@relay.pa.dec.com
How many times do you have to fall			decwrl!mwm
Before you end up walking?

Jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
>
>GNU stuff is *not* free. It costs something other than money, though: it costs
>your freedom to do as you like with your code if you include even a line of
>their code. $150 sure sounds cheap by comparison.

Whether or not you agree with the GNU philosophy, it just doesn't
make sense to sneer at the countless man-hours they have put
into their fine products - and this basically either for altruistic
reasons, devotion to a non self-serving cause, or else for the pure
love of their work.

If you think that this is worse than commercialism, and ought to
be banned from the net, then it looks - at least to me - as though
your value-system is upside down.

-Richard

Let me get this right, it's okay for Larry Wall to post announcements
about the availability of perl in comp.lang.perl but it's not okay
to announce the availability of ksh in comp.lang.shell?  Right, you
guys are just too much.  Wall benefits financially, albeit indirectly,
from his work on perl; likewise for Korn.  What's the difference?
None, except Korn is employed privately whereas Wall is employed by
the US federal gov't.  If anyone thinks there is a difference between
AT&T and the US federal gov't benefitting from their employees work
I'm gonna puke.

Also, I have seen far too many posts asking "What is the latest ksh
and where can I get it?"  I am tired of seeing them[!], my post will
help put an end to it.  I will continue to post announcements of ksh
availability here.

Till next time ...
-- 
Larry Cipriani, att!cbvox!lvc or lvc@cbvox.att.com
           "Save a logger, eat an owl"

In article <TOWFIQ.90Oct2112740@lcxserver.InterLan.COM> towfiq@interlan.Interlan.COM (Mark Towfiq) writes:

=> 	2) The ksh is a miserable piece of junk, when compared to the
=> 	GNU superset shell, BASH (which supports ksh-like vi-type
=> 	editing, and built-in help, among other things).  GNU is free,
=> 	with modifiable source; ksh costs money.

BASH is great, it dumps core and has clear documentation.

--
..............................................................................
: Ari Suntioinen -- aps@tut.fi   "He disagreed with something that ate him." :
:............................................................................:

In article <1990Oct2.180301.10897@cs.utk.edu> Dave Sill <de5@ornl.gov> writes:
>In article <4140@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
>>GNU stuff is *not* free. It costs something other than money, though: it costs
>>your freedom to do as you like with your code if you include even a line of
>>their code. $150 sure sounds cheap by comparison.
>
>Yes, their are restrictions on what you can do with *their*
>code--you're free to do whatever you want with your own code--but
>isn't that only fair?  And there is absolutely no reason why one would
>need to include a modified bash in their product, so the fear of it
>causing you to give your precious code away is baseless.

Of course, I thought the premise of FSF's forcing source distribution was
to *encourage* enhancements to their products.  Silly me.....

And yes, I think they ARE products; the General Public Virus (I like that term)
is as much a licensing agreement as anything shrinkwrapped on the back of
the latest Lotus release.  The terms may differ, but the idea of 'it's OUR
code and you have to play by OUR rules' is the same.

"I can't afford free software" is being heard quite a bit these days.  FSF's
attitude may have something to do with it.

						Bob Halloran
=========================================================================
Internet: rkh@mtune.dptg.att.com		UUCP: att!mtune!rkh		
Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed.
Quote: "How do you know when a politician is lying?  His lips move." 
	- M-m-max Headroom
       "Read my lips - no new taxes..."  - G. Bush, 1988
=========================================================================

towfiq@interlan.Interlan.COM (Mark Towfiq) wrote:
> lvc@cbnews.att.com (Lawrence V. Cipriani) writes:
>> ksh 11/16/88e is now available in the AT&T Toolchest; there
>> is a $150 upgrade for previous purchasers.
> There are several things wrong with this blatant advertisement:

> 1) It has always been frowned upon to post ads to regular groups [...]

Not unconditionally.  This ad didn't indulge in superfluous puffery.  It was
useful to me.

> 2) The ksh is a miserable piece of junk, when compared to the GNU superset
> shell, BASH (which supports ksh-like vi-type editing [...]

Last time I heard about it, bash didn't have "select", which makes it a
LONG way from being a superset.  (If the only edit mode it has is vi,
forget it).

I appreciate Larry telling us about the new version, and hope that new
versions of other shells are also announced here.

-- 
--  Jack Campin   Computing Science Department, Glasgow University, 17 Lilybank
Gardens, Glasgow G12 8QQ, Scotland   041 339 8855 x6044 work  041 556 1878 home
JANET: jack@cs.glasgow.ac.uk    BANG!net: via mcsun and ukc   FAX: 041 330 4913
INTERNET: via nsfnet-relay.ac.uk   BITNET: via UKACRL   UUCP: jack@glasgow.uucp

In article <APS.90Oct3040434@kaarne.tut.fi> aps@tut.fi (Suntioinen Ari) writes:
   BASH is great, it dumps core and has clear documentation.

BASH *is* rather nice.  Yes, as distributed it will dump core on
machines trap a dereferenced NULL, but anyone who has any programming
ability can track that down can fix it (there have been N+1 messages
about this problem on the mailing list) or just reading the mailing
list will also tell you how to fix it.  Let's see you try and fix any
bug you find in a binary-only distribution.  As for clear
documentation, there's Chet's man page and the POSIX spec.  That's at
least as well as most vendors document the shells they ship.
-- 
Rich Kaul                         | It wouldn't be research if we
kaul@icarus.eng.ohio-state.edu    | knew what we were doing.

In article <APS.90Oct3040434@kaarne.tut.fi> aps@tut.fi (Suntioinen Ari) writes:

>=> 	2) The ksh is a miserable piece of junk, when compared to the
>=> 	GNU superset shell, BASH (which supports ksh-like vi-type
>=> 	editing, and built-in help, among other things).  GNU is free,
>=> 	with modifiable source; ksh costs money.
>
>BASH is great, it dumps core and has clear documentation.

Well, I guess you're entitled to a full refund.

Korn first released ksh in 1982.  Bash has had a year.  Give us time to
catch up. 

As to documentation, FTP to cwns1.ins.cwru.edu (129.22.8.43) for a very
detailed bash manual page.  It's in pub/bash/bash.1.  There's also a
Postscript version there in bash.PS.  The next release of bash will have
an `FSF-style' texinfo manual.  I've proofed it; I know it exists.

The next release of bash should also be much more stable.  Brian is in
the process of merging two slightly divergent versions -- his and mine.
I run mine here as sh on several machines (all 4.3 BSD, but then that's
what we've got...), and haven't had a version that wasn't in the middle
of some development cycle dump core in months.  I would expect the merged
version to be just as reliable.

(By the way, I don't mind Larry posting ksh announcements here.  In fact,
I'd like him to post a list of changes between 88d and 88e, if he would.
I'm always looking for reasonable ksh features to incorporate into bash.)

Chet


 
-- 
Chet Ramey				``Levi Stubbs' tears run down
Network Services Group			  his face...''
Case Western Reserve University	
chet@ins.CWRU.Edu		

In article <TOWFIQ.90Oct2112740@lcxserver.InterLan.COM> towfiq@interlan.Interlan.COM (Mark Towfiq) writes:

| There are several things wrong with this blatant advertisement:
| 
| 	1) It has always been frowned upon to post ads to regular
| 	groups, and some people are actively hostile to it.  

  So then why post your FSF ad? You should post informational postings,
like the one about ksh88e.

| 	2) The ksh is a miserable piece of junk, when compared to the
| 	GNU superset shell, BASH (which supports ksh-like vi-type
| 	editing, and built-in help, among other things).  GNU is free,
| 	with modifiable source; ksh costs money.

  bash is nice if you want to modify the source. ksh comes with source
which works, and I've compiled 88d on about 15 machines and o/s
variations without having to port a special compiler or set of header
files to compile it. Not everyone run gcc.

| 	3) People don't want junk postings any more than they want
| 	junk mail.  

  So don't post junk mail.

| 	            There is a newsgroup for this stuff, you know.
| 	I'll let you read news.announce.NEWUSERS to find out what it
| 	is.

  Hell, I'll tell you for free: alt.flame. Please take your posting and
philosophy with you.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

In article <MWM.90Oct2145651@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes:

| Just out of curiosity, when did AT&T start allowing people to freely
| redistribute their code if it's part of a derived work? 

  V6, I believe. You can compile stuff with their compiler, link it with
their linker, and link in their library, and sell the resulting
executable without giving away source.

  Don't use bison or the (still in beta) FSF library if you want to keep
your code to yourself.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes:

>Just out of curiosity, when did AT&T start allowing people to freely
>redistribute their code if it's part of a derived work? At least,
>you're implying that I'm free to do what I want with my code if it
>includes AT&T's code, which generally includes redistribution.

	As is the case with other Toolchest products, one may choose to
take out a binary distribution license that will permit one to distribute
product based on the licensed source. Of course, this costs money, but
one is always free to find something else that meets his needs.

	One additional advantage of ksh against bash and other PD stuff
is that it will be a supported component under System V Rel 4. Those
spoiled children contrasting the products of the profit-oriented against
the selfless copyleft'ers should remember that much of the sustenance of
the latter comes from the former.

Just as a matter of interest, would you recommend alt.flame.gnu or
alt.flame.fsf for a forum for this debate?

(hold off folks, RMS is supposed to be relaxking the library terms)
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

In article <1990Oct3.140828.8051@usenet.ins.cwru.edu>, chet@cwns1.CWRU.EDU (Chet Ramey) writes:
> As to documentation, FTP to cwns1.ins.cwru.edu (129.22.8.43) for a very
> detailed bash manual page.  It's in pub/bash/bash.1.

Thanks, I'll forward a copy of the bash man page to Korn; he is always
looking for reasonable features to incorporate into ksh!  By the way,
Korn is very much in favor of the GNU project and ksh imitators.

> (By the way, I don't mind Larry posting ksh announcements here.

Thanks.

> In fact, I'd like him to post a list of changes between 88d and 88e, if he
> would.  I'm always looking for reasonable ksh features to incorporate into
> bash.)
--
This is not precisely what you want but this may be of more general interest.

[By the way, the "$150 dollar for previous purchasers." was a direct
quote from email I got from Korn; I apologize for the confusion.]
--
This is a list of changes [mainly bug fixes and minor enhancements] that have
been made since the 11/16/88 version of ksh. 

1.	New features in 11/16/88[abcde]
	a.  All characters of alias names can contain non-special
	    characters, not just the first.  A / is not a valid alias
	    character.
	b.  The vi % directive has been added to 11/16/88c
	c.  A new [[...]] -C option returns true for contiguous files.
	    This option returns false on systems that do not support
	    contiguous files.
	d.  Setting REPLY to the null string in a select command causes
	    the selection list to get refreshed in 11/16/88d.
	e.  Unary minus added for arithmetic expressions to increase
	    compatibility with system V test command.
	f.  Starting with 11/16/88e, The vi directive '#' has been changed
	    so that each line of the command is turned into a comment.
	    Also, if the first character of the command is a '#', the '#'
	    in front of each line is deleted.
	g.  The message for EOF with ignoreeof has changed in 11/16/88e.
	h.  A SOCKETS option has been added for machines with the BSD
	    socket calls so that scripts can connect to sockets via
	    redirection.  See the README file for more details.
	i.  Starting with 11/16/88e, the behavior of 'ksh script' where
	    script is not a shell script has been changed.  If ksh detects
	    that script is an a.out, a cannot exec error message is generated.

2.	Bugs fixed in 11/16/88a for default OPTIONS
	a.  Files containing a \ were not matched correctly with patterns.
	b.  read without arguments no longer references location 0.
	c.  The value of integer exported variables was not inherited
	    correctly in some cases.
	d.  The characters ()|&\ in IFS did cause word splitting when ksh
	    expanded commands. 
	e.  $! expanded to 0 before any background jobs were run, rather
	    than to the null string.  The value of $! was not reset to
	    null when running a script by name.
	f.  On some machines, the shell would core dump if the variable
	    LINENO was exported.
	g.  The [[ ]] command did not handle multiple && and || without
	    parenthesis grouping.
	h.  On some BSD implementations, terminal setting were being
	    incorrectly reset when using vi-mode. 
	i.  The execution of traps that write to standard output got
	    lost when the trap occurred while executing command substitution
	    of a built-in command. 
	j.  The noclobber option now only applies to ordinary files.
	k.  The value of RANDOM changes when ksh creates a subshell.
	l.  Some syntax error messages had extra backslashes in them.
	m.  The expansion ${#name[number]} was not returning the string
	    length of array element number.
	n.  ksh did not work correctly in some cases when there was
	    no search permission in the current directory.
	o.  A pipeline would hang if the last element of the pipeline
	    was a shell construct that created a lot of child processes.
	    For example, cat file | while read line;do /bin/true;done
	p.  getopts has been fixed to agree with the description in
	    the man page.  Previous ksh initialized OPTIND to 0, not 1,
	    and did not handle the case with a leading : as described.
	q.  If the name of the directory you are in contained a :,
	    a cd command to a relative pathname did always work correctly.
	r.  read -s now saves commands in the history file even when
	    read has been redirected from a file.
	s.  Some here documents containing command substitution with
	    a command that read from standard input didn't work
	    correctly.
	t.  (exec >&-; echo $(command) >&2) no longer runs command
	    with file descriptor 1 closed.
	u.  The <ESC>* command of vi and emacs inserted an extra
	    space when exactly one file matched.
	v.  A bug in vi edit mode caused a 'p' command to fail
	    after a 'D' command on some machines.
	w.  Reseeding the random number generator now guarantees
	    the same random sequence.
	x.  The results command substitution with built-in commands
	    that produced over 1K of output was sometimes incorrect.
	y.  set -A, without an argument, now produces an error message.
	    set -A name ... no longer causes the positional parameters
	    to be reset as an unintentional side effect.
	z.  Unterminated here-documents do not generate syntax errors
	    unless the -n option is on.
	aa. Job control now works for functions as it did with ksh-i.
	bb. The exit status of a pipeline whose last element is a built-in
	    command is now correct.
	cc. ksh no longer dumps core when the last element of a pipeline
	    is a built-in command with an invalid parameter expansion.
	dd. A trap on CHLD is no longer triggered by processes in the
	    current pipeline.
	ee. One systems without readdir(), filename generation left
	    open files by mistake.
	ff. traps ignored in a shell script were sometimes reset to
	    caught when functions were invoked.
	gg. The trace (set -x ) of [[ x < y ]] and [[ x > y]] was incorrect.
	hh. foobar() ; no longer core dumps.
	ii. A trap on continue from within a select loop no correctly
	    when the trap occurs while reading from the terminal.
	jj. The r command correctly handles numerical replacements so
	    that r 3=4 now works.
	kk. Long lines (>3K) no longer causes a core dump with read.
	ll. The command substitution $(name=value) no longer causes a
	    core dump.
	mm. With the vi edit mode on some systems, extra characters were
	    left on the screen when the kill or erase characters were
	    preceded by a backslash.
	nn. After a dot script that couldn't be found, a trap command
	    in a script could cause a core dump.
	oo. Redirection with read of the form, read x <&3, was causing
	    the seek position on unit 3 to be positioned incorrectly.
	pp. When an invalid alias name is given, ksh now prints the
	    correct error message.
	qq. On systems with job control, if you escaped to a shell that
	    terminated abnormally, the calling process would hang.

3.	Bugs fixed in 11/16/88b for default OPTIONS
	a.  ${x-"{a}"b} now expands to {a}b when x is not set.
	b.  ksh no longer core dumps with print -s when HISTFILE changed.
	c.  Tab stripping of numbered here-documents now works.
	d.  The deprecated, sh -t, now works the same as System V shell.
	e.  Attempting to list autoloaded functions no longer core dumps.

4.	Bugs fixed in 11/16/88c for default OPTIONS
	a.  The process id for background jobs killed from scripts was
	    incorrect.
	b.  The wait built-in did not always return the correct value when
	    there was more than one background job.
	c.  ksh dumped core while in read with stderr redirected and in
	    emacs mode when it received an signal that had a trap set.

5.	Bugs fixed in 11/16/88d for default OPTIONS
	a.  With the monitor option on with systems without job control,
	    login shells no longer print an extraneous 'running jobs'
	    message with a|b, where b is not found.
	b.  On systems where the behavior of the echo builtin depends
	    on the location of echo in the PATH variable, ksh no longer
	    core dumps if the PATH does not have a directory containing
	    an echo command.
	c.  return with an argument greater than 256 no longer causes
	    a core dump.
	d.  Tests on files whose names are null return false on all systems.
	e.  In some instances $0 was being incorrectly set after the
	    dot command was invoked with arguments inside a script.
	f.  The line number enclosed in [] when ksh reports a syntax error
	    has been corrected to be the first line of the command that
	    it is reading.
	g.  A trap on EXIT after a syntax error sometimes inserted an
	    extra character before the trap command text. 
	h.  for i in ...; do echo ${i[@]};done no longer causes a subscript
	    error.
	i.  If the read built-in was interrupted, the terminal was not
	    always restored to the state it was in before read.
	j.  Output from background status changes with the monitor mode are
	    now written to standard error.
	k.  Executing a function interactively no longer causes SIGTERM
	    to be caught.
	l.  Using _ as an array variable no longer causes a core dump.
	m.  Unsetting a function more than once no longer causes core
	    dumps or other undesired side effects.
	n.  The code to process the substring operator ## was changed
	    so that the time was no longer quadratic in the length
	    of the string.
	o.  A bug that caused a job to disappear from the jobs table
	    after sending it a CONT signal has been fixed.
	p.  On systems where a null pathname is not the same as .,
	    the command 'cd .' would fail if the environment was cleared
	    before executing ksh.
	q.  In vi-mode, the screen did not always get refreshed correctly
	    when an insert followed a delete in front of a control character.
	r.  A bug in getopts that could cause a core dump when getopts
	    was called with fewer arguments on subsequent calls was fixed.
	s.  In vi-mode, ^V^M now enters ^M, not ^J on most systems.
	t.  On systems with job control, the kill command now sends out
	    SIGCONT signal after the signal has been sent, not before.
	u.  If the shell was interrupted while processing the .profile
	    file, the $ENV file was sometimes echoed to the terminal.

6.	Bugs fixed in 11/16/88e for default OPTIONS
	a.  The code for item n from the d point release was omitted
	    but included in this release.
	b.  A script that uses edit modes now restores the terminal
	    modes with it receive a termination signal.  Also, the
	    initial process group is restored for job control shells.
	c.  The standard input for background jobs was not set to
	    /dev/null in some cases where it should have been.
	d.  The value of $? now gets set correctly to indicate an
	    error after eval fails because of a syntax error.
	e.  The line discipline ^O bit is now cleared by ksh on some
	    systems that use sys/termios.h.  Earlier versions only cleared
	    the ^O bit for BSD systems.
	f.  The suid_exec program has been modified to fix security
	    problems that could arise on systems that have symbolic links
	    but do not have the seteuid() system call.
	g.  The precedence for compound arithmetic assignment operators
	    such as *= was incorrectly set at the precedence of the
	    operator rather than the precedence for assignment.
	h.  The suspend character is now disabled when the last process of
	    a pipeline is not stoppable to prevent deadlock.
	i.  An extra secondary prompt was printed whenever a here-document
	    line contained a partial delimiter.
	j.  The EXIT trap will be executed for each function in the calling
	    chain when exit is called and when the maximum recursion level
	    (currently 128) is reached.  Also return now behaves the same
	    as exit outside a function or a dot script and inside a subshell.  
	k.  The value of $? no longer changes with a compound [[...]] command.
	l.  The jobs command now correctly reports 'no such job' when you
	    specify a pid that is not part of any running job.
	m.  The legal names for restricted shells have been reduced to
	    rsh, krsh, and rksh.
	n.  The vi, r, f, and @ directives now process ^V correctly.  Also,
	    the r directive updates the screen correctly after you back
	    up to a control character and replace it with a non control char.
	o.  The command, $x > file, where x is not set, no longer core dumps.
	p.  When the read is redirected from a file it no longer issues the
	    secondary prompt when the line is continued with a \.
	q.  Variables that have attributes, but whose values are unset,
	    are now displayed with typeset, export, and readonly.
	s.  Set, without arguments, now displays the name-value pairs even
	    when preceded with a variable assignment list.
	t.  set -a now causes assignments of the form ${x=value} to get
	    the export attribute.
	u.  Arithmetic expansion, $((...)), inside here-documents no longer
	    causes subsequent parameter expansions to have extra \ inserted.
	v.  A bug that could cause the shell to go into an infinite
	    loop while creating the history has been fixed.
	w.  true and false are now built-in commands rather than aliases so
	    that correct results are produced when invoked with extraneous
	    arguments.
	x.  A tab character near the end of a long prompt no longer
	    causes the shell to hang.
	y.  An expansion of the form $((...)) is processed as an arithmetic
	    expansion only when the inner parenthesis match.  Otherwise,
	    it will be processed as a nested command substitution.
	z.  Unsetting a function no longer causes the whence builtin to
	    give incorrect results for that name.
	aa. Errors detected while expanding the PS1 prompt no longer
	    leave the shell in an undefined state.
	bb. A bug that caused the shell to hang in read when a
	    coprocess (cmd |&) terminated has been fixed.
	cc. A bug in getopts that caused a core dump when standard error
	    was redirected has been fixed.
	dd. Testing for file access with null file names now returns false
	    now on all systems. 
	ee. A bug with [[...]] that caused quoting of patterns following the
	    = and != operators to give incorrect results has been fixed.
	ff. A bug with nested $() of builtins, where inner $() was enclosed
	    in double quotes has been fixed.
	gg. A bug that caused incorrect results when the -x trace option
	    was enabled and command substitution of a builtin command 
	    produced no output was fixed.
	hh. A bug that prevented set -e from exiting with pipelines has
	    been fixed.
	ii. Interactive shells that trap TERM, and then reset the trap,
	    no longer exit when they receive a TERM signal.
	jj. When inserting text in vi mode, the kill character deletes
	    only the insertion, not the whole line. 
	kk. A bug with eval that occurred when a word ended in a \ has
	    been fixed.
	ll. typeset -f fname now returns false after function fname
	    has been unset.
	mm. A bug in trap that caused a command to be interpreted as a
	    trap number if the first character was a digit has been fixed.
	nn. A bug that caused a trap action of return to not work correctly
	    when an interrupt occured during read has been fixed.
	oo. A bug that could cause the exported value of an integer variable
	    that has been imported and modified to be incorrect has been fixed.
	pp. A bug that caused set -n to incorrectly report subscript errors
	    has been fixed.
	qq. The select list variable is now set to null when none of the
	    given choices is not selected.  Previously it was unset. 
	rr. The pattern */foo, now also matches symbolic links to non-existent
	    files.
	ss. The whence command no longer terminates when it doesn't find
	    one of the names.

7.	Bug fixes for specific non-default option combinations.
	a.  VERSIONS: MULTIBYTE no longer automatically enabled.
	b.  ACCT: The accdefs.h include removed.
	c.  BRACEPAT:  No longer references location 0 and dumps core.
	d.  EMACSPLUS: Now enables additional EMACS features.
	e.  FLOAT:  arith.c now compiles.
	f.  VI off:  e_runvi is no longer unsatisfied external.
	g.  SUID_EXEC: execute only works when file descriptor 10 is open. 

8.	Other changes to 11/16/88[abcde]
	a.  sh.1 corrections.
	b.  sh.memo corrections.
	c.  ksh.mk modified to build in a cross development environment.
	d.  jobs.c modified to compile on machines that define the new
	    line discipline, NTTYDISC, but not the old, OTTYDISC.
	e.  RELEASE file corrections.
	f.  Some fixes to the stand-alone edit libraries.
	g.  VERSIONS option renamed FS_3D
	h.  POSIX option added to try out some IEEE POSIX 1003.2 proposals.
	i.  VFORK bugs fixed.  I still don't recommend this option.
	j.  OLDTERMIO option added to 11/16/88c.  This option allows older
	    termio ioctls, like TCGETA to be called after newer termios
	    ioctls' fail.  Only effective for machines that have both termio.h
	    and termios.h.
	k.  universe builtin added to 11/16/88d for systems with /bin/universe.
	l.  code changes to 11/16/88e to remove sbrk() dependence and to
	    use the standard library version of malloc().
	m.  A tests directory that contains some ksh regression test has
	    been added.  See the README file for more details. 
	n.  The way builtin commands are coded has been changed to make
	    it easier to add builtins.

9.	Incompatibilities with 11/16/88 version.
	None intentional.

-- 
Larry Cipriani, att!cbvox!lvc or lvc@cbvox.att.com
           "Save a logger, eat an owl"

In article <5X66S+B@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:

| (hold off folks, RMS is supposed to be relaxking the library terms)

  I certainly hope so. I talked to him last year about relaxing the
license enough to allow giving away a program in binary without source,
after it went through bison and used the skeleton. He declined.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

As far as I can tell from examining the BASH documentation, BASH is a
mutated C shell. I will always prefer KSH to any version of the C
shell.
-- 
David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631

feustel@netcom.UUCP (David Feustel) writes:

>As far as I can tell from examining the BASH documentation, BASH is a
>mutated C shell. I will always prefer KSH to any version of the C
>shell.
>-- 
>David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631

  It could be that you read some very strange docs, as i would say that BASH
is a far cry from being a "mutated C shell". Its command syntax if the same as 
the Bourne shell. If anything at all is is a super-Bourne shell. 
-----------
Christian Ratliff          InTeRnEt    caleman@rpi.edu
                           BiTnEt      caleman@rpitsmts
"It's all just ones and zeros"
                                -Mr. Button

In article <14617@netcom.UUCP>, feustel@netcom.UUCP (David Feustel) writes:
> As far as I can tell from examining the BASH documentation, BASH is a
> mutated C shell. I will always prefer KSH to any version of the C
> shell.

Read the manpage more carefully.  Bash is basically a reimplementation
of ksh (with some other stuff thrown in as well).

----------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA

What I read was the bash documentation. The features that I saw
described made me think more of the C shell than the Bourne Shell. I
admit to having been puzzled by the apparent contradiction between the
name and the features. Having been originally eager to port BASH to my
machine, I lost interest after my initial examination of the
documentation mentioned above.
-- 
David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631

   What I read was the bash documentation. The features that I saw
   described made me think more of the C shell than the Bourne Shell. I
   admit to having been puzzled by the apparent contradiction between the
   name and the features. Having been originally eager to port BASH to my
   machine, I lost interest after my initial examination of the
   documentation mentioned above.
   -- 
   David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631

From a purely user stand point bash does somewhat look like csh ( ksh
looking is much closer to the truth... )

Programming wise, sh/ksh.  I should know, all our scripts at our site are
csh... 

-randy
-- 
Randy Welch   Mail to :  ...!ncar!scicom!bldr!randy or rwelch@du.edu
Boulder, CO   VOICE   :  303-442-6717
"Unfortunately, life contains an unavoidable element of unpredictability"
-David Lynch "The Angriest Dog in the World"