If you'd like to test drive my YAML front matter CLI tool, you can now install it from Git using uv or pip(x). There's also a readme now that shows you what it can do and teaches you how to use it.
https://codeberg.org/scy/felloff
Let me know what you think and if you encounter any bugs!
me: manually editing YAML front matter sucks
also me: *spends a day writing a CLI tool for common tasks*
(Not released yet, I have a few small features I'd like to implement first.)
![Terminal screenshot, invoking "batcat -pl yaml tests/yaml.md". The result is the following Markdown document with YAML front matter:
---
title: Example doc # This comment will be preserved.
created: 2025-06-06
tags: [test, example]
---
This document will be used for **testing**.
Next, I'm invoking a command to change some values: "felloff set tests/yaml.md author scy title 'Changed title' --time modified now --append tags foo bar | batcat -pl yaml". The result is:
---
title: Changed title # This comment will be preserved.
created: 2025-06-06
tags: [test, example, foo, bar]
author: scy
modified: 2025-06-07 02:04:41.487260+02:00
---
This document will be used for **testing**.](https://assets.chaos.social/media_attachments/files/114/639/164/029/864/835/original/9dc753c11a435710.png "Terminal screenshot, invoking \"batcat -pl yaml tests/yaml.md\". The result is the following Markdown document with YAML front matter:
---
title: Example doc # This comment will be preserved.
created: 2025-06-06
tags: [test, example]
---
This document will be used for **testing**.
Next, I'm invoking a command to change some values: \"felloff set tests/yaml.md author scy title 'Changed title' --time modified now --append tags foo bar | batcat -pl yaml\". The result is:
---
title: Changed title # This comment will be preserved.
created: 2025-06-06
tags: [test, example, foo, bar]
author: scy
modified: 2025-06-07 02:04:41.487260+02:00
---
This document will be used for **testing**.")
Y ya probaron el comando "dysk", esta muy chulo y devuelve informacion sobre los sistemas de archivos, de forma mas clara que "df".
En github: https://github.com/Canop/dysk
Su web: https://dystroy.org/dysk/
Harlequin: The SQL IDE for Your Terminal.
https://harlequin.sh/
Un chouette outil pour remplacer `psql` et taper des commandes SQL : autocomplétion, formatage, résultats en tableaux, nom des tables…
#sql #psql #outil #cli
@ilyess Not a TUI, just a #CLI, but the best I've come across in months is https://f2.freshman.tech/ , "The batch renaming tool you'll actually enjoy using"
I made a comprehensive list of Linux tools and distributions + built a Python CLI to manage my list, and output it in Markdown, Text, JSON, and YAML.
The list reflects what I personally use or find interesting. The CLI is generic - feel free to fork it and create your own list.
https://github.com/paulsorensen/linux-tools https://paulsorensen.io/linux-tools-cli/
just stumbled over the #scanimage #cli tool thanks to this blog post by @b0rk (https://jvns.ca/blog/2020/07/11/scanimage--scan-from-the-command-line). I have so far struggled with GUI tools (mostly simple-scan) with very limited control over the actual scan process; scanimage is different: rather easy to use, very configurable and clear in what it actually does. Should be straightforward to write a couple of scripts for my usual use cases 
I am very impressed with this repo-diving and construction of documentation done by "Devin" for DeepWiki.
"Qio" is a CLI that I built to use with a database structure I came up with to keep a knowledge base of things like CLI things and one-liners or SQL or URLs or team lists or whatever ("rainbow.toml" is the database, "q" is short for queue, and "qio" is the clever CLI tool name that nobody had taken yet).
This was written before I was into TDD so it's not the *greatest* golang in the universe but my choice at the time was to lean heavily on Viper as a framework to build a database out of its own default configuration using TOML. There's lots of room for improvement. ;)
So anyway, I'm pretty complete on docs in this repo, and it seemed like a good candidate so I put my repo into DeepWiki and got a pretty amazing result complete with an accurate illustration of my entirely invented data definition:
"claude-trace (via) I've been thinking for a while it would be interesting to run some kind of HTTP proxy against the Claude Code CLI app and take a peek at how it works.
Mario Zechner just published a really nice version of that. It works by monkey-patching global.fetch and the Node HTTP library and then running Claude Code using Node with an extra --require interceptor-loader.js option to inject the patches."
Sharing @futurile's excellent blog series on how to configure #IMAP and #SMTP for #NeoMutt, including setups for Runbox.
Configure IMAP, SMTP or msmtp, set up multiple accounts - this tutorial has you covered.
Check out the posts here: https://www.futurile.net/archives.html
https://www.futurile.net/2025/05/18/neomutt-email-native-imap-tutorial/
Big thanks to https://mastodon.social/@futurile
https://www.europesays.com/uk/151149/ Germany’s CLI orders cargo vessel for Europe-Canada route #AtlanticOcean #Canada #CLI #EU #Europe #Germany #Netherlands #NorthAmerica #RoyalBodewes #subsidies #TaxpayerAbuse #UnitedKingdom
When moving or copying large files between hard disks I like to see the progress to make the wait more informative and enjoyable.
If you want to achieve the same thing the "progress" package (present in the repos of all distros) allows you to do it. After installing it add to mv or cp the variable "& progress -mp $!", for example: mv file1 /destination-directory & progress -mp $!
If you like you can add the corresponding alias: alias mv='mv -v "$@" & progress -mp $!'.
Just released DNS-tester — is a scalable tool designed for enterprise environments to validate DNS cache consistency, monitor performance across distributed DNS infrastructure, and ensure reliable name resolution at scale.! Perfect for sysadmins and devs. 
Check it out here 
https://github.com/dmachard/DNS-tester
"I’ve been tracking llm-tool-use for a while. I first saw the trick described in the ReAcT paper, first published in October 2022 (a month before the initial release of ChatGPT). I built a simple implementation of that in a few dozen lines of Python. It was clearly a very neat pattern!
Over the past few years it has become very apparent that tool use is the single most effective way to extend the abilities of language models. It’s such a simple trick: you tell the model that there are tools it can use, and have it output special syntax (JSON or XML or tool_name(arguments), it doesn’t matter which) requesting a tool action, then stop.
Your code parses that output, runs the requested tools and then starts a new prompt to the model with the results.
This works with almost every model now. Most of them are specifically trained for tool usage, and there are leaderboards like the Berkeley Function-Calling Leaderboard dedicated to tracking which models do the best job of it.
All of the big model vendors—OpenAI, Anthropic, Google, Mistral, Meta—have a version of this baked into their API, either called tool usage or function calling. It’s all the same underlying pattern.
The models you can run locally are getting good at this too. Ollama added tool support last year, and it’s baked into the llama.cpp server as well.
It’s been clear for a while that LLM absolutely needed to grow support for tools. I released LLM schema support back in February as a stepping stone towards this. I’m glad to finally have it over the line.
As always with LLM, the challenge was designing an abstraction layer that could work across as many different models as possible. A year ago I didn’t feel that model tool support was mature enough to figure this out. Today there’s a very definite consensus among vendors about how this should work, which finally gave me the confidence to implement it."
Yeah, colors and formatting in CLI tools is usually a good thing, but if your --help looks like this, you probably need to take a step back.
![The output of "uvx docling --help". It starts with a simple (yellow/white and bold) "Usage: docling [OPTIONS] source".
Below that, a full-width, but one line high rounded box titled "Arguments" that says: "* input_sources source PDF files to convert. Can be local file / directory paths or URL. [default: None] [required]".
So far, so good, but now starts a full-width rounded box titled "Options" that's taller than my vertical screen. It's a table with four columns, all of equal width:
The first column lists the actual option in cyan, e.g. --ocr, or --allow-external-plugins.
The second column is empty half of the time. It contains the negation option, if available. So for example, if the first column has --allow-external-plugins, the second one has --no-allow-external-plugins, but if the first column has --from, the second column is empty.
The third column contains the argument or enum to that option and is also empty half of the time. So for the --output option the column says "PATH", and for --table-mode it says "[fast|accurate]".
The fourth column explains what the option actually does and also lists the default in a new line after that, e.g. for --enrich-code it says "Enable the code enrichment model in the pipeline. [default: no-enrich-code]".
The fourth column being only ¼ of the screen but full of text, while the rest of the table contains a lot of horizontal and vertical whitespace (because column 4 usually spans multiple lines) makes it pretty hard to read.](https://assets.chaos.social/media_attachments/files/114/579/093/021/651/723/original/5dbeb52bb25bb28d.png "The output of \"uvx docling --help\". It starts with a simple (yellow/white and bold) \"Usage: docling [OPTIONS] source\".
Below that, a full-width, but one line high rounded box titled \"Arguments\" that says: \"* input_sources source PDF files to convert. Can be local file / directory paths or URL. [default: None] [required]\".
So far, so good, but now starts a full-width rounded box titled \"Options\" that's taller than my vertical screen. It's a table with four columns, all of equal width:
The first column lists the actual option in cyan, e.g. --ocr, or --allow-external-plugins.
The second column is empty half of the time. It contains the negation option, if available. So for example, if the first column has --allow-external-plugins, the second one has --no-allow-external-plugins, but if the first column has --from, the second column is empty.
The third column contains the argument or enum to that option and is also empty half of the time. So for the --output option the column says \"PATH\", and for --table-mode it says \"[fast|accurate]\".
The fourth column explains what the option actually does and also lists the default in a new line after that, e.g. for --enrich-code it says \"Enable the code enrichment model in the pipeline. [default: no-enrich-code]\".
The fourth column being only ¼ of the screen but full of text, while the rest of the table contains a lot of horizontal and vertical whitespace (because column 4 usually spans multiple lines) makes it pretty hard to read.")
