Text-only programs are easy to use. There's no excuse not to make a bit of effort to learn how to.
Let's say you have a command-line tool you want to run.
For example, CUE's RSEARCH.
According to its documentation, and trying to run it the wrong way, the usage is something like this: RSEARCH filename text [min [max [inc]]]
Since min, max, inc are optional, we'll do without them, and then you have just one argument (text).
This tool analyses a text file and generates a table file.
Let's call it text.txt for this example. That's what filename is supposed to stand for.
To make things simple, we'll have it in the same folder as the tool.Method 1: Learn how to use the Command Prompt
Press Windows+R, type cmd
The scary black Command Prompt window will appear.
Type this: CD "C:\etc\caetera\Folder_Where_Tool_is" /D
and press Enter.
You may not even have to do this step, just right-click on the folder where the tool is, while holding Shift, and the contextual menu will have "Open Command Prompt Here".
Now type the tool's name. For example here: RSEARCH.EXE
It's probably not the correct way to use it.
The tool's author will have some extensive help here usually about how to use it.
That's where I got the usage tips above from.
Now in the command prompt type this: RSEARCH text.txt
And that should be it. Really.Method 2: Batch files
Open Notepad, and write this:
Save this text file with the extension bat in the same folder as the tool and the text file.
Now double-click that bat file. That's it.Method 3: Console Compromise
A tool that can be downloaded from https://www.romhacking.net/utilities/1284/
You get to use any command-line tool as a GUI tool, even though it's a bit pointless.
You pass the path for the application, and the arguments (here it's just filename).Method 4: Drag-and-drop
If it's a simple tool, sometimes dragging the file to be converted on top of the tool's executable is enough. For example, the UNECM tool to decompress some PS1 scene releases.
Unfortunately, you'll miss any messages displayed by the process, errors or information, because it will close immediately whenever it's done. That's how it is with every modern day Windows OS. But sometimes this is good enough.
If there's a will, there's a way.
I used to hate command-line, but realized they're much more preferable to GUI tools, especially for operations that need to be repeated for hundreds of files (text insertion with Atlas for multiple files, with multiple insertion methods, or mass converting graphical files) and this would mean clicking hundreds of times on a button instead of copy-pasting a line in the batch file and running that once
Making a GUI is extra work. You do realize that people making tools code them just enough for their personal use to do the job, and then share it if they feel like it? Sometimes it's not even a proper program, but a bmg script. If it's good enough to do the job, why bother adding a GUI that wouldn't be needed in many cases at best, and a hindrance at worst.
That said, there are some tools that could benefit from a GUI, like the aforementioned RSEARCH which is superior in every other way to monkeymoore but could use some GUI options to make copy-pasting text, writing Japanese text, and editing table files on the fly possible, as well as better logging for the search process. Same goes for many MTE dictionnary optimisation/generation tools. These kind of tools need that visual feedback.
On the other hand, conversion tools, compression tools (which you need the offset for the data to use anyways), etc... these definitely don't need the extra development time on just one simple yet time-consuming GUI with "Select File" and "Convert".
LunarIPS is one such GUI, but that was done to cater to the needs of the general consumer, and even that one has had its later versions move on from that GUI to just directly selecting the files.