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

Exactly my view. I'm planning to give a talk about Ruby scripting this year and would welcome any references to the tools that people built with tty. Please get in touch once you have anything to show.

Thanks for you comment! Your feature requests are definitely where I want the library to go so I went and added them to tracker https://github.com/peter-murach/tty/issues as a future reminder. Please feel free to submit more suggestions or PR!

Few people pointed out the broken website to me, I'll definitely fix. I

Sounds interesting! If you come to use the library and have any thoughts or features requirements please post them on the issue tracker.

On another note I suppose, the choice of the interface for a boxing simulator to be cli client is really good for prototyping and is sweet for terminal power users.

I've started TTY library as an extraction from another project. It was born out of necessity to keep things that are generic in another place. Even more so, a lot of TTY library is devoted to supporting table rendering, surprising or not it involves terminal properties detection, ansi strings handling etc...

Thank you for pointing me to Perl library. The only thing I would say is that TTY gem does not have option parser and will probably not have one. Its main concern is more focused on prompting for values than actually providing a way to structure command line interface. There are already libraries that do an excellent job of that. Other features I will have to look individually into. I'd love to have more input on that from yourself.

I have actually recently thought about the dependencies for this library. Originally I wanted to make it easy to vendor things but I have actually started extracting code from this lib as well. For example, the https://github.com/peter-murach/equatable library. So I definitely agree with you and think this is the direction I'm gonna go!

In future I will break dependencies out into smaller components such as tty-prompt tty-table tty-terminal etc... which should help in mixing and matching what you need and the tty gem itself may be just a meta gem that pulls them all in.

I agree, all-in-one proposition is not my style either. From what I can tell the ANSI gem deals only with ansi strings transformations. This library has ansi string coloring but only to support output colorization for the shell.

The tty gem has a rather specific scope, which is to help read data in from command line and display it in some pleasant form such as data table to the user. This library does not deal with parsing command line arguments. There area already awesome propositions out there such as https://github.com/erikhuda/thor or https://github.com/leejarvis/slop to name a few. Basically tty gem tries to fit in the middle ground between gems that are options parsers and complete solutions for structuring command line apps. It is a sort of glue for common tasks based on my experience writing command line apps.

Thanks for the links, I will take a look. The future goal, idea is to create separate repositories dealing with specifics of command line apps. So for instance, in future I'd extract the prompt inquirer to be a separate gem called 'tty-inquirer' or similar.

If you find any issues, or have suggestions then please write up on the https://github.com/peter-murach/tty/issues tracker.

Sorry, I didn't have time to finish the usage page but the following readme should be comprehensive https://github.com/peter-murach/tty

When I see the term ninja, wizard or hacker in a job title it suggests to me that the people recruiting are looking for above average developer. I imagine, the rationale behind that is to do with looking for someone who will bring increased efficiency and productivity by being very intimate with a given technology and deliver value from the start. I am not saying this is the case at all but it seems like a plausible rationale behind such words. However, there is quite a stigma attached to these terms and most of the time the interpretation depends on the context. Many recruiters or companies feel that these terms resonate with developers and work for them like a bait for fish. I would definitely approach them sceptically and seek clarification of what the role involves. Probably the biggest issue with these terms is how do you actually quantify qualities of ninja or someone who has talent? Everything depends on context and these are quite murky waters. Software developer or Web developer as a job title sends much clearer picture of the company recruiting needs.