[q3k]

I don't really get why this is a TUI. Any time I actually hack on this sort of stuff, I'd rather have the outputs (eg. symbols, ELF sections/segments, strings, ...) directly on stdout so I can then further filter stuff or otherwise process it. Especially strings!

The only part of this tool that seems to merit a TUI is the hex view...

[IggleSniggle]

Sometimes you really want to make a TUI videogame but can't think of a good roguelike design so you just start hacking away at what you're curious about.

I can see this tool being a fun introduction to many things you would normally want to keep as separate tools you can glue together, and was probably also just a chance for them to exercise the TUI library they also created.

[mtndew4brkfst]

The creator is a maintainer of a major Rust library for writing TUI applications, so it's almost certainly a just-because rather than something that is intuitively or practically better as a TUI.

[mtndew4brkfst]

I should add - the fact that he dogfoods the library so frequently has no doubt improved the library a ton even if he never produced anything useful, which isn't true either. I'm glad he does so.

[Vegenoid]

One of the biggest benefits of a (good) TUI (or GUI) is that it guides someone who doesn't already know exactly what they want to do towards the most relevant information and the most common actions. Once you already know these things, it is usually faster and more powerful to work with code instead. With this TUI, someone who doesn't know very much about the internals of a binary gets that information presented them in a way that helps them learn the parts of the file, and their relations and relevance.

It is also easier for many people to remember how to navigate a GUI/TUI to achieve a task than to use the CLI, likely because it makes use of the parts of our brain for navigating space. This often makes them easier to use for tasks that you only do occasionally (at least until you learn how to take good notes, manage snippets, and work with your shell history).

So why a TUI instead of a GUI? Probably mostly for aesthetic and comfort reasons than for utility reasons - but I prefer staying in the terminal if possible, as I have a lot of control over its appearance and behavior, and TUIs generally have much better keyboard support than GUIs.

[wkat4242]

> So why a TUI instead of a GUI? Probably mostly for aesthetic and comfort reasons than for utility reasons - but I prefer staying in the terminal if possible, as I have a lot of control over its appearance and behavior, and TUIs generally have much better keyboard support than GUIs.

Also it is much easier to run remotely and doesn't need half a gigabyte of dependencies making it easier on a VPS etc

[darby_nine]

> It is also easier for many people to remember how to navigate a GUI/TUI to achieve a task than to use the CLI, likely because it makes use of the parts of our brain for navigating space

I'd be very very surprised if this were true for everyone. I'm certainly more symbol oriented than visually or spatially oriented, for instance, and the ways I AM spatially oriented doesn't map at all to common user interface elements.

Besides, many of the best interfaces (eg magit) aren't spatially oriented at all.

That said, I'll never complain at more interfaces even if I do prefer a query-and-response style interaction.

[neomantra]

Great reply about TUI/GUI vs CLI! Well-designed TUIs help teach and navigate the mental model of a situation. I try to also have a CLI available for the TUI that helps extract data for terminal pipeline use. You can even have the TUI tell you what the CLI command would be.

> So why a TUI instead of a GUI?

Also, TUI is available in constrained environments and over SSH/serial.

NB: the author's GitHub contribution graph is pure green for several years! https://github.com/orhun

[mtndew4brkfst]

You can even have the TUI tell you what the CLI command would be.

Most of the weird corners I know about Git workflows are because Magit offers the ability to explore via TUI but then see the literal command being run.

[exe34]

does this offer a programming api? what I think is the sweetest approach is if there's a tui/gui to explore and find what you want, and then click a button and have it dump a bunch of code that would achieve the same thing - so now you can play around with the api instead.

[fuhsnn]

"llvm-readelf --elf-output-style=JSON | jq" is handy.

[szszrk]

Push it through jless and you just made a great TUI for that :)

[wwader]

Nice haven't seen. Shameless plug fq support elf https://github.com/wader/fq and will have a look if i could lend some ideas from llvm-readelf

[q3k]

That's a neat trick!

[MSFT_Edging]

Sometimes you find yourself looking for a piece of info over and over again, and you'll lose something in stdout you think you'll remember as you do further analysis.

Ie for this, switching between readelf and objdump options, a handful of operations are already getting you 1000 lines into scrollback. I imagine having one terminal with this up and pre-parsed could be useful on the side while doing other analysis.

[Retr0id]

I always forget the precise flags for readelf/objdump etc., and in practice I do something like `readelf -a | less` and scroll until I find the info I was looking for. Scrolling around in `less` is pretty cumbersome for large outputs, and I wouldn't mind a TUI for it.

(I also forget the difference between a segment and a section, but I know what I'm looking for when I see it, heh)