[Top][All Lists]
[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.