pmurach

Exit codes are only used in the context of terminal shells. So it seems appropriate to refer to terminals. Wouldn't you agree?

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]

[1] http://tldp.org/LDP/abs/html/exitcodes.html [2] https://man.openbsd.org/signal.3

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.

This library improves the situation as:

* 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.

Unfortunately, the majority of these projects are just forks of well-established ones without any contributions.

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.

Other solutions that I've played in the past are:

* main - very sweet DSL (https://github.com/ahoward/main)

* clamp - (https://github.com/mdub/clamp)

* slop - (https://github.com/leejarvis/slop)

* gli - for Git-like interfaces (https://github.com/davetron5000/gli)

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.

Regarding tty-table, I have number of things planned including different renderer types to account for more esoteric formats and also very simple formats like tsv(table separate values) etc...