On Aug 31, 2015, at 6:55 AM, Mike - st257 <silvertip257 at gmail.com> wrote:> > I suppose my only options for this are to use shell functions or write a > script using a language that handles things properly (sanely?).No, there?s a fairly common hack around this problem: ibase=A and obase=A *always* means ?base 10? regardless of the current base, due to a quirk in the way values for these settings are interpreted. Thus you can always force your way back to sanity. My objection is that this is even necessary in the first place.
On Mon, Aug 31, 2015 at 11:15 AM, Warren Young <wyml at etr-usa.com> wrote:> On Aug 31, 2015, at 6:55 AM, Mike - st257 <silvertip257 at gmail.com> wrote: > > > > I suppose my only options for this are to use shell functions or write a > > script using a language that handles things properly (sanely?). > > No, there?s a fairly common hack around this problem: ibase=A and obase=A > *always* means ?base 10? regardless of the current base, due to a quirk in > the way values for these settings are interpreted. Thus you can always > force your way back to sanity. >Not sure how this helps me with my most recent example of bin_to_hex where the ibase within the define clause wasn't honored. Working with bc interfactively or by piping produce the desired/correct values. Testing indicates the ibase is defaulted or overrode as base10 despite what is specified in the define clause. :-(> > My objection is that this is even necessary in the first place.Agreed. -- ---~~.~~--- Mike // SilverTip257 //
On Aug 31, 2015, at 10:05 AM, Mike - st257 <silvertip257 at gmail.com> wrote:> > On Mon, Aug 31, 2015 at 11:15 AM, Warren Young <wyml at etr-usa.com> wrote: > >> ibase=A and obase=A > > Not sure how this helps me with my most recent example of bin_to_hex where > the ibase within the define clause wasn't honored.That?s because your bin_to_hex function is erroneously assuming that its input is just a string of digits that has no base interpretation, so that it can set ibase *after* bc has already seen the value, and that this will change the meaning of the prior input. That?s just plain wrong: the prior input has already been interpreted. You can?t wind back the clock like that. That sort of thinking only works in a string-based language like shell or Tcl, where a numeric string doesn?t take a meaning until you assign one. The correct form is: ibase=A /* needed only if ibase might not be 10 at this point */ obase=A /* ditto */ obase=16 /* means 16-base-10 here */ ibase=2 /* no possibility of confusion */ 10101011 Result: AB, as expected. The tricky bit is that you can?t swap the second pair of ibase and obase settings, since that would cause bc(1) to interpret obase=16 in base 2: bc(1) will clamp ?16? to 11, which in base 2 is 3-base-10.