'ajean where > fichier.txt' n'ecrivait rien dans le fichier et 'ajean help |
findstr x' ne transmettait rien : tout partait sur la console.
Cause : le binaire etant en sous-systeme GUI, setupConsole reouvrait stdout,
stderr et stdin sur CONOUT$/CONIN$ pour avoir ou ecrire. Il ecrasait ce faisant
la redirection que le shell avait posee. Le test naif ne suffit pas :
AttachConsole REMPLACE lui-meme les handles standard par ceux de la console,
donc les interroger apres le rattachement ne montre jamais qu'une console. On
releve donc leur type AVANT d'attacher, et on ne reouvre que ceux qui sont
reellement inutilisables.
Verifie sur un binaire compile comme celui de la release (sous-systeme GUI) :
redirection vers un fichier, tube vers findstr, et affichage console inchange.
Surface visible passee en AJEAN : aide de la CLI, messages, invite du chat
terminal, commentaires, README, metadonnees Windows du binaire
(InternalName / OriginalFilename).
Les reglages s'appellent desormais AJEAN_* (AJEAN_HOME, AJEAN_MODEL_DIRS,
AJEAN_DL_CONNS, AJEAN_LINK_URL, AJEAN_ACME_EMAIL, AJEAN_SERVICE), avec
l'ancien nom JEAN_* toujours lu en second via envAny(). Ces variables sont
posees a la main dans des shells, des units, des docker-compose et des
scripts de deploiement qu'on ne peut pas retrouver : cesser de les lire
ferait retomber silencieusement un reglage sur sa valeur par defaut.
Migration one-shot du dossier de donnees retentee dans la fenetre ou
l'installateur Windows a arrete toutes les instances, seule fenetre ou le
rename peut aboutir. Le chemin du binaire est recalcule juste apres, sinon
on reinstallerait dans le dossier qu'on vient de deplacer.
Deux choses volontairement NON renommees, parce que les renommer casserait
des utilisateurs sans rien apporter :
- "model": "jean", le nom expose sur l'endpoint compatible OpenAI. Des
integrations externes le configurent en dur.
- les cles localStorage (jean-theme, jean.sys...). Les renommer
reinitialiserait theme, preferences d'affichage et prompt systeme dans le
navigateur de chaque utilisateur.
Le plist launchd recevait /usr/local/bin/jean en dur : le chemin est
desormais injecte, sinon le daemon macOS aurait refuse de demarrer apres le
renommage.
index.html regenere depuis ui/src via go generate.
Socle du renommage jean -> AJEAN, sans aucun impact visible pour le parc
installe. Trois briques :
- module github.com/nathaninline/ajean, cmd/ajean, internal/ajean,
package ajean. Purement interne.
- AjeanHome() remplace JeanHome(). Les defauts deviennent
%ProgramData%\ajean et /etc/ajean, avec migration du dossier existant
au premier lancement. La migration est un os.Rename dans le dossier
parent de l'ancien chemin : intra-volume, donc atomique et instantane
meme avec des .gguf de plusieurs dizaines de Go. Si le rename echoue
(handle ouvert sous Windows, droits, volume en lecture seule) on
CONTINUE sur l'ancien chemin et on retentera : jamais de copie, jamais
de suppression, le pire cas est "rien n'a bouge".
$AJEAN_HOME et $JEAN_HOME restent tous deux honores, ainsi que
/etc/default/ajean et /etc/default/jean : un chemin impose a la main
est un ordre, on ne le migre pas.
- l'auto-MAJ accepte desormais ajean-<os>-<arch> ET jean-<os>-<arch>,
dans cet ordre. Indispensable dans les deux sens : les binaires deja
installes ne connaissent que jean-*, et ce binaire-ci doit pouvoir
s'installer depuis une release anterieure au renommage.
Couvert par des tests, dont le repli quand un handle ouvert bloque le
rename sous Windows.
nathaninline