kaitai-io / kaitai_struct_visualizer

Kaitai Struct: visualizer and hex viewer tool
https://rubygems.org/gems/kaitai-struct-visualizer
GNU General Public License v3.0
280 stars 25 forks source link

Support for creating a new console/shell to render text in? #32

Open ams-tschoening opened 4 years ago

ams-tschoening commented 4 years ago

The problem.

Running the viewer within an already existing console or shell is easy and text is simply rendered within that. But I'm running the viewer using launch configs of Eclipse as well and in that scenario things either get output to the console provided by Eclipse or one needs to take care of creating an additional console manually.

The problem with the Eclipse-console.

The problem with the console of Eclipse seems to be that while it is able to print STDOUT, STDERR etc., it doesn't seem to support real textual UIs like used by ksv. After executing a launch config only calling ruby itself directly, some debugging output gets printed and the process seem to halt afterwards. It doesn't terminate as well, it simply doesn't seem to do anything anymore, which can be seen at the red terminate-button on the right.

Eclipse console

Eclipse launch config w_o console

The problem with creating a custom console in the launch config.

While creating an additional own console within the launch config is possible, things get complicated if one wants do use that launch config under Linux and Windows at the same time, because both use different default shells. What I'm currently using on Windows is the following:

Eclipse launch config with console

That starts a new cmd.exe to actually only start another cmd.exe to start the process with all its arguments in a new console. Two cmd.exe were necessary to forward all individual args properly. Additionally, ComSpec maps to cmd.exe on Windows, but is not known on Linux, while SHELL is known on Linux but not on Windows and stuff like that.

Some ideas for workarounds.

  1. Two launch-configs of course, but especially because the arguments, settings for environment variables etc. are OS-independent already, would be great if one could avoid this.

  2. Would be great if one could tell ruby.exe itself to create a console. But didn't find any arguments in this direction.

  3. Issuing a system call using ruby -e '', because system maps to local shells mostly. The problem is that when using paths like I have in my Eclipse launch config, that those sometimes map to \ and sometimes to /, with the former introducing syntax errors for the system call. Those would need to be \\ in code.

  4. Add creating a new console in console_*.rb, but I don't know if that is possible at all in non-Windows. Windows supports the following calls to create a new console:

    def initialize Win32API.new('kernel32', 'FreeConsole', []).call() Win32API.new('kernel32', 'AllocConsole', []).call()

But rendering output to that new console didn't work properly yet, I guess because of problems with what STDIN/STDOUT is when.

  1. Using -r to load some text actually creating a console only, which makes things easier than to use -e and a long system-call.

  2. Adding a new argument like --new-console to recall the app using system with all given arguments, but without --new-console. Pretty similar to --version is handled currently, but system seems to only create a shell in case of a command line and that to build might be OS-dependent again because of how cmd.exe handles quotes and stuff. Didn't get a quick PoC to work as well:

    opts.on("--new-console [BOOLEAN]", "Recall with a newly created console. MUST BE FIRST ARG!") do |v| if v system($0.prepend('"').concat('" "').concat(ARGV.join('" "')).concat('"')) exit 0 end end

Any other ideas?