Présentation

proc est un utilitaire en ligne de commande destiné à la gestion sémantique des processus sur macOS, Linux et Windows. Il accepte comme cibles un port, un PID, un nom ou un chemin de fichier, ce qui élimine la nécessité de mémoriser les combinaisons d’options de lsof, ps ou kill. L’installation se fait en une ligne via Homebrew : 

brew install yazeed/proc/proc
. L’objectif principal est de fournir une interface unique capable de remplacer plusieurs pipelines Unix classiques.

Fonctionnalités principales

Le préfixe « : » désigne un port ; proc kill :3000 envoie immédiatement un SIGKILL au processus à l’écoute, avec une confirmation interactive ou un mode --dry-run qui ne fait qu’afficher l’action prévue. D’autres sous‑commandes couvrent les besoins courants : proc on :8080 liste les processus, proc why :3000 montre la chaîne de parenté, proc free :3000 libère le port, proc wait node boucle tant que le processus node existe, et proc orphans --in . recherche les processus orphelins dans le répertoire courant. Toutes les commandes acceptent les options --json pour un rendu machine‑lisible et --in pour restreindre l’opération à un projet.

Architecture et intégration

Chaque sous‑commande renvoie un code de sortie normalisé : 0 (succès), 1 (erreur), 2 (non trouvé), 3 (permission refusée), 4 (entrée invalide). Cette constance facilite l’intégration dans des scripts automatisés ou des agents IA tels que Claude Code, Codex, Cursor ou Gemini CLI, qui peuvent interroger proc sans analyser de tableaux textuels. Exemple d’utilisation JSON :

proc on :8080 --json | jq '.process | {pid, cwd, uptime_secs}'
{
  "pid": 177,
  "cwd": "/home/dev/code/shop",
  "uptime_secs": 35
}

Le rendu JSON contient les champs essentiels (PID, répertoire de travail, durée d’exécution), ce qui permet aux orchestrateurs de décision de filtrer ou d’agir en fonction de critères précis.

Limites et perspectives

Le fonctionnement repose sur les appels système natifs de chaque OS : kill sous Unix, les API de gestion de processus sous Windows. Par conséquent, les privilèges d’administrateur restent requis pour toucher des processus appartenant à d’autres utilisateurs, ce qui se traduit par le code de sortie 3. L’outil ne fournit pas de mécanisme de découverte de processus au-delà de ce que les API sous‑jacentes offrent, ce qui peut limiter son usage sur des systèmes où lsof ou les équivalents ne sont pas installés. Enfin, l’absence de documentation publique détaillée sur la gestion des signaux sous Windows laisse une zone d’incertitude quant à la portabilité exacte du SIGKILL sur cette plateforme.