On Fri, Aug 28, 2015 at 4:14 PM, Warren Young <wyml@xxxxxxxxxxx> wrote:
> On Aug 28, 2015, at 9:50 AM, Gordon Messmer <gordon.messmer@xxxxxxxxx>
> wrote:
> >
> > On 08/28/2015 07:15 AM, Mike - st257 wrote:
> >> Thoughts as to why my BC functions aren't properly converting between
> bases?
> >>
> >> Decimal to binary or hex works fine, but not binary or hex to decimal
> and
> >> so forth.
> >
> > I'm not an expert in bc, so I might be wrong, but it looks like setting
> the ibase inside a function is simply too late. ibase affects how bc
> interprets input.
>
Thanks Gordon.
Big bummer given that behavior. :-/
I had (and did test) definitions for other conversions (though I didn't
post them), but this one also drives it home.
~]$ grep bin_to_hex ~/.bcrc
define bin_to_hex(b) { obase=16; ibase=2; return b; }
~]$ echo "bin_to_hex(10101011)" | bc
9A2113
# so we're sending in a string with implied base10 ... sure enough matches
what BC errantly decided to do
~]$ echo "obase=16; 10101011" | bc
9A2113
~]$ echo "obase=16; ibase=2; 10101011" | bc
AB
>
> Yes, and it’s a serious design mistake in bc, IMHO. No other programmable
> system I’ve ever used changes how numbers in program text are interpreted
> based on prior commands to the system.
>
> I wrote a long answer explaining this on the Unix & Linux Stack Exchange
> here:
>
> http://unix.stackexchange.com/a/199620
>
>
Thanks Warren.
The order of obase and ibase definitely are bizarre and tripped me up the
first time around. I expected I should set ibase first and no no no that
was not the case! ;-)
To all:
I suppose my only options for this are to use shell functions or write a
script using a language that handles things properly (sanely?).
Thanks for the input everyone!
Best,
--
---~~.~~---
Mike
// SilverTip257 //
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
