Date: Wed, 25 Mar 1998 09:32:39 -0800
From: Bill Campbell <bill@celestial.com>
To: caldera-users@rim.caldera.com
Subject: Re: Caldera 1.2 wierd bc behaviour

On Wed, Mar 25, 1998 at 11:24:00AM +0100, Raymund Will wrote:
>Recently Bill Campbell wrote:
>> The bc-1.04-1 included with Caldera 1.2 now echos its standard input
>> instead of just the result when run from a pipe.  This is to say that
>> a command like VAL=`echo '2 * 2' | bc ` doesn't set VAL to 4, but to
>> ``2 * 2'' which breaks scripts.
>
>It's not a bug!  It's a feature!  :*)
>This strange behavior stems from the fact, that 1.04-1 has working
>readline/history support -- which apparently breaks pipe-usage...
>
>But that's no specific Caldera problem -- you can only complain, that
>they've tried to provide you with that feature ...   ;)
>
>Workaround #1: Use bash's '$[ 2 * 2 ]' for simple maths (speedup!)...
>Workaround #2: /usr/bin/expr should do OK for simple maths...

These two aren't options as I'm using bc specifically to get around
the 32-bit limitations of expr (the particular script that broke when
I discovered this is setting the size of backup media and originally
broke when 4GB DATs showed up).

>Workaround #3: Compile yourself a version of bc '--without-readline'...

Or remove this rpm and install an older one.

I can understand an occassional slip-up like this getting through, but I've
found several other things on 1.2 that have caused me problems including:

  1.  Changing the name of the program to set the CMOS clock from ``clock''
      to ``hwclock''.

  2.  Changing the format of the /etc/lpd.conf file.

  3.  Pedantic output of the `ps -...'' command saying that use of the
      ``-'' character is deprecated.

  4.  Changing the behaviour of the ``bc'' command.

I can work around any of these things, but if I want to do that every time
a system update comes out I might as well buy Microsoft products.

One of the beauties of Linux is that it's introducing many people to the
joys of good software at a price that they can afford.  The flip side of
this is that many people working on it are inexperienced and don't realize
the consequences of changing the behaviour of existing programs -- even if
the result is ``better''.  I did the same thing myself when I had been
programming for a year or two, taking advantage of all the vendor's neat
features, etc.

It wasn't until I had been programming long enough to have a volume of
working software, had to work on a different system where the ``neat
features'' weren't supported (but had its own set of features), and had to
go back and modify all my old programs that I decided that using standards
was a Good Thing(tm).  I much prefer developing new systems to going back
and ``fixing'' programs that have been working for almost twenty years
because somebody had a ``better idea''.  Unlike Microsoft, we don't get
paid to fix bugs, only for new systems or enhancements to existing ones.
Nor are we a University or government agency where we need things to do to
keep busy and justify our paychecks.

It's OK to add capabilities and features to an existing program while
leaving it compatible with earlier versions so that it doesn't break
existing code, and add new options which don't interfere with existing
operation.  If the behaviour is significantly different, the program should
have a new name (i.e. bzip and bzip2).

One of the things that commercial Unix vendors like to do is say that Linux
is non-standard and changes too often.  It's not in Caldera's interest as
the leading commerical Linux vendor to make this a valid argument.

Bill
--
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Systems, Inc.
UUCP:              camco!bill   2835 82nd Avenue S.E. S-100
FAX:           (206) 232-9186   Mercer Island, WA 98040; (206) 236-1676
http://www.celestial.com/

"I do not feel obliged to believe that the same God who has endowed us
with sense, reason, and intellect has intended us to forego their use."
                                -- Galileo Galilei