Feature : ECHO utility to support hex output
Closed this issue · 6 comments
Maybe I missing something but can I do hex output to file with any Yori utility?
It will be nice to do something like this:
echo -hex -- \x04\xFF > C:\temp\file.hex
or
hexwrite \x04\xFF > C:\temp\file.hex
Maybe I am wrong but I think this very simple to implement, so things like described in this question can be done in Windows.
By the way I've noticed that REPL utility is missing from main HELP command of Yori shell... it was very nice to find it by accident =)
Try this:
echo 04 FF | hexdump -g1 -hc -ho -r > C:\temp\file.hex
Wonderful! Thank you
Unfortunately this method works only with first 16 bytes of the echo... this command will output only 16 bytes to hex file:
echo -n -- 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 | hexdump.exe -g1 -hc -ho -r > C:\temp\file.txt
In resulting file there will be no 10 value which stands at 17th position of echoing string... I know I can do such command for every 16 bytes I need to write but is there any workaround of this limitation?
And by the way single byte output do not work too:
echo -n -- 0B | hexdump.exe -g1 -hc -ho -r > C:\temp\file.txt
this command will create zero size file.
hexdump -r was intended to reverse the process of a normal hexdump. The normal output may include an offset on each line, and may be followed by characters at the end of each line. Each line is defined as containing 16 bytes, and the format of the line is detected heuristically.
So firstly, note that specifying -g1 -hc -ho with -r is just being ignored.
The second issue raised here that a single byte isn't parsed correctly is because the heuristic detector didn't detect it correctly, because it was trying to infer the word length by looking for a trailing space. This was updated in commit 78623d7 to treat line end as indicator of word length.
The main issue raised here though is more involved, because there's no reliable way to distinguish between "characters at the end of each line" and "more hex digits to parse." That means this operation needs to be different to the existing reverse mechanism. I added -bin as part of commit 1ce1b7d which rejects any leading offset and expects no trailing characters, and having done so, can accept as many hex digits on a line as happened to be there. Note this is still using the same heuristic logic to detect word length, so sending a stream of bytes requires a space between each byte.
Thank you! I am very glad to see -bin switch... I've done some testing and and one thing that maybe a feature, not a bug =)
echo -n -- "AA" | hexdump -bin > test.bin - will make file with 1 byte
note there is no delimiter space between byte characters in next command:
echo -n -- "AABB" | hexdump -bin > test.bin - will make file with 2 bytes
and
echo -n -- "AABBCC" | hexdump -bin > test.bin - will NOT make file with 3 bytes
but with space delimiter next command:
echo -n -- "AA BB CC" | hexdump -bin > test.bin - will make file with 3 bytes
I can not consider this as an issue, just want to mention above for you maybe to get any thoughts
I will close this issue since now all works as expected.