Hello,
Recently I've tried to use BASH to do some binary operations, that task turned
out to be far more difficult, that I could ever imagined.
First of all, I've found out that 2 shifted to the left edge of boundary
(2**63) produces as a result a negative number "-9223372036854775808" ("funny"
thing is, when you substract "1" from this value, it gives positive value as a
result), this problem is of course related to "u2 code", but still it's an
error, which can cause various difficult to perceive problems during script
execution - i.e. PERL deals with it by substituting integer value, with
floating point value, which at least has a proper sign.Another thing, which
doesn't behave exactly the way it should, is bit shifting. While shifting
positive value to the right gives 0 at the end, then shifting negative value
gives "-1" at the end, again it's related to "u2 code". I.e. try to shift "1",
63 times to the left (it will turn into negative value), then shift it back to
the right, you'll never guess it won't evaluate to "0" but to "-1"! This
is error in "logic", which lays beneath this whole idea. Bit operations
shouldn't be sensitive to "u2 coding", as coding is on higher abstract level
then any of bit operations, which deals with "raw bits" on lowest
level!Genrally speaking, there is significant flaw in BASH, if it comes to any
binary operations - with whole do respect, your whole idea is one big
misconception. You've introduced all kinds of bit operators but they "works"
only on numbers, if anyone try to use it on character, they won't work properly
(those are some other "magical bits"?!). BASH for some reason is concentrated
almost solely on strings (almost like PERL), reading & writing characters
is relatively easy thing to be done but doing same thing with "raw data"
(binary data) requires making crude workarounds (like using coreutils "od" to
read data as numbers, not as characters & ab-using "printf" to later write
them to the file), while it should be possible to do it easily by using only
read & write commands - data stored in memory or on disc (or any other
medium), are just bunch of bits, meaning of those bits is determined later,
during processing (like in "C" language, where type "char" is in fact numeric
& it's interpretation by some commands gives it special meaning) &
programmer should be being able to decide the way he want to perceive those
data!I can see two solutions (one dosen't exclude the other) to this problem.
First one is to add commands which allows to read & write data the way,
they could be processed always as numbers.
The other is to introduce user defined data types or at least add ability to
control "data perception" (if they should be perceived as numbers or characters
or some other way...i.e. references). Giving a user/programmer an ability to
control "general" data type, will makes various operations easier, its results
more predictable & the best thing is, it can be introduced the way, that
doesn't require to change whole logic of BASH or even force scripts to be
re-written - it might be an extension, which user uses only if necessary, if
not the BASH behave as it is now.
To be honest, I would never dream (or I rather should write "to have a
nightmare") to use BASH to do binary ops but unfortunatelly I've faced task
which requires me to relay on it (& thankfully some of "coreutils"), I'm
able to overcome all flaws mentioned above, using very coarse workarounds
(essentially "hacking" some commands), to do the things, that should have been
done easily, with full support of the enviroment.
