2211

I'm working on a guide that will cover the entire process of creating a terminal user interface in bash. I want to create a central location for the information I've gathered so it may be of benefit to others.

I also hope that people will contribute their own snippets, methods and ideas. It'd be great to find out if there are better ways of implementing the code.

The guide is on GitHub [0] and is a heavy work in progress. Its currently structured in a way I'm not too happy with. I want to change it to a series of 'How to implement x' instead of an ever growing implementation.

Other than the TUI guide I have 4 other major projects which I am working on (neofetch, pywal, fff and the Pure Bash Bible).

[0] https://github.com/dylanaraps/writing-a-tui-in-bash

You could probably pull it off in POSIX sh if you basically made a file manager TUI around 'ls' (this isn't a bad idea actually). ;)

There's no library to handle all of this for you ('ncurses' etc). It has to all be done manually by hand. This involved scouring through VT100 and other terminal manuals to figure out escape sequences and other terminal behavior. Also the installation of something like 30~ terminal emulators to make sure the escape sequences behaved everywhere.

I stuck to VT100 sequences (which are supported pretty much everywhere nowadays) with the exception of 1 or 2 newer sequences (which are ignored in older terminals and not required). I didn't want to use 'tput' since it would add the dependency of 'ncurses' and it would slow the program down quite a lot. Each 'tput' call is an external process which adds '10-15ms' to the program per call.

I also ran into some funny bash behavior. The main loop waits for user input (with 'read') and if the script received a 'SIGWINCH' signal that ran a second 'read' asynchronously, it would break the terminal.

The other big issue is you can't write anything widely portable in bash without supporting bash '3.2+' (which is over 10(?) years old at this point). macOS is forever stuck on this version due to Apple's issues with GPLv3. This means useful features like associative arrays, 'declare -n' etc are unavailable for use.

Other than these issues it wasn't that difficult to pull off. It was a lot of fun actually!

Thanks, that's the idea. The project is still young so don't hesitate to bug me with issues etc. I'm sure you'll come across some. :)

I can very easily add optional support for either 'fzf' or another fuzzy matcher. I'll take a look at implementing this in pure bash but I doubt it'd match the speed of a dedicated tool in this instance.

The current search is just bash creating an array using a glob 'list=(/path/to/current_dir/"$search_query")'. bash gets a lot slower when you start adding more levels to the search (2 or more deep).

I'll get to implementing fuzzy searching algorithms first and we'll see what steps I take from there. Who knows? It might work fast enough in pure bash for file searching.

I use the search feature to quickly navigate through directories. I have 'CD on exit' configured as well so I can quit 'fff' and I'm in the new directory ready to type commands.

I also like that I can hit 'l' (or enter) to open files and I don't have to think about what program I need to use to open them. Text files are handled by '$EDITOR' and everything else is opened through mime-type using 'xdg-open' (which is configurable to your opener of choice).

The entire program was rewritten and the source is now highly readable. The rewrite also made features like 'LS_COLORS' support possible. A lot of optimization was done and the program no longer redraws the entire screen per key-press[!].

For those wondering "Why bash?"; I wanted something I could 'wget'/'curl' on other machines that would "just work". The program only requires 'bash 3+' and a POSIX compliant 'coreutils' to function. Also, it's really fun to push bash to its limits!

I'm the developer, happy to answer any questions.

Note: I noticed this has been posted before so I added a '#' to bypass the filter. I think this merits a re-post as the project is 100% different to how it was before. The old program was 100~ lines of obfuscated spaghetti and the new program is around 700~ lines of commented "well structured" code.

This is something I've put together over the past couple of days. It's still a work in progress but I'm posting it here to get some critique and hopefully some contributions.

I'd love to see what others come up with. If you'd like to contribute take a look at the CONTRIBUTING.md file.

https://github.com/dylanaraps/pure-bash-bible/blob/master/CO...

I wrote this yesterday so it's a WIP but it's fairly complete. It's a tiny pixel art editor for your terminal. There's a screenshot in the link above so check it out.

- Vim hjkl movement.

- Supports 256 terminal palette.

- Supports true color terminals (all hex colors).

- Draw with any character or string.

- Save and load "screens".

- Open regular text files for editing.

- Responsive on window resize.

It's all pure bash minus a call to `stty` if the hack to get terminal lines/columns in pure bash fails. I also need to figure out a way to export to an image file. Right now when you save/load a "screen" it just logs all key-presses to a file.

Mess around with it and let me know when you break it. :P

For those interested in how far the project has come, here's the first version of Neofetch (previously called fetch.sh).

https://github.com/dylanaraps/neofetch/tree/90130a7e0763bffd...

Disclaimer: I'm the author of the project and have been working on this for around 3 years now. The project has grown from supporting only Arch Linux to supporting over 150 different Operating Systems and Distributions.