Command Line on KnightLi Blog

CLI-Anything: Turning Software into an Agent-Usable Command Line

Mon, 25 May 2026 00:24:36 +0800

CLI-Anything is an open-source Agent tooling project from HKUDS. Its goal is to turn software that was originally designed for human GUI operation into command-line interfaces that AI Agents can call more easily. It does not reimplement a simplified version of the software. Instead, it builds a CLI harness around the existing codebase and real backend, allowing Agents to complete tasks through stable commands, stateful sessions, and structured output.

This direction addresses one of the most common gaps when Agents use software: GUI automation depends on screenshots, clicks, and coordinates, so it is easily affected by interface changes; a single API is also often incomplete, forcing the Agent to stitch together a large amount of context on its own. CLI-Anything chooses to condense software capabilities into a command line because commands are naturally easier for models to read, combine, and verify, while also fitting neatly into scripts and automation workflows.

How it works

The official repository describes CLI-Anything as a pipeline for automatically generating CLIs. After receiving a local software source path or a GitHub repository URL, the process analyzes the code structure, identifies the backend and data models, designs command groups, and then implements the CLI, tests, and documentation.

The generated CLI usually supports two usage modes. One is a REPL for continuous work, which preserves project state. The other is a subcommand mode, which is better suited to scripts and pipelines. Commands also provide JSON output so Agents can parse results directly, while still keeping a human-readable format for debugging.

In the official example, the Claude Code plugin can be used like this:

1
2
3

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything <software-path-or-repo>

If a harness has already been generated for a piece of software, later usage is closer to a normal Python CLI:

cd <software>/agent-harness
pip install -e .
cli-anything-<software> --help
cli-anything-<software>
cli-anything-<software> --json <command>

Where it fits

CLI-Anything is especially suitable for scenarios where “the capability exists in real software, but the Agent cannot operate it reliably.” Examples include image, video, audio, office documents, 3D modeling, data analysis, or AI/ML toolchains. As long as the project has an analyzable codebase, a callable backend, or a clear data model, it has a chance to be wrapped as a command set that Agents can use.

Its value is not merely adding another layer of wrapping in the command line. The real value is turning key software operations into discoverable, composable, and testable interfaces. An Agent can first understand capabilities through --help, then receive results through JSON output, and connect multiple commands into a workflow. For tasks that require batch processing, automatic validation, and continuous iteration, this is more controllable than temporarily asking an Agent to click through an interface.

Boundaries to keep in mind

CLI-Anything does not mean that any software can be integrated instantly at no cost. It depends on the target software’s source code, backend capabilities, file formats, and testability. If a piece of software is highly closed and its key logic exists only in the GUI layer, the difficulty of generating a high-quality CLI rises significantly.

The official methodology also emphasizes real backends and test validation. This means generating a harness is not finished after writing a few command wrapper scripts. To use it for serious work, you still need to confirm command coverage, output format, dependency installation, real software invocation, and end-to-end test reliability. A more realistic approach is to first generate a CLI for a clearly defined workflow, then gradually fill in capabilities through commands such as refine, test, and validate.

Summary

CLI-Anything’s idea is direct: instead of making Agents adapt to fragile human interfaces, add a stable, structured, and testable command-line entry point to existing software. It is suitable for people who want to bring professional software into Agent workflows, and also for developers studying the shape of “Agent-native software.” In real adoption, the key question is not how much code one command can generate, but whether the generated CLI can call real capabilities, preserve state, output structured results, and stand up to testing.

Ghostty Docs Quick Read: Installation, Configuration, and Daily Usage Notes

Fri, 15 May 2026 14:50:11 +0800

Ghostty is a new terminal emulator, but it is not simply “another faster terminal.” According to its official documentation, it tries to balance three goals at the same time: speed, features, and a native desktop experience. In other words, it wants GPU acceleration and solid rendering performance, while also feeling like a real local app on macOS and Linux instead of pushing every interaction into a custom-drawn interface.

If you currently use iTerm2, Kitty, Alacritty, WezTerm, or the system terminal, the most interesting part of Ghostty is not one isolated feature. It is the way it combines “works out of the box” with “deeply configurable.” The default configuration is already usable, but when you want to tune it further, the docs provide complete entry points for configuration files, themes, keybindings, fonts, Shell integration, and terminal control sequences.

Start with the Positioning

Ghostty’s core positioning can be summarized in three points:

It is a cross-platform terminal emulator, currently focused on macOS and Linux.
It uses platform-native UI: Swift, AppKit, and SwiftUI on macOS; Zig and GTK4 on Linux.
Its terminal core is libghostty, and the GUI applications are built around this shared core.

This design affects daily use. Tabs, splits, error prompts, window state restoration, system shortcuts, and similar features are not merely components that “look like a desktop app.” They try to follow the interaction conventions of each operating system. The default shortcuts on macOS and Linux also differ according to platform expectations.

Installation: Direct on macOS, Distribution-Dependent on Linux

The official prebuilt binaries mainly target macOS. The most common installation path is to download the .dmg, open it, and drag Ghostty into the Applications folder. Homebrew users can also use the community-maintained cask:

`1`	`brew install --cask ghostty`

Linux is more fragmented. The Ghostty docs separate package managers, community binaries, and source builds for different distributions. Arch, Alpine, Gentoo, NixOS, Snap, Solus, Void, and others all have their own paths. If a distribution has no official or trusted repository, the docs lean toward building from source rather than casually installing third-party binaries.

This matters especially on servers and workstations: a terminal emulator handles a large amount of input and output, clipboard data, links, SSH sessions, and local file paths. It is better to be conservative with the installation source, preferring the official macOS package, distribution repositories, or a build process whose source you can audit.

Configuration: Do Not Rush to Copy a Giant dotfiles Setup

Ghostty’s configuration philosophy is “usable with zero configuration.” The default font includes JetBrains Mono and Nerd Font support, so most users can work normally the first time they open it. The docs even suggest that if you must configure a non-subjective option to feel comfortable, it may be worth asking whether that behavior should become the default.

When you do need customization, Ghostty uses a text configuration file. The current configuration file name is config.ghostty, while older versions also support config. Common paths include:

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

On macOS, Ghostty also reads:

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

The syntax is straightforward: key = value. For example:

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

A practical suggestion: do not start by copying someone else’s full configuration. A steadier approach is to run it bare for a few days and change only three things at first: font family, font size, and theme. Once you actually feel friction around shortcuts, splits, windows, or Shell integration, add those settings one by one.

Documentation Lookup: Full Configuration Reference Is Available Locally

Ghostty has many configuration options, and the official docs collect them in the Option Reference. Besides the web page, you can query the reference locally after installation:

`1`	`ghostty +show-config --default --docs`

This command prints the default configuration and documentation to standard output, which is useful when piped into a pager:

`1`	`ghostty +show-config --default --docs \| less`

To list available fonts:

`1`	`ghostty +list-fonts`

To list built-in and available themes:

`1`	`ghostty +list-themes`

To view default keybindings:

`1`	`ghostty +list-keybinds --default`

These commands are more reliable than copying snippets from the web, because they come from the Ghostty version installed on your own machine.

Keybindings: Treat “Actions” as the Core Concept

Ghostty’s keybinding format is:

`1`	`keybind = trigger=action`

trigger is the key sequence, and action is the operation Ghostty performs. Creating a new tab, closing the current surface, reloading configuration, and jumping to a prompt are all actions. The model is clear: you are not “changing a menu item”; you are binding an input sequence to an action.

After changing configuration, you can reload it at runtime. The default shortcut is:

Linux: ctrl+shift+,
macOS: cmd+shift+,

Not every setting takes effect immediately. Some options only affect newly created terminals, while others require a full restart. If “the config is written but nothing changed,” check the documentation for that option before spending too much time suspecting syntax.

Themes and Fonts: Use Built-Ins First, Then Tune

Ghostty ships with many themes and supports switching themes according to the system light or dark mode:

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

Themes can also come from custom files. The docs are clear here: a theme file is essentially a Ghostty configuration file and can set many options, so do not casually use themes from untrusted sources.

For fonts, font-family can be repeated to specify fallback fonts. This is useful in multilingual environments: the primary font can handle English and symbols, while later fonts cover Chinese, Japanese, or other characters. When you encounter display details such as emoji, bold, italic, or ligatures, look up the corresponding options in the Option Reference.

Shell Integration: Especially Important for SSH Users

Ghostty supports automatic Shell integration injection for bash, elvish, fish, nushell, and zsh. When enabled, several interactions become more natural:

New terminals can open in the previous terminal’s working directory.
Complex prompts can redraw correctly after resize instead of reflowing badly.
You can jump between command outputs using prompt markers.
Cursor behavior at the prompt can better match editing habits.

If you do not want automatic injection, disable it in the configuration:

`1`	`shell-integration = none`

SSH deserves extra attention. Ghostty uses xterm-ghostty as TERM, but many remote hosts do not yet have the corresponding terminfo. The docs provide two Shell integration features, ssh-env and ssh-terminfo, which are disabled by default and can be enabled as needed:

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

If you often connect to old servers, containers, bastion hosts, or tightly managed production environments, read the official Terminfo and Shell Integration docs before enabling these features. Terminal capability negotiation looks minor, but when it goes wrong, the symptoms can be strange colors, broken shortcuts, or garbled full-screen programs.

My Suggested Onboarding Order

If you only want to judge whether Ghostty fits you, try this sequence:

Install it and use it for a day without writing any configuration.
Adjust only font-family, font-size, and theme.
Use ghostty +list-keybinds --default to inspect default shortcuts instead of importing someone else’s shortcut table first.
If you use SSH often, check remote host terminfo compatibility early.
Finally, tune splits, windows, transparency, title bar, background image, and other visual or workflow preferences.

Ghostty’s docs are engineering-oriented. They are better read as a configuration reference manual than as a marketing page. For most users, the real evaluation criteria are simple: does the default experience already feel comfortable, and are your daily editor, Shell, SSH, tmux, or Zellij workflows stable? If those pieces work well, Ghostty deserves a place on your long-term terminal shortlist.

References

How to Control fdupes Deletion Order: Keep Duplicate Files by Directory Priority

Wed, 06 May 2026 09:23:09 +0800

When using fdupes to delete duplicate files across three directories, such as a, b, and c, and you want to keep a first, then b, and delete duplicates from c first, the key is not a complex rule. It is the order of directory arguments.

In non-interactive delete mode, fdupes keeps the first file it sees in each duplicate group and deletes later duplicates. Therefore, directory arguments should be arranged from highest retention priority to lowest.

In other words, to achieve “delete from c first, then b, and keep a as much as possible”, write the command like this:

`1`	`fdupes -rdN a b c`

The scan order is a -> b -> c. When the same file exists in all three directories, the file in a is found first and kept, while duplicates in b and c are deleted. If only b and c contain duplicates, b is kept and c is deleted.

Parameter Meaning

Common parameters are:

-r: recursively scan subdirectories.
-d: delete duplicate files.
-N: when used with -d, skip interactive confirmation, keep the first file in each duplicate group, and delete the rest.

Therefore, the basic format for automatic duplicate deletion is:

`1`	`fdupes -rdN 目录A 目录B 目录C`

The earlier a directory appears, the higher its retention priority. The later it appears, the more likely its duplicate files are to be deleted.

Preview Before Deleting

Using -dN deletes files directly, so it is better to preview duplicate groups first:

`1`	`fdupes -r a b c`

The output is grouped by duplicate files. In each group, the file shown earlier is the one more likely to be kept in non-interactive deletion mode.

You can also view summary information:

`1`	`fdupes -rm a b c`

If the data is important, save the result and inspect it manually:

`1`	`fdupes -r a b c > duplicates.txt`

After confirming that the order within each duplicate group matches your expectations, run:

`1`	`fdupes -rdN a b c`

How Subdirectories Are Handled

As long as -r is enabled, fdupes recursively scans all files under the directories you pass in. Retention priority is still determined by the order in which paths appear in the command.

For example:

`1`	`fdupes -rdN dir_a dir_b dir_c`

This means:

dir_a has the highest priority.
dir_b comes next.
dir_c has the lowest priority.

If dir_a/sub1/file.txt and dir_c/sub1/file.txt have identical content, the file under dir_a is kept. If dir_a/x/y/file.txt and dir_c/file.txt have identical content, the file under dir_a is still kept first. fdupes compares file content; filenames and directory depth do not need to match.

Precisely Controlling Subdirectory Priority

If you only pass parent directories, the scan order inside subdirectories is determined by fdupes traversal behavior. This is enough in most cases. But if you want a specific subdirectory to have higher priority, write it explicitly before its parent directory.

For example, suppose you want to keep dir_a first, then keep dir_b/special, then process the rest of dir_b, and finally process dir_c:

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

This makes dir_b/special scan before dir_b. When dir_b is scanned later, files under special have already been recorded, so that subdirectory effectively has higher priority than the rest of dir_b.

This pattern is useful when:

a is the most important baseline directory.
A subdirectory inside b is more important than the rest of b.
c is mainly a low-priority backup directory.

The path order can be extended further:

`1`	`fdupes -rdN a b/important b c/keep-first c`

The rule is still the same: the earlier it appears, the more likely it is to be kept.

Use a List for Many Directories

If there are many directories and subdirectories, manually writing a long command is error-prone. You can write paths into a text file such as folders.txt, ordered by priority:

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

Then pass them to fdupes with xargs:

`1`	`cat folders.txt \| xargs fdupes -rdN`

If paths may contain spaces, use null-separated input for better safety:

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

Important Boundaries

First, fdupes compares file content, not filenames. Two files with completely different names can still be treated as duplicates if their content is identical.

Second, if directory a contains duplicates internally, fdupes -rdN a b c may also delete later duplicates inside a. This command means “keep the first file according to the overall scan order”, not “never delete anything under a”.

Third, by default, fdupes does not follow symbolic links. If you need to handle files behind symlinks, confirm whether -s is needed and whether that matches your data-safety expectations.

Fourth, fdupes only deletes duplicate files. It does not clean up empty directories. After deletion, if b and c contain empty folders, you can run:

`1`	`find b c -type d -empty -delete`

Safer Operating Habit

If the directories contain important data, do not start with -rdN. A safer workflow is:

Run fdupes -r a b c first to view duplicate groups.
Confirm that the first file in each group is the one you want to keep.
Then run fdupes -rdN a b c for automatic deletion.
After deletion, check whether empty directories need cleanup.

If you are very worried about accidentally deleting files under a, first clean a smaller range of low-priority directories, or export the results and filter them manually. The directory order in fdupes is useful, but it is not an access-control rule. Once a path is included in the scan, duplicate files inside it may participate in deletion decisions.

Summary

To delete duplicate files with fdupes by priority, put the directories you want to keep earlier and the directories you want to delete from later.

To keep a, then b, and delete from c first:

`1`	`fdupes -rdN a b c`

To give a subdirectory higher priority, write it before its parent directory:

`1`	`fdupes -rdN a b/important b c`

The key sentence is simple: fdupes -dN keeps duplicate files that appear first and deletes duplicates that appear later. Directory order is your retention priority.

FFmpeg `-map` Explained: Precisely Select Video, Audio, and Subtitle Streams

Thu, 02 Apr 2026 23:14:03 +0800

In multi-audio and multi-subtitle workflows, -map is one of FFmpeg’s most important and most frequently misused options.

If you don’t explicitly specify -map, FFmpeg auto-selects streams using default rules, and the output is often not what you expect. For example:

Subtitles disappear after export
The wrong language track is selected
Unwanted data streams are included

This article uses common real-world scenarios to explain how -map works.

First, Understand What a “Stream” Is

A container file (such as mp4 or mkv) usually contains multiple streams, including:

Video streams (v)
Audio streams (a)
Subtitle streams (s)
Attachment/data streams (fonts, cover art, chapters, etc.)

You can inspect streams with ffprobe:

`1`	`ffprobe -hide_banner input.mkv`

Basic `-map` Syntax

Most common pattern:

`1`	`-map input_index[:stream_type][:stream_index]`

Examples:

0:v: all video streams from the 1st input
0:a:0: the 1st audio stream from the 1st input
1:s:1: the 2nd subtitle stream from the 2nd input

Notes:

input_index starts from 0, based on -i order
stream_index also starts from 0

Practical Examples

1) Video from A, audio from B

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0:v:0 -map 1:a:0 \
  -c:v copy -c:a aac \
  french.mp4

Meaning:

Use the first video stream from english.mp4
Use the first audio stream from french.mp3
Merge into french.mp4

2) Keep all streams from input 1, then add one more audio track

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0 -map 1:a:0 \
  -c copy \
  english-french.mp4

Meaning:

-map 0 keeps all streams from the first input
Then append the first audio stream from the second input

Two Useful Advanced Tricks

1) Negative mapping: exclude unwanted streams

For example, keep everything from input 1 but remove its second audio stream:

`1`	`ffmpeg -i input.mkv -map 0 -map -0:a:1 -c copy output.mkv`

2) Optional mapping: don’t fail when a stream is missing

If some files may not have subtitles, use ?:

`1`	`ffmpeg -i input.mp4 -map 0:v -map 0:a -map 0:s? -c copy output.mp4`

0:s? means: map subtitles if present; otherwise skip without error.

Common Pitfalls

Once you use -map, FFmpeg stops automatic stream selection, so you must map everything you need.
-c copy only remuxes without transcoding. If the target container doesn’t support a codec, it still fails.
With multiple inputs, index mistakes are common. Input indices are determined only by -i order.
For robust scripts, inspect with ffprobe first, then generate -map dynamically.

Summary

The core idea of -map is simple: explicitly tell FFmpeg which input to use, what stream type to pick, and which stream index to select.

Once you master this, you can reliably handle complex cases like multi-audio, multi-subtitle, and cross-file stream composition.

Command Line on KnightLi Blog

CLI-Anything: Turning Software into an Agent-Usable Command Line

How it works

Where it fits

Boundaries to keep in mind

Summary

Ghostty Docs Quick Read: Installation, Configuration, and Daily Usage Notes

Start with the Positioning

Installation: Direct on macOS, Distribution-Dependent on Linux

Configuration: Do Not Rush to Copy a Giant dotfiles Setup

Documentation Lookup: Full Configuration Reference Is Available Locally

Keybindings: Treat “Actions” as the Core Concept

Themes and Fonts: Use Built-Ins First, Then Tune

Shell Integration: Especially Important for SSH Users

My Suggested Onboarding Order

References

How to Control fdupes Deletion Order: Keep Duplicate Files by Directory Priority

Parameter Meaning

Preview Before Deleting

How Subdirectories Are Handled

Precisely Controlling Subdirectory Priority

Use a List for Many Directories

Important Boundaries

Safer Operating Habit

Summary

FFmpeg `-map` Explained: Precisely Select Video, Audio, and Subtitle Streams

First, Understand What a “Stream” Is

Basic -map Syntax

Practical Examples

1) Video from A, audio from B

2) Keep all streams from input 1, then add one more audio track

Two Useful Advanced Tricks

1) Negative mapping: exclude unwanted streams

2) Optional mapping: don’t fail when a stream is missing

Common Pitfalls

Summary

Basic `-map` Syntax