sitkevij / hex Goto Github PK

In my system, I have also installed installed the helix editor.

• https://github.com/helix-editor/helix

It is currently not yet on Crates

• https://crates.io/crates/helix-editor
• https://crates.io/crates/helix-term

It provides a wrapper that uses the same binary name than hx, which therefore clashes.

Is there a way to assign another name to the binary during build, e.g. hex? Then choosing an abbreviated version remains as simple as creating a symlink.

• add grcov to Makefile

I was unable to install hex because https://github.com/helix-editor/helix has hx.

$ cargo install hx
error: binary `hx` already exists in destination as part of `helix-term v0.6.0 (/home/x/helix/helix-term)`
Add --force to overwrite

The Debian Linux assets are not on the releases page, which should be based on the README.

clippy enhancements found on develop branch #29

$ make clippy
warning: using `write!()` with a format string that ends in a single newline
   --> src/lib.rs:324:17
    |
324 |                 write!(locked, "{}\n", ascii_string)?; // print ascii string
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(clippy::write_with_newline)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#write_with_newline
help: use `writeln!()` instead
    |
324 |                 writeln!(locked, "{}", ascii_string)?; // print ascii string
    |                 ^^^^^^^            --

warning: using `writeln!(locked, "")`
   --> src/lib.rs:397:9
    |
397 |         writeln!(locked, "")?;
    |         ^^^^^^^^^^^^^^^^^^^^ help: replace it with: `writeln!(locked)`
    |
    = note: `#[warn(clippy::writeln_empty_string)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#writeln_empty_string

add cli integration tests to lib.rs and update dev-dependencies.

[dev-dependencies]
assert_cmd = "1.0.1"
predicates = "1.0.5"

• add manual hx --help to README.md

• support tarpaulin for ci/cd

Is your feature request related to a problem? Please describe.

Usually when I'm using a hex editor it's because I'm having trouble parsing or packing something. I often need a quick look at the first n bytes of the file as well as the last n bytes of the file to see if something is wrong with the header or an offset.

If it's a large file, I might try to bisect by picking a random offset and see the general area where the issue reference and test data have become out of sync.

Describe the solution you'd like

I'd love to have a -t <n> option for tailing the last n bytes of a file.

I'd also love a --seek <+/-n> option to complement -l.

Describe alternatives you've considered

For positive or forward seeking I suppose I could use something like dd if=./my/file.bin iseek=100 bs=1 count=2 | hx.

Additional context
N/A

support for NO_COLOR env variable, if found, do not ouptut color.

Is your feature request related to a problem? Please describe.
I'm always frustrated when I try to use hx for a very large file. For example, when trying to load a 3.1 GB binary file, it eventually used up 16 GB of RAM before I stopped the process.

Describe the solution you'd like
I think that a potential solution would involve replacing the fs::File::open with an unsafe memmap call. Just that would probably save a lot of memory usage.

Describe alternatives you've considered
Note that I'm not very familiar with the code at all (just started reading it today). That said, another alternative would be to not append the given line to the page.body for all of the bytes ... and maybe the truncate_len used in buf_to_array should be set to the console's number of lines somehow? The difficulty with that second approach is that at each console refresh, another part of the file will need to be parsed.

Hi, just a heads-up: I added an AUR package for hex.

Describe the bug
Calling hx with the -l or --len argument causes it to hang indefinitely.

To Reproduce
Steps to reproduce the behavior:
hx -l myfile.txt

Desktop (please complete the following information):

• OS: Arch linux

Additional context
Thanks for this great tool :)

If I understand well, at present, the colorization is simply the byte value turned into color:

I wonder if this may be a bit difficult to read (at least, for me, on my machine, with my terminal setup, this is difficult to read).

I was wondering about the following:

• would a "semantic" colorization, i.e colorizing in different ways depending on the "kind" of byte (for example ASCII small letter, capital letter, number, formatting command, "other" binary) help? When I look at some binary dump, I am usually looking for these kind of features, in particular, looking for strings etc

• would it be reasonable to introduce a few different "color themes"? I.e. mapping from "color kind" to "actual color", with a few ones thought for example for solarized dark, tango, etc, and similar "commonly used" themes

What do you think? I may try to find time to come with a pull request if you think this may be a reasonable idea.

Is your feature request related to a problem? Please describe.
Currently, there's no options to disable prefixes like 0x as far as I know.
The hexdump command doesn't show 0x so I can show more digits in a line.

Describe the solution you'd like
It would be better to add an option to disable prefixes.

Describe alternatives you've considered
The option -f, --format could have values to disable prefixes.

Additional context

When used in a pipeline hex will crash if a downstream program exits before hex finishes printing.

To Reproduce

$ dd if=/dev/random bs=512 count=10 | RUST_BACKTRACE=1 hx | head -n 10

10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 0.001144 s, 4.5 MB/s
0x000000: 0x24 0xfc 0xad 0xc8 0x27 0x0f 0x30 0x33 0x45 0x33 $...'.03E3
0x00000a: 0x4c 0x49 0xcc 0x33 0x47 0x9e 0x6d 0x38 0xc6 0x6f LI.3G.m8.o
0x000014: 0x86 0x7d 0xc2 0xd3 0x03 0x31 0xf9 0xbf 0xec 0xa4 .}...1....
0x00001e: 0x36 0x33 0xf1 0x6e 0x8b 0x43 0xe6 0xab 0x7c 0xef 63.n.C..|.
0x000028: 0x52 0xb4 0xdb 0xa1 0x63 0xe8 0x96 0x61 0xd8 0x2b R...c..a.+
0x000032: 0x47 0xc6 0xad 0x86 0x86 0xf6 0x52 0xe3 0x54 0x58 G.....R.TX
0x00003c: 0xfb 0x1b 0x80 0x50 0x79 0x80 0x11 0x31 0xa6 0x72 ...Py..1.r
0x000046: 0x50 0xf8 0x77 0x96 0x50 0x13 0x39 0x17 0xfe 0xc7 P.w.P.9...
0x000050: 0xef 0x40 0x78 0xe8 0xd5 0xfb 0xc6 0x4c 0x62 0x36 [email protected]
0x00005a: 0xd9 0x32 0x18 0xe5 0x1d 0xc5 0xf0 0x95 0x35 0xdf .2......5.
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:822:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: std::panicking::begin_panic_fmt
   8: std::io::stdio::_print
   9: hx::lib::run
  10: hx::main
  11: std::rt::lang_start::{{closure}}
  12: std::rt::lang_start_internal
  13: main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

In this situation head reads 10 lines from hex, prints them, and exits. This causes a SIGPIPE to be sent to hex which crashes. The expected behavior would be to handle the signal, stop printing, and cleanly exit.

Environment

Version: v0.3.0 (installed via cargo install hx)
OS: macOS 10.14.6

• improve cli user feedback when no command parameters present
• provide Makefile for development, build, and release workflow
• cargo fmt all rust code

• warning: the following are not valid category slugs and were ignored: debugging. Please see https://crates.io/category_slugs for the list of all category slugs.
• remove debugging from Cargo.toml category slugs

Is your feature request related to a problem? Please describe.

The hexdump command and many Unix/Linux utilities allow operating on stdin either naturally cat FILE | util or by supplying special file name "-" like cat FILE | util -.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

If file name does not exist and it has name "-", read and process input from stdin

Describe alternatives you've considered

If file name is not supplied, check if there is an input on stdin and process it instead.

Additional context

Since hx is basically filter, those two invocations are the first ones I have tried and none has worked for me. It is not a deal breaker, but it might be considered as lack of polish that will hinder adoption of hx tool.

Especially since in the second case I get panic instead of nicely formatted error message:

$ cat FILE | hx -
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/haku/.cargo/registry/src/github.com-1ecc6299db9ec823/hx-0.2.1/src/lib.rs:223:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

• configure ci.yml

Describe the bug

Passing an invalid filename to hx causes it to crash on a Result:

To Reproduce
Steps to reproduce the behavior:

$ hx toto
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', $HOME/.config/rust/cargo/registry/src/github.com-1ecc6299db9ec823/hx-0.3.0/src/lib.rs:238:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior

I expected the program to tell me I made a mistake.

Desktop (please complete the following information):

• OS: macOS 10.15.7

Additional context

$ hx --version
hx 0.3.0

I'll probably have the time to open a PR for a fix tomorrow if wanted.

It would be nice to be able to compile/install this by making cargo install hex or something similar.

Hello, I was wondering if hex could be used with vim instead of xxd. It would be nice to have the colorized output inside vim.

Feel free to close if out of scope.

• update project in preparation for https://crates.io publish

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
A --length and --address to specify the memory range to print

Describe alternatives you've considered
Less with search is terrible

Additional context
It helps developers

colorize the "error" prefix in main.rs.

• resolve new clippy lint https://rust-lang.github.io/rust-clippy/master/index.html#print_literal
• update README.md

• Consistent --help documentation
• allow only certain values to cli input
• add ability to enable or disable color terminal output
• add 'cargo fmt --all -- --write-mode=diff' to travis build

Thanks for fixing this!

One nit: Generally unix tools don't report broken pipe errors since a tool further in the pipeline exiting without consuming all the output is normal.

See:

$ dd if=/dev/random bs=512 count=10 | xxd | head -n 1
10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 0.000457 s, 11.2 MB/s
00000000: fb7c 0e2c 7e8c 6cd9 da0f 74aa 86b9 2cf6  .|.,~.l...t...,.

Wheras:

$ dd if=/dev/random bs=512 count=10 | hx | head -n 1
10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 0.001642 s, 3.1 MB/s
0x000000: 0x02 0x3b 0x56 0x5d 0xb1 0x9a 0x6e 0xc0 0x3f 0xb0 .;V]..n.?.
error: Broken pipe (os error 32)

Originally posted by @pR0Ps in #23 (comment)

Create a Debian package installation for hex.

Overview https://ubuntuforums.org/showthread.php?t=910717

Debian New Maintainers' Guide https://www.debian.org/doc/manuals/maint-guide/

Context

hx does not sense if stdout is being sent to a terminal, hence garbled term codes are output:

$ cat Cargo.toml | hx | more                                                                                                                                                                
0x000000: ESC[38;5;91m0x5bESC[0m ESC[38;5;112m0x70ESC[0m ESC[38;5;97m0x61ESC[0m ESC[38;5;99m0x63ESC[0m ESC[38;5;107m0x6bESC[0m ESC[38;5;97m0x61ESC[0m ESC[38;5;103m0x67ESC[0m ESC[38;5;101m0x65ESC[0m ESC[38;5;93m0x5dESC[0m ESC[38;5;10m0x0aESC[0m [package].

Solution

Support sensing of terminal (isatty) on stdout.

The Debian Linux assets are not on the releases page, which should be based on the README.

• include sh integration test script