That's not the case at all. Every process produces an exit status when it terminates and many things besides interactive shells use them. Pretty much anything that runs a subprocess should retrieve the exit status to see if the child process was successful and log the failure if nothing else.
Some random examples: Automated build systems like Jenkins typically use the exit status to decide if a build task has succeeded. `make` also uses exit codes to decide if a child task has succeeded and may abort the rest of the build based on that and return an exit code itself. A local mail delivery agent like maildrop may return different exit status depending on if it's a permanent or temporary failure and the mail transfer agent decides if it should retry the local delivery based on that. The exit status of a Docker of Kubernetes container is usually based on a process exit status too.
You're right. However, I'm also extending the set of exit codes with Bash recognised statuses[1]. This also includes a list of fatal signals, e.i. exit codes 128 + n, where n is a corresponding signal error.[2]
In this context "Do not use them.", these are reserved codes and shouldn't be redefined in your programs to mean something entirely different. So codes in range 64-78 are a standard across Unix systems. Usually, specific program codes are best served using codes below 64.
I have included a method that helps you check if a code is reserved or not. For example, TTY::Exit.exit_reserved?(126) will return true as this is a status used by Bash to indicate a problem with executing a command.
* It includes default user-friendly error messages for all the built-in exit codes. For example, the code 64 will print " "ERROR(64): Command line usage error" to stderr.
* Machines, e.i. programs that, for example, watch over an executable can decided based on the error code what to do. If the program is interrupted by Ctrl-C then the parent program can handle the situation gracefully.
I totally agree that an example of using an exit code in a parent program would be beneficial.
I don't know if Tesla has any computers to license. My understanding is that nVidia makes the computers inside Tesla vehicles (the X1 product for infotainment, and the DRIVE product for self-driving).
I think John Deere is perfectly fine using something that is proven to work. I can't imagine anyone wanting to tie themselves to Tesla's software at this stage of the game.
Many systems come preinstalled with Ruby. Bundler is a very elegant and simple solution - I don't think it is hostile. Quite often the tools that we build are written by developers for developers or system administrators. For example Puppet or Chef. In my experience, these are people how don't mind running couple commands to get started. If anything I have heard people say really positive things on how easy and pain free installation is. Of course, if you want to write portable code that works on any system then Go is a very wise solution.
As always this depends. In principle I agree for example I wrote pastel-cli(https://github.com/piotrmurach/pastel-cli) that doesn't use any parser to figure out arguments. However, it's super basic, for anything more complex I would look for more powerful parsers. Lexing command input as much as it is fun can be very thorny issue.
The choice of not writing options parser was very deliberate. As much as it is a tempting proposition I believe there are already great tools around. TTY attempts to provide glue to stitch a lot of scripting needs together without opinionated view on how they should be structured - for now at least ;-)
In my scripting experience I tend to gravitate towards two solutions. If my script is fairly small, e.i. in a single file, with no much complexity I tend to use Ruby standard library optparse. However, if my needs get a bit more complex and I need, for example, subcommands I use thor. Thor gives me a better way to structure my application logic. These two solutions so far have covered all my needs.
My recommendation before using other libraries would be to really give optparse a good spin so that you can figure out why the other options are more suitable.
Very interesting. I haven't considered mruby but it makes perfect sense. Though I don't know how the situation looks like with regards to standard library? A lot of tty packages use esoteric stuff from Ruby standard libraries including ffi or console modules.
There is still plenty of scripts that I write that are geared towards development workflow. I haven't had issues on setting up these tools on Debian servers, Ruby is usually preinstalled and all you need is bundler to get what you need.
I was aware of many progress bar libraries before writing tty-progressbar. The reason I ended up coding my own was to have a dead simple codebase - literally one file that does the job well. This makes it easy to maintain and receive contributions. In addition doing job well meant very extensible way to format the progress display, virtually a string with tokens.
