On Tue, Feb 21, 2017 at 07:19:13AM +0100, Otto Moerbeek wrote:
> On Tue, Feb 21, 2017 at 07:00:34AM +0100, Otto Moerbeek wrote:
>
> > On Tue, Feb 21, 2017 at 04:08:57AM +0100, Martijn Dekker wrote:
> >
> > > Upon encountering a parsing error, bc(1) passes an error message on to
> > > dc(1), whic
On Tue, Feb 21, 2017 at 07:00:34AM +0100, Otto Moerbeek wrote:
> On Tue, Feb 21, 2017 at 04:08:57AM +0100, Martijn Dekker wrote:
>
> > Upon encountering a parsing error, bc(1) passes an error message on to
> > dc(1), which writes the error message to standard output along with the
> > normal outp
On Tue, Feb 21, 2017 at 04:08:57AM +0100, Martijn Dekker wrote:
> Upon encountering a parsing error, bc(1) passes an error message on to
> dc(1), which writes the error message to standard output along with the
> normal output.
>
> That is a bug. Error messages should go to standard error instead
Op 21-02-17 om 04:08 schreef Martijn Dekker:
> bc() {
> _bc_err=$(command -p bc "$@" 1>&3 2>&1)
Correction, the redirections should be the other way around:
_bc_err=$(command -p bc "$@" 2>&1 1>&3)
Sorry about that,
- M.
Upon encountering a parsing error, bc(1) passes an error message on to
dc(1), which writes the error message to standard output along with the
normal output.
That is a bug. Error messages should go to standard error instead, as
POSIX specifies:
http://pubs.opengroup.org/onlinepubs/9699919799/utili
