bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11085: factor only supports decimal numbers, doh


From: Jim Meyering
Subject: bug#11085: factor only supports decimal numbers, doh
Date: Tue, 27 Mar 2012 09:44:48 +0200

severity 11085 wishlist
tags 11085 notabug
retitle 11085 RFE: teach factor to read/write hexadecimal
thanks

Adam Back wrote:
> Thanks for replying.  I am aware of bc, dc etc.  And in fact that was what I
> did to work around (used bc), but it seems like unnecessary feature removal
> when the underlying crypto library the tool is calling to actually do the
> work is more natively working with hex (binary).
>
> Sorry about getting off on the wrong foot with the "stupid" word mixed into
> my thought.
>
> I have been using unix exclusively since 1989, and yes I am a fan of the
> unix philosophy.  I would qualify "it is possible to use other tools to work
> around the lack of this feature" to more the tools are scalable,
> conveniently pluggable etc.  And convenient pluggability applies IMO.
>
> Eg lets say od can output in different formats (-tx1 I use commonly if I
> need convert a file into something suitable to chain with some other crypto
> command line tool) ...  you "could" no doubt work around that with awk, perl
> or maybe even bc if you were creative, but it just makes things less
> convenient to chain if the default or only output is not directly
> compatibile with the main consuming next in the chain tools natural, default
> or only input...

You can define a shell function like this to handle the input conversion:

f2(){ factor $( { echo ibase=16\;;echo "$*"|tr a-f A-F|tr -s ' ' \;; } |bc); }

and use it like this:

    $ f2 FF FFF
    255: 3 5 17
    4095: 3 3 5 7 13

Considering that to get the same effect internally (in factor.c),
I would have to change two separate code paths (with/without GMP),
and -- perhaps more importantly -- that yours is the first request
for this feature, your using the simple wrapper is preferable.

And that is considering only the input conversion.
I'm sure you can find or write a tool that parses an arbitrary
stream of integers and converts them from decimal to hexadecimal.
So far, it does not seem justified to add an option for that.

However, if someone is interested enough to write patches, you might
be able to convince us that a hexadecimal input should be accepted
and should cause factors to be printed in hexadecimal.  e.g.,

    $ factor 0xFF 0xFFF
    0xFF: 3 5 11
    0xFFF: 3 3 5 7 C

Then there's no need for a new option.

But realize that this is no trivial task and would require an FSF
copyright assignment.
As usual, the change set would also have to add tests (be sure to
exercise both code paths) and update documentation and NEWS.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]