search

malxau / yori

Yori is a CMD replacement shell that supports backquotes, job control, and improves tab completion, file matching, aliases, command history, and more.
http://www.malsmith.net/yori/
MIT License
1.23k stars 30 forks source link

Feature : ECHO utility to support hex output #77

Closed aleaksunder closed 3 years ago

aleaksunder commented 3 years ago

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 =)

ghost commented 3 years ago

Try this:

echo 04 FF | hexdump -g1 -hc -ho -r > C:\temp\file.hex
aleaksunder commented 3 years ago

Wonderful! Thank you

aleaksunder commented 3 years ago

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?

aleaksunder commented 3 years ago

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.

malxau commented 3 years ago

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 78623d7a9afd288930784f787ca553e421c0472f 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 1ce1b7d1d0f5a7809a8f0d88ce6bbe4b98539930 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.

aleaksunder commented 3 years ago

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.