Envoyez un fichier Markdown depuis un terminal et récupérez son lien. Un seul fichier JavaScript sans dépendances, qui parle à la même API et aux mêmes convertisseurs que le site.
Lire la référence de la ligne de commande
`cli/tp.mjs`, dans le dépôt public, est un client de la même API. C’est un fichier unique, sans rien à installer à côté — un outil qui tourne en CI ne devrait pas traîner un arbre de paquets derrière lui —, et il demande Node 20 ou plus récent.
Depuis une copie du dépôt, il se lance avec `node cli/tp.mjs` ; son paquet nomme la commande `tp`, et c’est ainsi que les exemples de cette page sont écrits. `tp --help` liste chaque commande et chaque option.
C’est aussi ce qu’exécute la GitHub Action : une commande qui fonctionne sur votre machine se comporte de la même façon dans un workflow.
`tp push README.md --share` convertit le fichier, le conserve dans votre compte et affiche son lien. Un `.html`, `.csv`, `.tsv`, `.json` ou `.enex` d’Evernote envoyé est converti en Markdown par le serveur à l’arrivée, au lieu d’être stocké comme s’il était déjà du Markdown.
Les fichiers que l’API reçoit en octets plutôt qu’en texte — `.docx`, `.xlsx`, `.pptx`, `.epub`, `.odt`, `.rtf` et les zips d’export — sont refusés, avec l’adresse de la page du site qui les lit dans le navigateur.
`--merge` enchaîne plusieurs fichiers Markdown en un seul document, dans l’ordre donné, avec un filet entre eux, et `--name` le nomme : `tp push docs/*.md --merge --share --name handbook.md`.
`--share` crée un lien que quiconque le détient peut ouvrir, et `--share people` réserve le document à des lecteurs nommés, dont vous ajoutez les adresses sur le site. `--expires 7d`, `12h` ou `2026-12-31` met fin au lien — une date seule valant la fin de ce jour-là chez vous —, et `--password` le protège par un mot de passe lu dans `TP_SHARE_PASSWORD`, jamais dans un argument, où il resterait dans l’historique du shell.
`tp push notes.md --update <id>` envoie un nouveau texte à un document qui existe déjà. Son id, son lien, son mot de passe et sa date de fin restent tels quels, et le texte remplacé est gardé sur le serveur comme révision, les dix plus récentes. Renvoyer le même texte ne change rien.
`--replaces <id>` fait exprès l’inverse : il crée un nouveau document, avec son propre id et, une fois partagé, son propre lien, et l’enregistre comme version suivante d’un document antérieur, ce que `tp versions <id>` liste comme une chaîne. Un lien déjà envoyé continue de montrer ce qu’il montrait.
`tp list` montre ce que contient le compte, et `--q` cherche dans le texte des documents. `tp rm <id>` envoie un document à la Corbeille, où il attend 14 jours ; `tp usage` affiche la part utilisée des 250 Mo et des 5 000 documents ; `tp summary <id>` demande un court résumé, rédigé une fois puis mis en cache.
`--folder "Team/Notes"` lors d’un envoi range le document selon son chemin et crée toute partie du chemin qui n’existe pas encore. `tp folders` affiche l’arborescence avec les id, `tp mkdir` et `tp mv` créent et déplacent, `tp rmdir` supprime un dossier et fait remonter son contenu d’un niveau, et `tp share-folder` partage un dossier entier avec `--link`, `--people` ou `--private`, avec les mêmes `--expires` et `--password`.
`tp login tp_live_…` enregistre une clé dans `~/.config/tp/config.json`, lisible par vous seul. Une clé peut aussi venir de `--key` ou de `TP_API_KEY`, lues en premier ; la variable d’environnement est celle qui convient en CI, car `tp login` laisse la clé dans l’historique du shell.
`--json` affiche la réponse de l’API elle-même au lieu des lignes de résumé — c’est ce que lit l’Action —, et `TP_HOST` fait pointer l’outil vers un autre déploiement. Un échec affiche le message de l’API avec son statut et se termine par un code de sortie non nul, pour qu’un script ou un pipeline s’arrête là où il le doit.