Converting software that runs on a GUI to run through the command-line

[Ciro Santilli (***) OurBigBook.com sponsor me: ************.com/sponsor, opinions my own 2020冠状病毒审查 ，2020*** ，2018**改造中心，1989**事件，1999**功 ，2019 996.ICU, 2018包子露宪，2015 709大抓捕，2015巴拿马文件 ***，2017低端人口，2008西藏**<script>alert(1)</script>]

https://stackoverflow.com/questions/17284554/converting-software-that-runs-on-a-gui-to-run-through-the-command-line/17285171#17285171

Your input options in order of increasing complexity are:

• read argv and argc manually for inputs for which the user needs no extra information to give. Ex:

    app 1 2 3
  

  You can use this if you want to allow users to enter either value 1, value 1 and 2, or value 1 and 2 and 3, but not if you want to allow users to enter, say, only value 2.

• parse argv and argc with some library if the input may be more complicated.

  Many libraries will parse POSIX/Gnu conventions for you. Ex:

    app -i 1 --input 3
  

  so that those libraries will easily allow you to recover i and input gotten from the command line, which would be very annoying to do manually.

• if the user must have feedback from the app before giving more input, consider a REPL interface using functions such as fgets and getchar. Ex:

    water animal or earth animal? (w/a)
    > w
    dolphin or shark? (d/s)
    > s
  

  Here the program needs to know what type of animal before giving the animal options.

• if you want the user to move around in a menu-like dialog use a curses library. Ex:

    - water animals [selected]
    - earth animals
  

  after a down keypress:

    - water animals
    - earth animals [selected]
  

  after a right keypress:

    - water animals
    - earth animals
        - dog [selected]
        - wolf
  

  after an enter keypress: application receives dog value.

For the output you can:

• output output to stdout (printf) and user messages to stderr (fprintf(stderr,"")).

  This is the most flexible options, since users can then pass output to another application easily to be further processed without creating a file.

  Also, you an separate stderr from stdout so that the next application won't read user messages asking for input.

• write to a file.

  This is more restrictive than outputing to stdout since it is simple to redirect stdout to a file (app > file in Linux), but might be an option spcially if output is large, and if you thing users will always want to put output on a file.

I don't know about CRC, but for file checksums for example, if you have no options (a single type of checksum), you should just read the filename from the argv / argc manually and print the checksum to the stdout. If there are many options (checksum parameters), consider using a library that parses those options for you.