svn commit: r363091 - in head/contrib/bc: . include manuals src tests tests/bc

[Jessica Clarke]

On 30 Jul 2020, at 17:40, Ravi Pokala <rpokala at freebsd.org> wrote:
> 
> -----Original Message-----
> From: <owner-src-committers at freebsd.org> on behalf of Jessica Clarke <jrtc27 at freebsd.org>
> Date: 2020-07-30, Thursday at 09:35
> To: Baptiste Daroussin <bapt at FreeBSD.org>
> Cc: Stefan Eßer <se at FreeBSD.org>, src-committers <src-committers at freebsd.org>, <svn-src-all at freebsd.org>, <svn-src-head at freebsd.org>
> Subject: Re: svn commit: r363091 - in head/contrib/bc: . include manuals src tests tests/bc
> 
>    On 30 Jul 2020, at 17:31, Baptiste Daroussin <bapt at FreeBSD.org> wrote:
>> On Thu, Jul 30, 2020 at 05:28:19PM +0100, Jessica Clarke wrote:
>>> On 30 Jul 2020, at 17:20, Baptiste Daroussin <bapt at FreeBSD.org> wrote:
>>>> On Sat, Jul 11, 2020 at 07:33:19AM +0000, Stefan Eßer wrote:
>>>>> Author: se
>>>>> Date: Sat Jul 11 07:33:18 2020
>>>>> New Revision: 363091
>>>>> URL: https://svnweb.freebsd.org/changeset/base/363091
>>>>> 
>>>>> Log:
>>>>> Update to version 3.1.3
>>>>> 
>>>> Jumping on that commit, since the switch from our previous bc.
>>>> 
>>>> The output of the interactive bc has changed, the previous version had a clean
>>>> UI, the new version "pollutes" the output with plenty of lines about the
>>>> copyright:
>>>> 
>>>> ====
>>>> Copyright (c) 2018-2020 Gavin D. Howard and contributors
>>>> Report bugs at: https://git.yzena.com/gavin/bc
>>>> 
>>>> This is free software with ABSOLUTELY NO WARRANTY.
>>>> ====
>>>> 
>>>> Imagine if all programs where doing that, it would be painful, do you think
>>>> upstream can be convinced to remove those lines?
>>>> 
>>>> I no the GNU version also has the same polluted output which was one of the
>>>> reason I was happy with out previous version of bc.
>>> 
>>> By default both will print such a banner if and only if being called
>>> interactively. You can disable the banner explicitly with -q/--quiet
>>> for both GNU bc and this bc. I agree it's a bit noisy and would be
>>> nicer to not have that printed, but it's not without precedent for
>>> REPL-like things.
>> 
>> Yes it is not without precedent for REPL-like things, still I dislike this and
>> would be happy to get bc interactive be as nice as the previous one we had :)
>> 
>> If not I will deal with it and just yell internally each time I run it :D
> 
>    `alias bc='bc -q'` / `alias bc bc -q` and preserve your inner zen? :)
> 
>    Jess
> 
> I was actually about to complain about the new `dc' not exiting after evaluating a '-e' expression, without an explicit 'q'. But then I noticed the "DC_EXPR_EXIT" envvar, which restores the desired behavior. That lead me to discover "DC_ENV_ARGS" and, correspondingly, "BC_ENV_ARGS"; that last one would be helpful here.

That does feel like the wrong default; even GNU dc doesn't do that, and
the principle of least surprise would suggest exiting is the right
thing to do. It's also unlikely you want to evaluate something and then
use it interactively.

Jess