Команди
Усі команди ketch в одному місці: що робить кожна, яку форму приймає та один
робочий приклад. PKG нижче — встановлена назва, аліас або
owner/repo; більшість команд, що його приймають, також допускають @version у кінці
(sharkdp/[email protected]). Глобальні прапорці працюють скрізь: --root <DIR> вказує на
інше дерево ketch, -v/--verbose показує, що робить ketch, -q/--quiet
друкує лише помилки й запитані дані, --no-color вимикає колір, а
--no-emoji прибирає значки перед рядками статусу.
Значки. У терміналі кожен рядок статусу починається зі значка того, про що він
повідомляє: 📦 встановлення, ⏫ оновлення пакета чи реєстру, 🧹 видалення, ⏬ завантаження,
🔗 посилання, ⏪ відкат, 🔍 пошук, 🩺 doctor, а в решті випадків ✅ успіх, ❗ попередження,
❌ помилка, 💡 примітка. Типово вони ввімкнені (emoji у config.toml,
KETCH_EMOJI) і ніколи не з'являються в пайпі чи файлі, за TERM=dumb, у
виводі --json або --names-only, у табличних даних і в лозі.
Встановлення та видалення
ketch install [PKG]... [options]
Встановлює один або кілька пакетів. Виведення обирає асет релізу, що пасує
хосту (архітектура, ОС, libc); маніфест або --asset кажуть, що робити натомість.
ketch install BurntSushi/ripgrep # будь-який репозиторій, що публікує релізи
ketch install rg # або назва, відома реєстру
ketch install sharkdp/[email protected] # або точна версія
ketch install --path ./mytool # локальний бінарник, архів, символьне посилання або .app
Уже встановлений пакет не оновлюється у вас за спиною. Якщо є
новіший реліз, install питає <pkg> <installed> is installed; update to <latest>? (типово ні) і в разі відповіді «так» оновлює його так само, як ketch upgrade;
--yes відповідає «так», а без термінала команда зупиняється з кодом 5 і пропонує
передати --yes або запустити ketch upgrade. Якщо нічого новішого немає, вона завершується з кодом 5:
cannot install <pkg>: <version> is already installed and no update is available (--force перевстановлює). Точна версія ([email protected]) і закріплений
пакет поводяться як раніше.
Опції: --path <PATH> встановлює локальний файл (еквівалент
local:<PATH>); --name <NAME> задає назву встановлення для одного
пакета; --force/-f перевстановлює запитану версію, навіть якщо вона вже є;
--pre враховує пререлізи й лишає пакет на них: далі
upgrade, outdated і list шукають пререлізи без --pre, а
info показує channel: pre (точний тег пререлізу, [email protected],
робить те саме; звичайне встановлення повертає пакет на stable); --draft
враховує й чернетки релізів GitHub, разом із пререлізами, і лишає пакет на
чернетках (channel: draft); pkg@<tag> --draft знаходить чернетку за
тегом, який вона отримає. GitHub показує чернетки лише токену з правом push
у репозиторій (KETCH_GITHUB_TOKEN, GITHUB_TOKEN, GH_TOKEN або
github_token), тож без нього --draft зупиняється з цією причиною; файли
чернетки завантажуються через API з токеном і перевіряються як будь-які
інші. Інші джерела не мають чернеток і відхиляють --draft; --no-link розпаковує без посилань у PATH;
--require-checksum відхиляє релізи без опублікованої контрольної суми;
--asset <NAME> бере один файл релізу за точною назвою (питає підтвердження,
бо перевірка платформи пропускається); -j/--jobs <N> і -y/--yes керують
паралелізмом і запитаннями. Аліас — ketch i.
Тег, який не є версією (nightly, dev, canary, edge), — плаваючий:
проєкт перепубліковує його під тією самою назвою. pkg@nightly встановлює
його на channel: dev і записує отриману збірку — дайджест асета й час
публікації. Повторне встановлення того самого тегу дає already installed,
доки тег не вкаже на іншу збірку, а тоді бере нову.
Коли реліз містить кілька бінарників із назвою пакета й жоден
маніфест не називає потрібний, посилання ставиться лише на один із них: той, що названий у --bin <NAME>;
інакше — бінарник, названий точно як пакет; інакше — вибір,
запам'ятований з минулого разу (у state.json, а під час ketch sync — у
ketch.lock), або вибір за номером у терміналі. Бінарники з іншими назвами
отримують посилання як звичайно. З --yes або без термінала вибору немає, і
встановлення завершується помилкою зі списком кандидатів — див. розділ bin у
MANIFESTS.md.
--bin <NAME> (для одного пакета) відповідає на це запитання заздалегідь, тому працює
без термінала: ketch install owner/rtok --bin rtok-cli. Він зберігається в
state.json, як вибір зі списку, і використовується під час подальших оновлень. Він завершується помилкою, якщо жоден бінарник
релізу не має такої назви і якщо в маніфесті пакета вже є bin
(тоді змініть його).
ketch uninstall <NAME>...
Видаляє встановлені пакети. Назви розв'язуються як в install (встановлена назва,
бінарник або owner/repo); одруківка зупиняє команду до того, як щось буде видалено.
Видаляється вся тека пакета в сховищі, разом з усім, що там залишило перерване
оновлення.
Для невстановленої назви друкується <name>: not found і повертається код 4; перелічується кожна
відсутня назва, і нічого не видаляється.
ketch uninstall rg
ketch uninstall fd ripgrep --yes # пропустити підтвердження
Аліаси — ketch remove і ketch rm.
ketch upgrade [NAME]...
Оновлює встановлені пакети до останнього релізу. Без аргументів — усі
незакріплені пакети. Показує таблицю from -> to, питає, потім встановлює.
Кожна версія розпаковується у власну нову теку, тож ніщо з постачання старої
версії не може затриматися в новій, а залишки перерваного
оновлення спершу видаляються — або оновлення зупиняється й називає їх. Тека попередньої
версії зберігається поруч для ketch rollback до ketch prune.
ketch upgrade # усе незакріплене
ketch upgrade ripgrep fd # лише ці
ketch upgrade --dry-run # показати план, нічого не змінюючи
Опції: --pre враховує пререлізи; --draft враховує й чернетки релізів
GitHub (пакет, встановлений із --draft, обходиться без нього). Опублікована
чернетка — це оновлення до релізу під її тегом; видалена чернетка —
попередження. Пакет на плаваючому тезі (channel: dev) іде за цим тегом:
оновлення — це тег, що вказує на іншу збірку, що вирішує дайджест асета, а
якщо джерело його не дає — час публікації релізу; новіша версія під іншим
тегом оновленням не є. --force оновлює й закріплені
пакети; --bin <NAME> (рівно для одного пакета) обирає, на який бінарник ставити посилання, коли
новий реліз містить кілька файлів із назвою пакета, як в install;
-j/--jobs <N>, -y/--yes. Закріплені пакети й пакети local: пропускаються, якщо
не вказано --force.
ketch rollback <PKG> [--to <VERSION>]
Перемикає пакет назад на версію, яка ще лежить на диску. Без --to відновлює
попередню збережену версію.
ketch rollback ripgrep
ketch rollback rg --to 14.1.0
ketch prune [NAME]... [--keep <N>]
Видаляє збережені старі версії згідно з політикою зберігання. Без аргументів — усі
встановлені пакети. --keep <N> оновлює збережену політику.
ketch prune
ketch prune ripgrep --keep 2
ketch pin <NAME>... / ketch unpin <NAME>...
Закріплює пакет на поточній версії (pin) або знімає закріплення (unpin).
Закріплені пакети пропускаються командою upgrade, якщо не передано --force.
ketch pin ripgrep
ketch upgrade --force # оновлює й закріплені пакети
ketch unpin ripgrep
ketch link <NAME>... / ketch unlink <NAME>...
Наново створює (link) або видаляє (unlink) посилання в каталозі bin для встановленого
пакета. unlink лишає вміст встановленим; upgrade зберігає стан
посилань.
ketch unlink ripgrep # лишити, але прибрати з PATH
ketch link ripgrep # повернути назад
ketch import winget|brew|linux <NAME> [--dry-run] [--yes]
Додає пакет, який уже знає інший пакетний менеджер. ketch читає його
опис, перетворює його на користувацький маніфест
~/.ketch/manifests/<name>.toml і встановлює звичайним шляхом, з ассетом і
контрольною сумою з цього опису.
ketch import brew codex # cask Homebrew (або formula)
ketch import brew fly --cask # шукати лише cask; --formula — лише formula
ketch import winget BurntSushi.ripgrep.MSVC # ідентифікатор winget, з урахуванням регістру
ketch import linux lazygit # Arch Linux, потім AUR
ketch import linux obsidian --dry-run # надрукувати маніфест, нічого не змінюючи
| Джерело | Звідки береться опис |
|---|---|
winget | маніфест інсталятора найновішої версії в winget-pkgs |
brew | JSON cask або formula з formulae.brew.sh |
linux | .SRCINFO пакета Arch Linux, або пакета AUR із суфіксом -bin/-appimage, якщо Arch збирає його з джерельних кодів |
Перетворюється лише пакет, чиї завантаження — ассети релізу GitHub
(https://github.com/<owner>/<repo>/releases/download/...). Завантаження звідкись
іще — CDN вендора, SourceForge, джерельний tarball, домашня сторінка GitHub із
файлами в іншому місці або суміш — нічого не записує і завершується з кодом 1
і повідомленням
<name> can't be converted: it is not distributed through GitHub Releases, and that is not supported yet.
Так само й інсталятори, які ketch не вміє запускати (.msi, .msix, Inno або
NSIS .exe, .deb, .rpm), артефакти cask окрім застосунку і бінарників
(pkg, installer) і два файли на одну платформу.
Маніфест зберігає лише те, що потрібно ketch: name, source, kind для
застосунку, bin і по одному шаблону [asset.target] на платформу, де версію
замінено на *, щоб шаблон пасував і далі. Він починається з рядка
# Written by `ketch import …` ; файл із таким ім'ям без цього рядка — ваш,
і import відмовляється його замінювати.
Повторний запуск безпечний: якщо перетворений маніфест і встановлена
версія вже збігаються з джерелом, друкується
Everything is up to date і нічого не змінюється. Нова версія вище за течією
переписує файл і оновлює пакет; змінений маніфест за тієї самої версії
перевстановлює його.
Адреси каталогів можна перенаправити (дзеркало або тестовий двійник) через
KETCH_IMPORT_BREW, KETCH_IMPORT_WINGET_API, KETCH_IMPORT_WINGET_RAW,
KETCH_IMPORT_ARCH, KETCH_IMPORT_ARCH_GITLAB і KETCH_IMPORT_AUR. Список
winget іде через GitHub API, тому використовується токен GitHub, якщо його задано.
Перегляд
ketch list
ketch list [local|remote] [--json] [--names-only] [--pre] [--draft], аліас — ketch ls.
Показує, що встановлено, що пропонує реєстр, або і те, і те в одній таблиці з найновішою версією кожного пакета.
| Команда | Показує | Мережа |
|---|---|---|
ketch list local | Встановлені пакети із запису про встановлення | Ніколи |
ketch list remote | Пакети, які пропонує реєстр, з останньою версією | Потрібна; без неї помилка |
ketch list | І те, і те, по рядку на пакет, із сортуванням за назвою | Використовується для latest; без неї — локальна частина |
«Реєстр» тут — це локальна копія, яку завантажує ketch update, плюс ваші власні
маніфести в ~/.ketch/manifests (ваші перемагають, якщо назва є і там, і там). Ті нечисленні
пакети, що вкомпільовані в ketch як запасний варіант, не перелічуються; запустіть ketch update,
щоб побачити реєстр, з якого їх узято.
Стовпці.
package— назва, за якою пакет встановлюють, оновлюють або видаляють.installed— встановлена версія, а за нею канал, за яким слідує пакет, якщо він не стабільний:(pre)— пре-релізи (встановлено з--preабо з тега пре-релізу),(draft)— чернетки GitHub (встановлено з--draft),(dev)— плаваючий тег на кшталтnightly; у пакета на стабільному каналі за замовчуванням позначки немає.(pinned)означає, що його утримуєketch pin;(+N retained)означає, що N попередніх версій збережено дляketch rollback. Порожньо для невстановленого пакета.latest— найновіший реліз джерела пакета. За ним іде(update available), якщо це оновлення для встановленої версії.?означає, що джерело не відповіло. Порожньо для пакета, встановленого з локального шляху, який не має upstream, щоб запитати.source— звідки береться пакет. Для встановленого пакета це те, звідки його встановлено й звідки прийде його наступна версія.description(лишеremote) — однорядковий опис із реєстру, обрізаний за шириною термінала (COLUMNSзадає іншу ширину; під час виводу в пайп нічого не обрізається).
Маркери. У ketch list у встановленого пакета в першому стовпці стоїть *.
У кольоровому терміналі маркер — ●, назва виділена жирним, а
(update available) — жовтим. CLICOLOR_FORCE=1 вмикає колір навіть під час виводу в
пайп; --no-color і NO_COLOR вимикають його.
Наявність оновлення визначається тим самим правилом, що в ketch outdated, для
будь-якого каналу. latest — найновіший реліз, про який повідомляє джерело пакета, з
того самого запиту, що робить ketch outdated: лише стабільні релізи, якщо не вказано
--pre, не задано prerelease = true у config.toml або в маніфесті пакета і пакет
не встановлено на каналі pre; з --draft або на каналі draft — ще й чернетки.
Ця версія порівнюється зі встановленою, і враховується лише строго новіша; реліз зі
встановленим тегом — ні, з двома винятками. Пакету на каналі draft пропонується
реліз, яким опубліковано його чернетку, під тим самим тегом, а якщо чернетка зникла,
про це виводиться попередження. Пакет на каналі dev шукається під власним тегом, і
latest показує цей тег; нова збірка, опублікована під ним, — це оновлення.
Закріпленому пакету оновлення ніколи не пропонується.
Закріплені пакети перелічуються з обома версіями та (pinned), не отримують
(update available) і не потрапляють у підсумковий рядок. ketch unpin знову дозволяє їм
оновлюватися.
Пакети не з реєстру — встановлені з owner/repo або
іншого посилання scheme:id — теж перелічуються, і їхній latest береться з
їхнього власного джерела. Пакет, встановлений з локального шляху (ketch install --path),
показується з порожнім latest.
Під таблицею рядок N updates available: ketch upgrade <names> називає кожен
пакет з оновленням у вигляді команди, яка оновить їх усі.
Офлайн і пакети, що не відповідають. Останні версії запитуються
паралельно (по jobs за раз, типово 4), а поки вони завантажуються, у stderr іде лічильник.
Джерело, що не відповіло, — уперлося в ліміт, зникло, недоступне — показує ? у
latest, а під таблицею один рядок називає кожен такий пакет; усі інші рядки
однаково друкуються, і команда однаково завершується успішно. Коли не відповідає жодне джерело,
вважається, що мережі немає: ketch list друкує таблицю ketch list local,
за нею latest: offline, і повертає 0, а ketch list remote,
якому без мережі нічого показати, повертає ненульовий код.
Відповіді кешуються на 10 хвилин у ~/.ketch/cache/latest.json для кожного джерела
й кожного запитаного каналу (stable, pre, draft або власний тег пакета dev), тож два
виклики поспіль звертаються до GitHub один раз. Файл кешу, записаний старішою версією
ketch, ігнорується й замінюється. Кешуються лише
відповіді, але не збої. Видаліть файл, щоб запитати наново раніше;
ketch outdated і ketch upgrade його ніколи не читають.
--json друкує для кожного режиму:
local— масив{"name", "installed", "channel", "pinned", "retained", "source"}, деretained— список версій, збережених для відкату, аchannel— канал релізів, за яким слідує встановлення (stable,pre,draftабоdev).remote— масив{"name", "latest", "description", "source"}, деlatestдорівнюєnullдля джерела, що не відповіло.- без режиму —
{"packages": [...], "unreachable": [...]}. Кожен пакет —{"name", "installed", "channel", "latest", "update_available", "pinned", "source"};installedіchannelдорівнюютьnull, якщо пакет не встановлено, аlatestдорівнюєnull, якщо версія невідома.unreachableназиває пакети, чийlatestневідомий. Офлайнpackagesмістить лише встановлені пакети.
--pre шукає пре-релізи під час заповнення стовпця latest для кожного рядка, як
ketch outdated --pre. У ketch list local він нічого не змінює: той не питає джерела.
--draft шукає ще й чернетки релізів GitHub, а разом із ними пре-релізи, у
стовпці latest встановлених пакетів, як ketch outdated --draft. Рядки реєстру не
зачіпаються: чернетки видно лише токену з правом push у репозиторій. Пакет, у джерела
якого чернеток немає, запитується без них, а без такого токена рядок показує ?.
--names-only друкує лише назви, по одній на рядок, для кожного режиму; до мережі він ніколи
не звертається.
Змінено в 0.7. Раніше ketch list показував лише встановлені пакети, а його
--json був масивом записів про встановлення; тепер він показує все в
описаному вище вигляді. Скриптам, яким потрібні встановлені пакети, слід викликати
ketch list local. ketch list --installed — прихований аліас
ketch list local, збережений на один реліз.
$ ketch list local
package installed source
fd v10.4.2 github:sharkdp/fd
ripgrep 14.1.1 github:BurntSushi/ripgrep
rtok v0.9.0 (pinned) github:pyrlyn/rtok
$ ketch list remote
package latest description
cox v0.1.0 Modular terminal coding agent
ketch v0.6.1 Catch releases straight from GitHub
ripgrep 15.2.0 Recursively search directories for a regex pattern
rtok v0.10.0 Reduce the context AI coding agents must carry
runa ? Run AI models locally (GGUF via llama.cpp) or through the OpenAI and Anthropic APIs
swarfr v0.1.0 Shrink Cargo target directories without slowing builds
? means the latest release could not be checked: runa
$ ketch list
package installed latest source
cox v0.1.0 github:pyrlyn/cox
* fd v10.4.2 v10.5.0 (update available) github:sharkdp/fd
ketch v0.6.1 github:pyrlyn/ketch
* ripgrep 14.1.1 15.2.0 (update available) github:BurntSushi/ripgrep
* rtok v0.9.0 (pinned) v0.10.0 github:pyrlyn/rtok
runa ? github:pyrlyn/runa
swarfr v0.1.0 github:listepo/swarfr
2 updates available: ketch upgrade fd ripgrep
? means the latest release could not be checked: runa
Без мережі:
$ ketch list
package installed source
fd v10.4.2 github:sharkdp/fd
ripgrep 14.1.1 github:BurntSushi/ripgrep
rtok v0.9.0 (pinned) github:pyrlyn/rtok
latest: offline
$ ketch list remote
error could not reach any package source to check the latest versions; `ketch list local` works offline
ketch list local --json # встановлені пакети, для скриптів
ketch list --names-only # усі назви пакетів, по одній на рядок
ketch list remote --json # реєстр з останніми версіями
ketch outdated [--json] [--pre] [--draft]
Показує встановлені пакети, що мають новіший реліз. Недоступне джерело —
це попередження, а не помилка, якщо тільки взагалі нічого не вдалося перевірити.
--draft порівнює й із чернетками релізів GitHub, як в upgrade. Пакет
на плаваючому тезі застарів, коли його тег указує на іншу збірку.
ketch outdated
ketch outdated --json # {"status","outdated","failed","unreachable"}
ketch info <PKG> [--assets] [--releases [--draft]] [--json]
Показує подробиці про пакет, встановлений чи ні: джерело, опис, останню та встановлену версії, посилання, зберігання, перевірку.
ketch info BurntSushi/ripgrep
ketch info rg --assets # кожен асет релізу з оцінкою та її причиною
ketch info rg --releases # нижче — та сама таблиця, що друкує `ketch releases`
--releases додає під подробицями релізи пакета (20 найновіших) у форматі
ketch releases, а --draft перелічує серед них чернетки, як
ketch releases --draft; з --json це масив releases. Недоступне джерело — попередження,
а розділ пропускається (у JSON — null).
Аліас — ketch show.
ketch releases <PKG> [--pre] [--draft] [-n <LIMIT>] [--json]
Перелічує релізи, опубліковані джерелом пакета, від нових до старих — у порядку, у якому їх віддає джерело, — і позначає встановлений. Потрібна мережа.
$ ketch releases fd -n 3
tag version published kind
v10.5.0 10.5.0 2026-08-26 stable
* v10.4.2 10.4.2 2026-03-10 stable
v10.4.1 10.4.1 2026-03-08 stable
tagіversion— тег релізу та версія, яку ketch читає з нього й порівнює, без написання тега (v10.4.2читається як10.4.2). У тега, що взагалі не версія (nightly), уversionстоїть-.published— день публікації за даними джерела або-.kind—stable;pre— реліз, який форж позначає як пре-реліз або в чиєї версії є пре-релізна частина (2.0.0-rc.1);dev— тег, що не є версією (плаваючийnightly, навіть якщо його позначено і як пре-реліз);draft— неопублікований реліз GitHub, перелічується лише з--draftабо для пакета, встановленого на каналіdraft.*у першому стовпці (●у кольоровому терміналі) позначає реліз, з якого встановлено пакет, якщо він є серед перелічених.
Без --pre перелічуються лише стабільні релізи, якщо не задано prerelease = true
у config.toml або маніфесті пакета і пакет не встановлено на каналі pre чи dev (GitHub позначає nightly як пререліз); репозиторій,
у якому ніколи не було стабільного релізу, перелічує свої пре-релізи в будь-якому разі.
--draft перелічує ще й чернетки GitHub, а разом із ними пре-релізи; пакет,
встановлений з --draft, перелічує їх і без прапорця. Як і для
ketch install --draft, потрібен токен з правом push у репозиторій
(KETCH_GITHUB_TOKEN, GITHUB_TOKEN, GH_TOKEN або github_token), а без нього
команда зупиняється й називає, чого бракує; в інших джерел чернеток немає, і вони
відхиляють прапорець.
-n (типово 20, не менше 1) обмежує список; джерело може повернути менше.
Порожній список друкує no releases.
--json друкує масив {"tag", "version", "published_at", "kind", "installed"};
version і published_at дорівнюють null, коли невідомі.
ketch releases ripgrep
ketch releases sharkdp/fd --pre --json
ketch why <PKG> [--json]
Пояснює, як було б розв'язано пакет, не встановлюючи його: який рівень маніфестів відповів, який реліз і асет було обрано й чому.
ketch why sharkdp/[email protected]
ketch why rg --json
ketch changelog <PKG> [--latest] [--file] [--release]
Показує, що змінилося: файл changelog, що постачається з пакетом, або нотатки до релізу, опубліковані разом із ним. Для встановленої версії віддає перевагу файлу на диску; інакше використовує нотатки.
ketch changelog ripgrep # встановлена версія
ketch changelog ripgrep --latest # натомість найновіший реліз
ketch changelog ripgrep --file # лише файл із постачання
ketch changelog ripgrep --release # лише опубліковані нотатки
ketch search <QUERY>... [-n <LIMIT>]
Шукає на GitHub (і в плагінах із пошуком) репозиторії, які можна встановити.
ketch search fuzzy finder
ketch search ripgrep -n 5
Відтворення
ketch lock [--file <FILE>] [--check]
Записує ./ketch.lock за тим, що встановлено, — відтворюваний запис
утиліт машини, закріплених на точних релізах. Див. LOCKFILE.md.
ketch lock # записати ./ketch.lock
ketch lock --check # чи не розійшлося дерево з ним?
ketch lock -f tools.lock
ketch sync [--file <FILE>] [--prune] [--dry-run]
Встановлює все, що названо в ketch.lock, у названих там версіях. Пакет, не
згаданий у lock-файлі, не чіпається, якщо не передано --prune (який спершу питає,
бо може знищити чиюсь роботу).
ketch sync # лише відсутні або розбіжні пакети
ketch sync --dry-run # показати план +/~/−, нічого не змінюючи
ketch sync --prune --yes # також видалити зайве, не питаючи
Історія
ketch history [PKG] [-n <LIMIT>] [--json]
Показує, що встановлювалося, оновлювалося й видалялося, починаючи з найновішого. Без пакета показує все дерево на одній часовій шкалі.
ketch history
ketch history ripgrep -n 10
ketch stats [--json]
Підсумовує все, що ketch записав у stats.db.
ketch stats
ketch stats --json
Реєстр і джерела
ketch update
Оновлює реєстр пакетів у ~/.ketch/registry. (Для встановлених
пакетів див. upgrade.)
ketch update
Запускається автоматично на початку install і upgrade, якщо
auto_update не дорівнює false у ~/.ketch/config.toml
(KETCH_AUTO_UPDATE=false).
ketch registry validate [DIR] [--fixture <DIR>] [--changed <NAME>] [--json]
Перевіряє дерево реєстру так само, як pre-push хук: кожен ketch.toml розібрано й
перевірено, плюс конфлікти назв. --fixture як додатковий доказ виконує офлайн-встановлення записів із
локальних файлів.
ketch registry validate
ketch registry validate ./ketch-registry --fixture ./fixtures
ketch registry status [--json]
Показує вік і джерело локальної копії реєстру, нічого не завантажуючи.
ketch registry status
ketch registry push [--file <FILE>] [--registry <REPO>] [--dry-run] [--yes]
Порівнює ketch.toml цього проєкту з копією в реєстрі й відкриває з ним пул-реквест.
Для нового пакета відкриває одразу; для оновлення показує диф і питає;
якщо файли ідентичні, повідомляє unchanged і нічого не відкриває. Див.
REGISTRY.md.
KETCH_GITHUB_TOKEN=... ketch registry push
ketch registry push --dry-run
ketch plugin list [--json] / ketch plugin dir
Показує виявлені плагіни джерел (ketch-source-<scheme> у ~/.ketch/plugins
і в PATH) або друкує каталог плагінів. Див. PLUGINS.md.
ketch plugin list
ketch plugin dir
Оточення
ketch doctor [--fix] [--json]
Перевіряє оточення й дерево встановлення: версію, налаштування PATH, перевірки
платформи, лог, вік реєстру, відповідність сховища state.json. Повертає ненульовий код, якщо
перевірка не пройшла. У Windows також попереджає про записи в користувацькому PATH, що вказують на каталог bin
ketch, теки якого вже немає, — цього кореня або будь-якої .ketch\bin.
ketch doctor
ketch doctor --fix # виправити те, що можна виправити (налаштування PATH)
ketch path [install|uninstall|status]
Додає каталог bin ketch до PATH. Просто ketch path показує таблицю
стану; це типова підкоманда.
ketch path # каталог bin, стан PATH, таблиця за оболонками
ketch path install # змінити файли запуску оболонок (питає для кожної)
ketch path install --print # надрукувати рядок, щоб додати його вручну
ketch path install --all # діяти для всіх відомих оболонок
ketch path uninstall # знову прибрати блок
ketch config create [--file <FILE>] [--force] [--yes]
Записує конфігурацію пакета (ketch.toml) за відповідями на запитання — джерело, назва,
записи bin, шаблони асетів, — потім показує й записує файл. Пакет, який
ставить посилання на бінарники, має називати команду, яку додає до PATH, тому перший запис bin
команда запитує, а не пропонує; його назва типово — назва пакета.
Відповіді можна передати через stdin, по одній на рядок. Див. MANIFESTS.md.
ketch config create
ketch config create --file ./ketch.toml --yes
ketch config reset [--yes]
Записує config.toml у корені ketch зі скомпільованими типовими значеннями. Спершу питає,
якщо не передано --yes; зберігає резервну копію наявного файлу поруч із ним як
config.toml.bak-<unix-seconds>, якщо файл є й не збігається з уже
наявною поруч резервною копією.
ketch config reset
ketch config reset --yes
ketch completions <SHELL> [--install]
Друкує скрипт автодоповнення для оболонки або з --install встановлює його в
користувацький каталог автодоповнень оболонки.
ketch completions zsh > _ketch
ketch completions bash --install
Скрипти для bash і PowerShell також доповнюють назви пакетів: встановлених — після
uninstall, upgrade, pin, unpin, link, unlink, info, releases,
why, changelog і rollback, і назви з локальної копії реєстру — після
install і search. Скрипт запитує їх у бінарника внутрішньою командою
ketch __complete <installed|registry> [PREFIX], яка читає файл стану та
вже наявний на диску реєстр і ніколи не звертається до мережі. --root, вказаний раніше
в командному рядку, враховується.
--install записує скрипт bash у
${XDG_DATA_HOME:-~/.local/share}/bash-completion/completions/ketch, звідки
bash-completion 2 завантажує його під час першого використання. У macOS для цього системної
оболонки замало: /bin/bash — це 3.2, а bash-completion 2 потрібен bash 4.2 або новіший.
Встановіть свіжий bash і bash-completion 2 (через Homebrew:
brew install bash bash-completion@2), зробіть цей bash оболонкою входу й
підключайте bash_completion з bash-completion у ~/.bashrc, як сказано в його
примітках. Сам скрипт працює й під bash
3.2, тож eval "$(ketch completions bash)" у ~/.bashrc працює і без них.
У Windows --install (і ketch self install, який встановлює скрипти для всіх
оболонок) також вмикає автодоповнення, бо жодна з оболонок не завантажує
каталог автодоповнень сама:
- PowerShell. Скрипт потрапляє в
Documents\PowerShell\Completions\ketch.ps1, а блок між# >>> ketch >>>і# <<< ketch <<<у профілі CurrentUserAllHosts для PowerShell 7 (Documents\PowerShell\profile.ps1) і Windows PowerShell 5.1 (Documents\WindowsPowerShell\profile.ps1) підключає його через dot-sourcing. Documents — це тека, про яку повідомляє PowerShell, тож перенаправлення в OneDrive враховується. Ще не наявний профіль створюється, лише якщо цю редакцію встановлено і її політика виконання дозволяє локальні скрипти; інакше ketch пояснює, чому не став його чіпати. - cmd. У cmd немає програмованого автодоповнення, тому він отримує макроси doskey:
ki(ketch install),ku(ketch upgrade),kl(ketch list) іkun(ketch uninstall), кожен з яких передає свої аргументи далі. Вони лежать у<root>\share\ketch\ketch.doskeyі завантажуються командоюdoskey /macrofile="…", доданою доHKCU\Software\Microsoft\Command Processor\AutoRunчерез&після того, що AutoRun уже виконує.
ketch self uninstall прибирає блоки з профілів (видаляючи профіль, у якому
більше нічого не було) і видаляє з AutoRun рівно свою команду, лишаючи
попереднє значення як було або видаляючи значення, якщо в ньому була лише команда ketch.
Сам ketch
ketch self install [--force] [--link-dir <DIR>]
Встановлює цей реліз ketch як пакет — у сховище й каталог bin. Саме це запускають інсталятори curl/PowerShell/Homebrew.
ketch self install
ketch self upgrade [--dry-run] [--force] [--pre] [--yes]
Оновлює ketch до останнього релізу. Аліас — ketch self update. ketch,
встановлений через mise й жодного разу не встановлений через self install, оновлює mise:
команда відмовляється й називає mise upgrade.
--pre бере найновіший реліз, включно з пре-релізами, а не останній реліз за
версією GitHub. Релізи macOS-застосунку desktop-v* не беруться ніколи. Той
самий прапорець приймають інсталятори: install.sh --pre та
install.ps1 --pre. Без прапорця нічого не змінюється.
ketch self upgrade
ketch self upgrade --dry-run
ketch self upgrade --pre
ketch self version
Друкує запущену версію та де вона розташована (target, корінь, бінарник, PATH).
ketch self version
ketch self uninstall [--keep-packages] [--dry-run] [--yes]
Видаляє ketch і все, що він встановив, назавжди. Перелічує, що збирається
видалити, і спершу питає. --keep-packages видаляє лише ketch. Для ketch,
встановленого через mise, також питає, чи запустити mise unuse -g для його власної копії;
--yes відповідає й на це.
У Windows запущений ketch.exe не може видалити сам себе, тому решта
кореня видаляється фоновим процесом після виходу ketch.
Власні каталоги кореня (bin, store, cache, …) очищуються, лише якщо
корінь створив ketch — тоді в ньому лежить мітка .ketch-root — або корінь
стандартний, ~/.ketch. Корінь, що існував раніше, наприклад ~/.local
чи /usr/local, і сам домашній каталог зберігають усе, що ketch там не
записував.
У Windows він також видаляє те, що ketch записав до реєстру Windows. Зараз це
лише каталог bin у користувацькому PATH (HKCU\Environment\Path), записаний
install.ps1 або ketch path install. Запис знаходиться хоч би як він був
написаний: регістр, лапки, / чи \, кінцевий роздільник або коротка назва
8.3. --keep-packages лишає його, як і блоки в оболонках, бо
він потрібен пакетам, що лишаються в каталозі bin. ketch ніколи не реєструє себе в «Програмах і
можливостях», тож видаляти там нічого.
Він також видаляє блоки з профілів PowerShell і додаток до AutoRun cmd,
які вмикають автодоповнення, — їх і з --keep-packages, бо обидва
завантажують сам ketch.
ketch self uninstall --dry-run
ketch self uninstall --keep-packages