Open-source project
oldratlee/useful-scripts avatar
oldratlee/useful-scripts

useful-scripts: a Bash toolbox for the terminal plus three scripts for Java classpath pain

🐌 useful scripts for making developer's everyday life easier and happier, involved java, shell etc.

7,516 stars2,786 forksShellApache-2.0

At a glance

What is it?
A Shell-first grab bag of Bash 3.2+ helpers for everyday command line work, alongside three scripts for Java CPU and classpath problems. Apache-2.0 licensed and still pushed in 2026, but the newest tag is a work in progress alpha and the one-line installer executes a fetched file inside your current shell.
Who is it for?
Treat it as a toolbox you read before you run, not a dependency. The Shell side is small Bash 3.2+ you can inspect a line at a time, and the three Java scripts pay off when top shows a hot process or a class conflict appears out of nowhere.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 148 days ago.
What is it written in?
Mainly Shell, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.

From daily snapshots

Star history

  • oldratlee/useful-scripts7,516 ★ · -2
Star history
Repository2026-09-222026-11-14
oldratlee/useful-scripts7.5k7.5k

-2 Stars in the last 53 days, measured from the daily GitHub snapshot. Compare with other projects

Editorial analysis

The install one-liner fetches from release-3.x while the default branch is dev-3.x

The first thing the project offers is a single line that fetches a file and runs it in the shell you are already sitting in:

bash
source <(curl -fsSL https://raw.githubusercontent.com/oldratlee/useful-scripts/release-3.x/test/self-installer.sh)

Four details in that line deserve a second look. The `<(...)` process substitution feeds the fetched text straight into `source`, so it runs in your interactive shell rather than in a throwaway subshell. The URL names the `release-3.x` branch, while the branch you land on when you open the repository is `dev-3.x`, so the code you read is not necessarily the code you just ran. The script lives under `test/`, the directory where the project keeps its test material. And the command carries no checksum and no version tag, so what executes is whatever that branch holds at the moment of the request. The project names `docs/install.md` as the place for the other download and usage methods, which is the route to take if you want to see the rest of the options first.

show-busy-java-threads prints stacks for the threads the OS already blamed

`show-busy-java-threads` exists to answer one narrow complaint: the CPU column in `top` is high and nobody can say which method is responsible. It works through the chain from the outside in. Running Java processes are found, the ones consuming CPU are singled out, the threads inside those processes that are consuming CPU are identified, and their thread stacks are printed so the call site behind the number becomes visible. The printed stack is the payoff. A process name and a percentage tell you very little on their own, whereas a stack gives you the frame to look at next. The scope is just as narrow. The trigger is CPU consumption, so a service that is slow because it is blocked on I/O, starved for memory, or waiting on a lock is not what this script points at.

show-duplicate-java-classes and find-in-jars only see the directory you pass

Two more scripts work at the classpath level. `show-duplicate-java-classes` finds duplicate classes across jar files and class directories, which is the shape a class conflict takes when the same class name exists in more than one artifact and you cannot work out which one loads first. `find-in-jars` searches for a class or a resource file inside every jar under a directory. Both are scoped to the path you hand them, and that is exactly where they stop helping. A duplicate only shows up if every copy involved sits inside the scanned path. A jar living in a shared library directory or a mounted image stays outside it, and a conflict driven by something you never scanned never appears in the output. Read a clean result from either script as a narrowing of the search rather than an all clear, or you will end up restarting a service that still has the wrong class on its classpath.

uq drops duplicate lines without the sort uniq needs

`uq` is the entry with the clearest reason to exist. The system `uniq` only collapses adjacent duplicate lines, which means the input has to arrive sorted and the order has already been rewritten by the time you read the output. `uq` deduplicates whole input lines without reordering, and it does not need the input sorted, so first seen order survives. The neighbours in the same group are about reading rather than filtering. `a2l` prints its arguments colored line by line so a long value list is separable by eye. `coat` and `taoc` are colored `cat` and `tac`, printing file lines in color so a person can tell one line from the next. `c` prints command output as it is and also copies standard output to the system clipboard, removing the select and copy step. That last one only pays off where a system clipboard exists to paste from later, so it reads as a desktop habit rather than something portable to a bare terminal.

ap, rp, xpl and xpf move path work in and out of a file browser

`ap` and `rp` convert file paths between absolute and relative in bulk, and the detail that matters sits in how they are described: they follow links and normalize the path along the way. That is convenient for batch work, and it also means the string handed back to you may not be the string you typed. `xpl` and `xpf` take the idea in the other direction. From the command line they open or select a named file or folder inside a file browser, and the stated goal is to smooth the flow between the command line and other applications. The tradeoff is that coupling. Work which used to finish inside the terminal now finishes in a separate window you must have configured, find, and switch to, and on a host with no file browser at all the step has nothing behind it.

cp-into-docker-run and tcp-connection-state-counter both read the host

`cp-into-docker-run` copies an executable from the local machine into a specified `docker` container and runs it there. The word specified does the load bearing work. The container is one you name, which means one you already have; this is a copy and execute step, not a create and start step. If that container is not running, or the name you give does not match, the failure has nothing to do with the script's own logic. The other utility in this group looks at the machine instead of your files. `tcp-connection-state-counter` counts how many connections sit in each TCP state, and its documented purpose is judging whether the system is carrying too much connection load. A set of state counts tells you the pressure is real. It does not name the process holding those connections, so you still have to identify the owner yourself before you can stop anything.

echo-args, console-text-color-themes.sh and parseOpts.sh are for script authors

The last group is aimed at people writing scripts rather than running them. `echo-args` prints the arguments a script received, and when you run it in a console it renders the brackets that surround argument values in red, so a missing quote or a stray space shows up as a boundary you can actually see. `console-text-color-themes.sh` displays every text color combination `Terminator` offers along with the way each one is printed, which serves as a reference while writing colored output. `parseOpts.sh` is a command line option parsing library, and its stated addition to ordinary behavior is support for an option that takes multiple values, in other words arrays. Worth noticing what the color tooling assumes: the theme file is built around `Terminator`, so a palette you verified there is not automatically the palette another terminal hands you.

Bash 3.2 is the floor, and the 3.x line has no stable tag

Every shell script in the collection targets Bash 3.2 or newer, and the reasoning given is practical: Bash remains the mainstream shell and is present by default in most environments, Google's shell style guide names it the only language allowed for shell scripts, and standardizing on one shell avoids the differences between sh, bash, zsh, fish, csh, tcsh, ksh, ash and dash. A host that offers you only dash or ash cannot run the Bash scripts. Maintenance deserves the same careful reading. The repository is not archived and the last push is dated 2026-06-19, yet the newest tag is v3.0.0-Alpha from 2024-04-15, labeled a work in progress and cleanup release, ahead of v2.5.4 from 2024-04-12 and v2.5.3 from 2024-02-18. There is no stable 3.x to pin, so v2.5.4 is the newest release not marked as work in progress, and the default branch dev-3.x carries roughly two years of commits past it. The project also states that scripts such as the Java ones are deployed in online production at companies including Alibaba, and asks those companies to say so through issue 96.

Editorial conclusion

Treat it as a toolbox you read before you run, not a dependency. The Shell side is small Bash 3.2+ you can inspect a line at a time, and the three Java scripts pay off when top shows a hot process or a class conflict appears out of nowhere. Skip it if you need a supported release to pin, because the newest tag is a WIP alpha. Before anything touches production, check the installer line you are about to source and the release your clone actually points at.

Frequently asked questions

What are examples of scripts?

The Java group holds show-busy-java-threads, show-duplicate-java-classes and find-in-jars. The Shell group holds c, coat, taoc, a2l, uq, ap, rp, cp-into-docker-run, tcp-connection-state-counter, xpl and xpf, and the script author group holds echo-args, console-text-color-themes.sh and parseOpts.sh.

What is a good script?

The project's answer is rigor rather than novelty. All shell scripts target Bash 3.2 or newer, Bash is treated as a production language, and the project points at ShellCheck as a static analysis tool and shfmt as a formatter.

What are good script ideas?

The ones already here answer it: copying command output to the system clipboard, deduplicating lines without sorting them first, converting paths in bulk while following links, and printing thread stacks for the Java processes burning CPU.

What's a fun script?

The self-installer is the playful entry. One sourced line pulls test/self-installer.sh from the release-3.x branch and runs it in the shell you are already in, and docs/install.md is named as the place for the other download and usage methods.

Official sources

  1. License: Apache-2.0
  2. oldratlee/useful-scripts on GitHub
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/oldratlee-useful-scripts.svg)](https://hysenlabs.com/projects/oldratlee-useful-scripts)

Star history chart for your README

markdown
[![Star history](https://hysenlabs.com/chart/oldratlee-useful-scripts.svg)](https://hysenlabs.com/projects/oldratlee-useful-scripts)

Was this useful?