shownotes: a personal archive of Linux shell scripts and config notes

This is a notebook for a YouTube channel, not a tool with an API

The description of the repository is one line: notes for videos from my youtube channel. The primary language is recorded as Shell, and the licence is GPL-3.0. Everything else follows from those three facts.

What lives here is a large set of small shell scripts, plain text notes and configuration snippets that were written for, and shown in, terminal tutorial videos. The audience is therefore two groups. The first is the author himself, who needs the working commands to hand when recording. The second is anyone who watched a video, wanted the exact command, and would rather read the file than retype it from a video frame.

There is no command line interface to learn and no API to call. There is no installer, no package manifest, and no configuration schema. The unit of reuse is a file, and the value of a file depends entirely on whether it does the thing you were about to type yourself.

This is worth saying plainly because a repository with many small files and a GPL badge can look like a software product. It is a personal archive with a public URL. Adopting it means reading and copying, not installing.

The tree is a flat catalogue of scripts, notes and dotfiles

The repository layout is the fastest way to understand the project, and it is flat by design. The top level is a long alphabetical list of files, mixing three kinds of content without a clear partition.

The first kind is executable shell scripts, each doing one self-contained job. Visible examples include any_term_dropdown.sh, aerosnap_script.sh, blocklist.sh, clipboard_removeformatting.sh, custom_actions_archive_mounter.sh, custom_actions_discimage_mounter.sh, dl_wallhaven_wallpapers.sh and dvdvideo2iso.sh. The naming style is descriptive: what it does is in the name, and a reader can guess the intent before opening the file.

The second kind is written notes in text or markdown, often a command cheat sheet for a tool rather than a script. The listing includes fzf.txt, fzf-snippet.md, fzf_dmenu.md, fzf_locate_fzf_playonlinux.md, fzf_clipboard_greenclip.md, fzf_surfraw.md, the fzf_nova/ and fzf_speed/ folders, color_commands.txt, color_manpages.txt, cheat_zsh_autocomplete.txt, alias_functions_examples.txt, doc2pdf.txt, format2usb.txt, fstab.txt, aspell_fx.txt, feedly_custom_rss.txt, google_text_to_speech.txt and guake_chfontsize.txt.

The third kind is configuration for a specific desktop session, stored as dotfile-style content: the repository root carries.autostartrc and.xbindkeysrc, so a window manager setup and a keybinding file are versioned alongside the scripts.

There are also directories of related material, including fzf_nova/, fzf_speed/, amulecli/, bleachbit_cleaners/, 404urlcleaner, diana-mui, dragonzord, game2chd and game2m3u. The pattern is a flat file for a one-off script and a directory when a topic accumulates several pieces.

To use it, read the file and copy the command

There is no install step, and pretending otherwise would be dishonest. The usage model is: find the file, open it, copy the lines you need. The root listing makes that search cheap because names are functional rather than cryptic.

A few representative paths from the root, to show the shape of what is there:

fzf.txt
fzf_dmenu.md
fzf_nova/
any_term_dropdown.sh
dvdvideo2iso.sh

The fzf entries are worth a word. The README's coverage list names fzf as a fuzzy finder for your shell, and the repository devotes several files to it: a base note, a dmenu integration, a snippet file, a locate and playonlinux pairing, a clipboard pairing with greenclip, a surfraw pairing, and two folders for what the names call fzf_nova and fzf_speed. A single tool that is the subject of one video becomes a dozen files here, each capturing a different integration.

The second pattern is pairing a general tool with a specific application. fzf_clipboard_greenclip.md pairs the fuzzy finder with greenclip, which the README describes as a simple clipboard manager to be integrated with rofi. Other names follow the same logic, and the notes are short by design: a working command line with the flags already filled in.

The important caveat for a reader: the files assume a Linux desktop with particular tools installed. A script that drives fzf, calibre, inxi or a pulseaudio mixer will do nothing useful on a machine that lacks the tool it calls.

The README is a link ledger of what the videos covered

A large part of the README is not about the repository at all. It is a ledger of places that mentioned the videos, and it is structured in four parts.

The first and longest is My Videos has Been Feature On, split into Official Software Site and Blogs/Wikis/SocialMedia. The official-site list names projects the videos covered, each with a one line description taken from the project: couturier for merging PDF and images, curseofwar as a fast action terminal RTS game with vim hotkeys, greenclip, inxi as a full featured system information script, a package converter that is a frontend to Alien, pacmixer as an alsamixer alike for pulseaudio, pipe-viewer and straw-viewer and youtube-viewer as command-line interfaces to YouTube, sunflower-fm as a lightweight dual pane file manager, torrent-search, turses as a console twitter client, veromix as a KDE mixer for pulseaudio, and weechat-vimode as a WeeChat script adding vi-like modes.

The second part is the blog and wiki trail, with entries from Hackaday, Linuxaria, nixCraft, OMGUbuntu, Phoenixts, PS2-Home, Softpedia, UbuntuBuzz, UbuntuManual and WebUpd8, each linked to a specific video.

The third part records translations, with a Spanish translation at Hipertextual and a German one at tomzai.ch. The fourth is shout outs to other channels such as KarynBryant, InfinitelyGalactic, PC-Addicts, budlabs and DistroTube.

The practical value of that ledger is that it is a map of the channel's coverage. Each entry is a link to a video about a specific tool, which makes this repository a good index for finding which tool the author has already covered.

GPLv3 with a stated default, and no version to pin

Licensing here is explicit and consistent, which is better than most script collections manage. The README has a dedicated section, What License Are My Scripts Under If Not Stated?, and states the rule plainly: GPLv3, with the reasoning given as a matter of copyright and copyleft and the choice left to the reader. The licence file in the root is LICENSE.txt, and the repository licence is recorded as GPL-3.0.

A default licence for files that do not state one is a genuinely useful convention. If you copy a script out of this repository and drop it into your own project, you have a clear answer on terms, and the same rule covers the notes as well as the code.

The important boundary is where GPLv3 stops and upstream terms begin. Many of these files wrap other people's software. A script that drives fzf, calibre, inxi or youtube-viewer is not covered by the author's licence, and neither is the tool it calls. If you take a wrapper, you take a dependency on that tool's own licence and its own release cycle, and that is the part most people forget.

Upgrade cost, in the sense that matters here, is not versioned. The repository has no GitHub releases, so there is no tag to reference, no changelog to diff and no upgrade path to follow. What a reader can do is record the commit they copied from.

The last push was on 2026-10-12, so the content is recent, and the repository is not archived. Whether that means the individual scripts still work is a separate question, because their correctness depends on external tools whose interfaces change independently.

Where the archive is the wrong source to depend on

There are several cases where reaching for this repository is a mistake.

First, if you need a supported tool with a maintainer, a version policy and a bug tracker, this is not it. It is a collection of files with no release series, no issue policy and no compatibility promise. Every script in it is a snapshot of one author's machine at one moment.

Second, if you are writing software rather than running a command. Depending on a script means depending on a file that can change without notice, with no version constraint, no test suite and no semantic guarantee about its output. Copy the command into your own scripts and own it instead.

Third, if your environment is not a Linux desktop with the expected tools. The archive is built around terminal workflows on a graphical Linux session, given the presence of .autostartrc, .xbindkeysrc, window manager and mixer material, and the calibre, ffmpeg and pulseaudio notes. A headless server, a macOS workstation or a container will find large parts of it inapplicable.

Fourth, if you need documentation of the tools themselves. The files here are the author's usage notes, which means they cover what the author needed and quietly skip everything else. The README's own one line descriptions of the covered projects are the right starting point for that, and the projects' own documentation is where the full behaviour lives.

A better-shaped alternative for reusable shell work, and what this archive still gives you

For the underlying tools, the alternative to reading these notes is the project itself. The README's coverage list is a directory of projects with their own upstream homes, each described in one line, and each of those is where the authoritative documentation, the release history and the licence live. A note in an archive is a good pointer to the upstream project and a poor substitute for it.

The difference in approach is worth naming. Upstream tools ship an interface and a maintainer who will change it deliberately. A personal notes file preserves one working invocation, verified once, against one version, and never revised. The archive's value is that it removes the friction of figuring out which flags to combine, which is exactly the part people watch a video to learn.

There is also a category that upstream cannot supply at all. The scripts here are the glue: a terminal dropdown launcher, an archive and disc image mounter wired to file manager actions, a wallpaper downloader, a window and keybinding configuration, a calibre and ffmpeg command line. Nobody publishes those as products, and a working example saves an afternoon of flag archaeology.

The repository also carries one of the author's own projects, pkm, described as a shell script wrapper for package managers originally by gotbletu, and it appears in the coverage list alongside projects that merely featured the videos. That distinction is a good filter to apply when reading the tree: the files that are the author's own work carry an ongoing responsibility, and the notes that wrap other people's tools carry an expiry date.

Editorial conclusion

Use shownotes as a searchable notebook: it is a good place to find a working fzf snippet, a calibre or ffmpeg command line, or a shell function the author has already used, and the licence is GPLv3 (copyleft), so reuse is fine if you keep the same terms. Do not wire it into a build, do not depend on it as a library, and do not expect it to be a maintained package, because it publishes no releases and its scripts call external tools such as fzf, calibre and inxi whose interfaces move on their own schedule. Before copying anything, read the individual file rather than the README, and check the licence of the upstream tool the script drives.

Frequently asked questions

Official sources

1. gotbletu/shownotes on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README