Four joke cron scripts, one of which touches a real database

Each prank hangs off a trigger, not just a timer

The collection is four scripts, and what lifts them above ordinary scheduled jokes is that each is wired to a trigger condition rather than firing blindly. smack-my-bitch-up.sh only runs if there are active SSH sessions on the server after 9pm with the engineer's login, and it sends a late at work text to his wife, picking a reason at random from an array of strings. hangover.sh fires the opposite way: it triggers only if there are no interactive sessions on the server at 8:45am, then sends an email like not feeling well with a random reason drawn from a second array. The cron entries that drive them read like this:

# Runs `smack-my-bitch-up.sh` monday to friday at 9:20 pm.
20 21 * * 1-5 /path/to/scripts/smack-my-bitch-up.sh >> /path/to/smack-my-bitch-up.log 2>&1

# Runs `hangover.sh` monday to friday at 8:45 am.
45 8 * * 1-5 /path/to/scripts/hangover.sh >> /path/to/hangover.log 2>&1

# Runs `kumar-asshole.sh` every 10 minutes.
*/10 * * * * /path/to/scripts/kumar-asshole.sh

# Runs `fucking-coffee.sh` hourly from 9am to 6pm on weekdays.
0 9-18 * * 1-5 /path/to/scripts/fucking-coffee.sh

Notice that the two text-message pranks get a weekday window while the database script gets polled every ten minutes, because a keyword might arrive at any hour. Each script therefore reads the server's own state to decide whether the joke is currently true, which is the one sharp engineering idea hiding inside the humour.

kumar-asshole.sh is the only script that reaches a real system

Of the four, this is the one with actual teeth, and the one to read twice before pointing anywhere. It scans the inbox for email from someone called Kumar, a DBA at one of the clients, watching for keywords such as help, trouble, or sorry. If it finds them, the script SSHes into the client's own server and rolls back the staging database to the latest backup, then replies no worries mate, be careful next time. The consequence for a reader is immediate and different from the other three. The coffee and text-message scripts touch only a phone and a telnet socket, but this one reaches over SSH into someone else's infrastructure and reverts a database. It is a punchline about a runaway build engineer, not a tool.

The coffee script is a 17-second timer and a telnet handshake

fucking-coffee.sh is the most self-contained of the set and the one with the most quotable numbers. The story is that nobody had realised the office coffee machine was on the network, running Linux, with a TCP socket listening. The script waits exactly 17 seconds, opens a telnet session to the machine, and sends something like sys brew, which starts brewing a mid-sized half-caf latte, then waits another 24 seconds before the pour into the cup. Those two waits are not arbitrary: together they match how long it takes to walk from the engineer's desk to the machine, so a finished cup is waiting when he arrives. It is a genuine networked-device automation demo dressed as a joke, and the timing is the whole payload.

Every script needs live Twilio and Gmail credentials to run at all

None of this works without real credentials, which is the first practical thing to understand before you run anything. The text-message and hangover scripts depend on Twilio, configured through TWILIO_ACCOUNT_SID and TWILIO_AUTH_TOKEN, while the Kumar script reads a mailbox through GMAIL_USERNAME and GMAIL_PASSWORD:

# used in `smack-my-bitch-up` and `hangover` scripts
TWILIO_ACCOUNT_SID=ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TWILIO_AUTH_TOKEN=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

# used in `kumar_asshole` script
[email protected]
GMAIL_PASSWORD=password

A committed .env.example holds those four variable names with placeholder values, and its header tells you to set the variables or copy the file into a .env, pointing at the dotenv library. For the Ruby versions the instructions also have you install the matching gems with `gem install dotenv twilio-ruby gmail`. The consequence is that these scripts are not harmless to fire casually, because pointing them at your own Twilio and Gmail will send real messages and read your real mail.

The joke has been ported to more languages than it needs

What began as two original implementations, the .sh and .rb files sitting at the top level, has been reimplemented across a striking spread of language directories: CSharp, R, clojure, coffee, go, groovy, java, kotlin, nodejs, perl, php, powershell, python, python3, and scala. The project explicitly invites pull requests carrying other implementations in Python, Perl, Shell, and the like. This is the point where the joke turns into a breadth exercise rather than a utility. Fifteen or so ports of a text-message prank is not a case of picking the right tool, it is a case of the community enjoying the bit. The practical consequence is that no port carries the maturity or the test coverage a tool you would actually depend on would have, so treat every one of them as a curiosity. The spread also says something about the audience, since a joke that ports cleanly to PowerShell and to Clojure is a joke about the shape of shell scripting rather than about any one runtime. Nothing in the tree suggests one port is the reference implementation and the rest are ports, which leaves a reader without a clear place to start.

The last commit was 2023, so nothing here is maintained

The repository is not archived, but the last push is dated 2023-10-23, well over a year before now. That fact matters more than the not-archived flag, because it means no script here has been touched in a long time and none should be expected to receive a fix. The code is released under the WTFPL, the licence famous for its deliberately unserious and permissive wording, which fits a joke collection and carries no warranty of any kind. The consequence for a reader is that this is a finished anecdote preserved in code, not a maintained utility. If you want a dependable SMS sender or a database rollback tool, use a real one. If you want to understand the shape of trigger-based cron automation, four compact scripts make an unusually clear lesson.

The code is a prop, and the story is the point

The repository exists to preserve one true anecdote about a build engineer who lived inside the terminal, loved Vim, drew diagrams in Dot, and wrote wiki-posts in Markdown. His rule was simple and is the thesis of the whole collection: if anything took more than 90 seconds of his time, he scripted it. The four pranks are that rule applied to the everyday indignities of a sysadmin's week, and the README tells the story in full before it shows a single line of code, tracing it back to a bash.im quote with a link to an archived copy of the original. The consequence is that the scripts are deliberately incomplete props, not a coherent toolkit. There is no installer, no test suite, and little error handling, so the humour is the load-bearing part.

Editorial conclusion

Read hacker-scripts as a sysadmin satire and as a compact lesson in trigger-based cron automation, which is what it is good for. It is not a tool to adopt: the database script acts on real infrastructure, every script needs live Twilio and Gmail credentials, there is no installer or test suite, and the last push was 2023-10-23. If you only want the jokes, clone it and read the README. If you want a working tool, build one and keep the WTFPL code as a reference.

Frequently asked questions

Official sources

1. Official README
2. Project repository