[WIP] Internationalisation: proof of concept

[rlepigre]

J'ai passé un peu de temps à essayer de voir comment pourrait fonctionner l'internationalisation des missions, et voilà le résultat. En gros l'idée est d'avoir un dossier locale dans chaque mission, avec des fichiers .po pour chaque langue supportée. Par example, j'ai crée des fichiers locale/fr.po et locale/en.po pour la mission 1.

Pendant l'exécution de start.sh ces fichiers sont transformés en fichiers .mo (par msgfmt) et placé sous un dossier locale à la racine GameShell (avec l'arborescence qui va bien). Les fichiers ainsi crées prennent le nom du dossier de la mission (plus l'extension), ce qui veut dire qu'ils sont activés en exportant TEXTDOMAIN=nom_de_la_mission. En gros, ça veut dire qu'il faut s'arranger pour que les scripts de la mission (et les éventuels fichiers binaires) soient toujours lancés dans un environnement ou TEXTDOMAIN contient le nom du dossier de la mission. (J'ai pris pour convention de définir TEXTDOMAIN="gash" en dehors de l'exécution du code des missions.)

L'autre chose à faire c'est d'exporter TEXTDOMAINDIR="$GASH_BASE/locale" dans start.sh.

Un autre point intéressant est qu'on peut utiliser la variable LANGUAGE pour controller la langues des messages. On peut même faire un truc comme LANGUAGE=fr_FR:fr:en_GB:en_US:en pour que le système donne la priorité au Français mais se rabatte sur l'anglais s'il n'est pas disponible. Il faudrait quand même s'assurer que les locales soient dispo pour une des langues du système (et que LANGUAGE est définie) parce que sinon gettext ne donne que la clé en résultat.

Dernière remarque : j'ai utilisé un fichier goal.sh dans la mission pour pouvoir utiliser gettext. C'est plus uniforme, et j'imagine que pour des missions compliquées on pourrait avoir besoin de générer les instructions donc c'est pas idiot. Une autre possibilité serait de s'assurer que les fichiers locales définissent toujours une entrée avec la clé "Mission goal", et on pourrait appeler gettext directement depuis lib/game_shell.sh.

Qu'en penses-tu Pierre?

[phyver]

Bon, c'est les vacances par ici, et j'en avais marre de gettext, alors je viens de rajouter l'archive exécutable. C'est vraiment marrant. Le script bin/archive.sh produit un fichier exécutable GameShell.sh que l'on peut lancer directement. Quand on quitte, cela produit un nouveau fichier GameShell-save.sh qui contient l'état courant. On peut donc le relancer. Toutes les options donnés au script sont passées à start.sh.

J'ai hésité, mais finalement, je ne créé pas de GameShell-save_001.sh, GameShell-save_002.sh etc.

[rlepigre]

Bon, c'est les vacances par ici, et j'en avais marre de gettext, alors je viens de rajouter l'archive exécutable. C'est vraiment marrant.

En effet, ça a l'air rigolo, il faut que j'essaye !

J'ai joué une partie complète (en anglais) ce soir, et voilà quelques remarques / suggestions / idées :

• Il faudrait varier un peu plus les lieux des missions.
  • Mission 10: mettre les ornaments dans la salle du throne ?
  • Mission 9: enlever la suie dans une cheminée et laisser les nids d'oiseaux ?
  • On pourrait bouger une des missions avec des rats dans une Cuisine?
  • En général je trouve qu'il se passe trop de choses dans la cave.
  • Tout ça c'est pas génial pour s’entraîner à utiliser ls et cd.
• Le très long couloir est un peu chiant avec l'affichage du chemin courant.
  • C'est pas un problème si on ne passe moins de temps dedans.
  • On pourrait ajouter un Jardin contenant le Labyrinthe dans le chateau?
• Il y a parfois beaucoup de fichiers dans un dossier (par exemple le formage dans la cave), donc c'est un peu chiant quand tu fais ls. Ce n'est pas un problème si le dossier n'est pas un lieu important.

Quelques idées de missions qu'on pourrais ajouter :

• Ramasser le formage dispersé par les souris et le ranger dans la reserve (dans la cave) par type: un dossier à créer par type (camembert, reblochon, ...) puis mv avec des patterns qui vont bien.
• Ajouter un alias pick pour ramasser un objet (le déplacer dans le coffre de la cabane), un alias inventory montrant le contenu du coffre avec des numéros par ligne, un alias drop N pour déposer l'objet N de l'inventaire dans le dossier courant.
• Reception d'un colis (emballage = archive), utilisation de tar.

[phyver]

C'était quoi le problème pour ton commit Fix translation bug in [treasure-msg] handling ?

Je pensais mettre un verbose_source (que je devrais renommer en source_i18n ou similaire), mais comme je ne vois pas où était le problème, je ne sais pas si je vair réintroduire un bug.

[rlepigre]

Le problème était que la variable TEXTDOMAIN n'était pas changée au bon endroit (pour cette ligne), donc j'ai fait en sorte de la définir autours de tout le if ... elif ... else ... fi.

[phyver]

Normalement, ça doit encore marcher... Sinon, je viens de pousser tout ça sur mon dépot, branche "devel". Je ne suis pas sûr de tout comprendre sur les droits, mais j'ai essayé de t'ajouter comme "collaborateur". J'imagine que ça veut dire que tu dois pouvoir pousser dessus. Non ?

[rlepigre]

Normalement, ça doit encore marcher...

Oui et non (cf mon message plus haut, je sais pas pourquoi je l'ai tapé en anglais).

Sinon, je viens de pousser tout ça sur mon dépot, branche "devel". Je ne suis pas sûr de tout comprendre sur les droits, mais j'ai essayé de t'ajouter comme "collaborateur". J'imagine que ça veut dire que tu dois pouvoir pousser dessus. Non ?

Oui, j'ai eu une invitation, normalement je dois pouvoir pousser. On verra bien si ça marche quand j'en ai besoin.

[phyver]

We still need TEXTDOMAIN to be defined around this script sourcing I think.

Or rather it should be mission_source?

Je ne suis pas sûr de voir ce que tu veux dire... Normalement, tous les fichiers "sourcés" pour les missions le sont avec mission_source. Les deux autres endroits où on en a besoin (pour récupérer les fichiers texte dans goal et dans treasure-msg, j'affecte TEXTDOMAIN dans l'appel à gettext.

[rlepigre]

Je ne suis pas sûr de voir ce que tu veux dire... Normalement, tous les fichiers "sourcés" pour les missions le sont avec mission_source. Les deux autres endroits où on en a besoin (pour récupérer les fichiers texte dans goal et dans treasure-msg, j'affecte TEXTDOMAIN dans l'appel à gettext.

Oui, mais justement: la ligne où le treasure-msg.sh est sourcé l'est avec source, pas mission_source. C'est un bug non?

[phyver]

Oups. Ça m'apprendra à faire plus attention quand je ne veux pas commiter toutes les modifs d'un fichier !

[phyver]

Y'a presque une vraie dernière mission !

Les labyrinthes sont mainetenant générés en Python, si disponible. Ça va nettement plus vite !

Par contre, pour le moment, j'ai dupliqué le script python dans plusieurs missions. Ce n'est pas très satisfaisant, mais ça garantit que la mission marche même si celle qui contient le script n'est pas présente. J'en viens d'ailleurs à me demander si le répertoire MISSION_DIR/bin est vraiment nécessaire. Il sert assez peu, et on pourrait laisser les scripts dans MISSION_DIR. Il pourrait servir pour ajouter des programmes utilisateurs, mais je ne m'en suis jamais servi comme ça.

Remarque : l'option -D ne prend plus d'argument. On ne peut pas lancer GameShell sur une autre mission que la première.

[rlepigre]

Y'a presque une vraie dernière mission !

Cool, je viens d'essayer et c'est pas mal ! Par contre il faudrait vraiment une commande gash index pour donner la liste des missions (et pourquoi pas le status pour chaque mission: réussie, abandonnée, pas essayée), sinon on ne sait pas quel numéro de mission donner à la fin.

Est-ce que tu veux que j'ajoute un truc comme ça ?

Les labyrinthes sont mainetenant générés en Python, si disponible. Ça va nettement plus vite !

Cool !

Par contre, pour le moment, j'ai dupliqué le script python dans plusieurs missions. Ce n'est pas très satisfaisant, mais ça garantit que la mission marche même si celle qui contient le script n'est pas présente.

Ouais, c'est un peu dommage de devoir dupliquer le script. Mais bon, ce problème existe déjà dans d'autres missions où une grosse partie des check.sh par exemple est similaire. On pourrait peut-être avoir un dossier quelque part avec des scripts ou bibliothèques partagés pour toutes les missions ? Ceci dit, c'est pas une priorité je pense.

J'en viens d'ailleurs à me demander si le répertoire MISSION_DIR/bin est vraiment nécessaire. Il sert assez peu, et on pourrait laisser les scripts dans MISSION_DIR. Il pourrait servir pour ajouter des programmes utilisateurs, mais je ne m'en suis jamais servi comme ça.

Oui, j'ai toujours pensé qu'il était utile pour ça, je pense qu'on devrait le garder quand même. Je pense qu'on trouvera des idées de missions pour lesquelles il serait utile d'avoir des programmes utilisateurs.

Sinon, qu'est-ce qu'il reste à faire avant de merger tout ça ?

Un truc que j'ai remarqué c'est qu'il y a beaucoup d'endroits où on ne fait pas des phrases dans les messages (par exemple dans les aides pour les commandes utiles). Souvent il n'y a pas de majuscule, et pas de point à la fin. Est-ce que c'est un truc qu'on veut changer où pas ?

[phyver]

Par contre il faudrait vraiment une commande gash index pour donner la liste des missions (et pourquoi pas le status pour chaque mission: réussie, abandonnée, pas essayée), sinon on ne sait pas quel numéro de mission donner à la fin.

Est-ce que tu veux que j'ajoute un truc comme ça ?

Oui, bonne idée ! Les missions sont dans $GASH_DATA/index.txt (une mission par ligne, en ne comptant pas les lignes qui commencent par # et les lignes vides). Le status sera dans le fichier $GASH_DATA/missions.log. Il devrait y avoir "réussie", "abandonnée", "annulée" (problème de dépendances), "pas encore vue", "commencée" (pour la mission en cours).

Ouais, c'est un peu dommage de devoir dupliquer le script. Mais bon, ce problème existe déjà dans d'autres missions où une grosse partie des check.sh par exemple est similaire. On pourrait peut-être avoir un dossier quelque part avec des scripts ou bibliothèques partagés pour toutes les missions ? Ceci dit, c'est pas une priorité je pense.

Exactement. Une idée que j'ai eu, serait d'avoir des dossiers bin ou scripts sur des groupes de missions dans l'arborescence. Par contre, ça oblige à trier les missions la dessus plutôt que sur des critère "sémantiques", et ça ne me plait pas trop. Les autres solutions sont probablement trop compliquées pour être vraiment rentables.

Pour le moment, je préfère dupliquer le code ou ajouter des dépendances : le fichier deps.sh peut vérifier que le script est bien dans $GASH_LOCAL_BIN. Ça impose donc qu'une autre mission fournisse les script.

Sinon, qu'est-ce qu'il reste à faire avant de merger tout ça ?

Je suis en train de repasser sur les missions pour ajouter un fichier test.sh et faire un peu de nettoyage. Ensuite, il faudra repasser sur les messages et les traductions pour corriger / uniformiser (voir plus bas).

Et finalement mettre la documentation à jours, en anglais.

Un truc que j'ai remarqué c'est qu'il y a beaucoup d'endroits où on ne fait pas des phrases dans les messages (par exemple dans les aides pour les commandes utiles). Souvent il n'y a pas de majuscule, et pas de point à la fin. Est-ce que c'est un truc qu'on veut changer où pas ?

Ça serait bien d'uniformiser un peu. Je crois qu'en général, je ne mets pas de vraie phrase, du style

pwd
affiche le répertoire de travail courant

Par contre, quand je veux mettre des détails, je me retrouve avec

grep CHAINE FICHIER
affiche les ligne du fichier qui contiennent la chaine

Si on ne donne pas de fichier, la command agit sur l'entrée standard.

C'est pas génial, mais pas très grave non plus.

Je viens de regarder, et même les pages de manuel ne sont pas uniformes (`man ls` / `man grep` n'utilisent pas la même convention.)
Les pages POSIX ('man 1POSIX ls`, si elles sont installées) semblent plus uniformes, avec des majuscules / points partout. Ça donnerait

grep CHAINE FICHIER Afficher les lignes du fichier qui contiennent la chaine.

-v Inverser en affichant uniquement les lignes qui ne contiennent pas la chaine.

Si on ne donne pas de fichier, la command agit sur l'entrée standard.

Tu as un avis ?

Dans le même style, en anglais, je ne sais jamais trop s'il faut mettre

ls List the content of the current directory.

ou

ls Lists the content of the current directory.

J'ai tendance à mettre la première solution, et toi la seconde. Les pages de manuel semblent être de mon coté. Et Bran ?

[rlepigre]

Par contre il faudrait vraiment une commande gash index pour donner la liste des missions (et pourquoi pas le status pour chaque mission: réussie, abandonnée, pas essayée), sinon on ne sait pas quel numéro de mission donner à la fin. Est-ce que tu veux que j'ajoute un truc comme ça ?

Oui, bonne idée !

OK, je regarde ça dés que j'ai un moment !

Sinon, qu'est-ce qu'il reste à faire avant de merger tout ça ?

Je suis en train de repasser sur les missions pour ajouter un fichier test.sh et faire un peu de nettoyage. Ensuite, il faudra repasser sur les messages et les traductions pour corriger / uniformiser (voir plus bas).

Ouais, dés qu'on a uniformisé un peu tout je ferai jouer Bran pour corriger l'anglais.

Et finalement mettre la documentation à jours, en anglais.

OK, je peux aider pour ça aussi, et il faudrait aussi terminer la documentation pour la création de mission.

Les pages POSIX ('man 1POSIX ls`, si elles sont installées) semblent plus uniformes, avec des majuscules / points partout. Ça donnerait

grep CHAINE FICHIER
  Afficher les lignes du fichier qui contiennent la chaine.

  -v
    Inverser en affichant uniquement les lignes qui ne contiennent pas la chaine.

 Si on ne donne pas de fichier, la command agit sur l'entrée standard.

Tu as un avis ?

Moi je préfères les phrases avec majuscules et point partout.

Dans le même style, en anglais, je ne sais jamais trop s'il faut mettre

ls
  List the content of the current directory.

ou

ls
  Lists the content of the current directory.

J'ai tendance à mettre la première solution, et toi la seconde. Les pages de manuel semblent être de mon coté. Et Bran ?

Bran dit qu'il faut utiliser la second option, en tout cas c'est plus naturel si on fait des phrases.

[phyver]

Merci ! J'ai ajouté les traductions et c'est tout sur la branche devel "officielle". (Pour une raison bizarre, ma branche devel et ta branche ont divergées !)

J'ai nettoyé un peu les missions et fait quelques changements : le labyrinthe est maintenant dans le jardin, on supprime des araignées plutôt que des rats, et la mission 23 (qui combinait head et tail) demande maintenant de combiner tail, nl et fold. J'ai aussi ajouté pas mal de test.sh.

Il faut que je refasse les missions 24 et 25 (des rats dans la cuisine, à la "Ratatouille"), et après, je ferais une pause.

OK pour mettre des majuscules partout :

ls
  Lists the content of the current directory.

grep CHAINE FICHIER
  Affiche les lignes du fichier qui contiennent la chaine.

Je ne l'ai pas fait. On profitera des corrections d'anglais pour uniformiser ça en même temps.

[rlepigre]

Merci ! J'ai ajouté les traductions et c'est tout sur la branche devel "officielle". (Pour une raison bizarre, ma branche devel et ta branche ont divergées !)

Oui, j'ai remarqué ça hier, quand j'ai essayé de pousser vers "devel". On devrait probablement utiliser ma branche sur la PR, ou alors fermer cette PR et en faire une nouvelle basée sur "devel" pour discuter facilement.

J'ai nettoyé un peu les missions et fait quelques changements : le labyrinthe est maintenant dans le jardin, on supprime des araignées plutôt que des rats, et la mission 23 (qui combinait head et tail) demande maintenant de combiner tail, nl et fold. J'ai aussi ajouté pas mal de test.sh.

Il faut que je refasse les missions 24 et 25 (des rats dans la cuisine, à la "Ratatouille"), et après, je ferais une pause.

OK, très bien !

OK pour mettre des majuscules partout :

Je ne l'ai pas fait. On profitera des corrections d'anglais pour uniformiser ça en même temps.

OK, très bien. Je vais essayer de faire une passe avec Bran ce weekend sur les premières missions.

[phyver]

Bon, je viens de pousser tous mes changements, mais y'a eu plein de conflits pour je ne sais quelle raison. J'ai l'impression que c'était uniquement en local, mais je ne sais pas trop ce qui s'est passé...

Essaie de récupérer la branche devel et d'y pousser ta prochaine modif sur devel pour voir si tu as les droits nécessaires.

Si c'est bon, je pourrais fermer cette PR. (Le mieux pour continuer à discuter serait peut-être sur l'issue correspondante : https://github.com/phyver/GameShell/issues/11)

En fait, je n'avais jamais vraiment utilisé les PR avant, alors je sais pas ce qui est le mieux.

[rlepigre]

Bon, je viens de pousser tous mes changements, mais y'a eu plein de conflits pour je ne sais quelle raison. J'ai l'impression que c'était uniquement en local, mais je ne sais pas trop ce qui s'est passé...

Essaie de récupérer la branche devel et d'y pousser ta prochaine modif sur devel pour voir si tu as les droits nécessaires.

Normalement c'est bon, quand j'ai essayé je pouvais pousser, mais je ne l'ai pas fait comme il y avait des conflits.

Si c'est bon, je pourrais fermer cette PR. (Le mieux pour continuer à discuter serait peut-être sur l'issue correspondante : #11)

En fait, je n'avais jamais vraiment utilisé les PR avant, alors je sais pas ce qui est le mieux.

En général le mieux c'est de bosser dans des PR, peu importe qu'elle vienne d'un fork externe (elle est de toute façon référencée sur la page du projet dans la liste des PRs). Si tu préfères qu'on bosse sur ta branche devel pas de problème, tu peux fermer ma PR et en ouvrir une nouvelle à partir de ta branche devel. L'alternative c'est de supprimer ta branche devel et de continuer à bosser dans ma PR. Pour moi c'est égal, donc je te laisse décider !

[phyver]

Bon, je commence un peu mieux à comprendre comment les PR fonctionnent. Par contre, je crois que je viens de faire un truc pas bien en supprimant le dernier commit (qui ne contenait rien) et en poussant avec -ff. Ça fait quoi si tu "pull" la PR ?

Si c'est OK, on continue ici et j'oublie ma branche devel pour le moment...

[rlepigre]

Haha... Tout est OK a priori. On pourra toujours faire un rebase -i et nettoyer un peu l'historique des commits de la PR avant de la merger.

[phyver]

J'ai supprimé ma branche devel pour éviter ce genre de problèmes !

[phyver]

Je crois que j'ai fini le plus gros de ce que je voulais faire. J'ai même ajouté 3 nouvelles missions (36, 37 et 38). Dis moi ce que tu en penses !

Je pensais re-sourcer le fichier static.sh juste avant le fichier chaque chargement du init.sh correspondant. On n'en a jamais eu besoin, mais ça peut éviter des problèmes si le joureur supprime le dossier Chateau par inadvertance ! Tu y vois des inconvénients ?

Sinon, je vais probablement changer le nom de quelques variables GASH:

• GASH_CONFIG => GASH_BASHRC_D (c'est là que sont stockés les fichiers de config pour bash)
• GASH_DATA => GASH_META (c'est là que sont stockés les métadonnées de la partie : liste des missions, logs des actions gash, historique des commandes et passeport)
• GASH_MISSION_DATA => GASH_VAR (c'est là que sont stockés les fichiers temporaires, init.sh y met typiquement des données qui seront utilisées par check.sh)

Maintenant, il va falloir que je me motive pour repasser à mes corrections de TP !

[phyver]

Ça fait plaisir de pouvoir faire

$ ./start -FRD
...
[mission 1] $ for _ in $(seq 38); do gash auto; done
.
.
.
CONGRATULATIONS!

en anglais et en français.

Ce week-end, j'essaierais de tester sur une debian minimal pour lister la liste des paquets nécessaires, et vérifier que les autres dépendances deps.sh capturent tout ce qu'il faut.

Je pourrais probablement tester avec un bsd également.

Par contre, il faudrait trouver un macos. J'essaierais peut-être ça https://github.com/sickcodes/Docker-OSX, sauf si tu as une meilleure idée.

[phyver]

Et il faut prévoir une sacrée relecture (francais / anglais) juste pour les fautes d'orthographe !

[rlepigre]

Je crois que j'ai fini le plus gros de ce que je voulais faire. J'ai même ajouté 3 nouvelles missions (36, 37 et 38). Dis moi ce que tu en penses !

Cool ! Je ne les ai pas encore essayées, mais vu les instructions elles ont l'air vraiment pas mal !

Je pensais re-sourcer le fichier static.sh juste avant le fichier chaque chargement du init.sh correspondant. On n'en a jamais eu besoin, mais ça peut éviter des problèmes si le joureur supprime le dossier Chateau par inadvertance ! Tu y vois des inconvénients ?

Je ne vois pas de problème avec ça. Par contre, ça ne permet pas de protéger contre la suppression du coffre ou de la cabane par exemple. Peut-être qu'on devrait sauvegarder le monde dans une archive au début de chaque mission, et vérifier qu'il ne manque rien à la fin? Une autre idée que j'avais eu il y a quelques jours serait d'utiliser git et de faire un commit à la fin de chaque mission (en sauvegardant les fichiers concernés et en vérifiant qu'il n'y a pas de modifications ailleurs). Mais bon, ça semble un peu trop compliqué (?), et pas sans problème : il me semble que par exemple git ignore le dossiers vides. Ce serait peut-être plus raisonnable d'utiliser des archives.

Sinon, je vais probablement changer le nom de quelques variables GASH:

• GASH_CONFIG => GASH_BASHRC_D (c'est là que sont stockés les fichiers de config pour bash)
• GASH_DATA => GASH_META (c'est là que sont stockés les métadonnées de la partie : liste des missions, logs des actions gash, historique des commandes et passeport)
• GASH_MISSION_DATA => GASH_VAR (c'est là que sont stockés les fichiers temporaires, init.sh y met typiquement des données qui seront utilisées par check.sh)

OK, très bien.

Maintenant, il va falloir que je me motive pour repasser à mes corrections de TP !

C'est tout de suite moins rigolo, tu devrais faire plus de TPs quasi-automatiques comme celui de gash !

Ça fait plaisir de pouvoir faire

$ ./start -FRD
...
[mission 1] $ for _ in $(seq 38); do gash auto; done
.
.
.
CONGRATULATIONS!

en anglais et en français.

Youhou !

Ce week-end, j'essaierais de tester sur une debian minimal pour lister la liste des paquets nécessaires, et vérifier que les autres dépendances deps.sh capturent tout ce qu'il faut.

Je pourrais probablement tester avec un bsd également.

Par contre, il faudrait trouver un macos. J'essaierais peut-être ça https://github.com/sickcodes/Docker-OSX, sauf si tu as une meilleure idée.

Je pense que c'est une bonne idée, ou en tout cas un truc similaire. C'est en fait assez facile d'ajouter un script d'intégration continue dans un dépôt sur GitHub, donc on pourrait faire ça pour tester sous différents systèmes. Je pourrai essayer de m'en occuper si tu veux.

Et il faut prévoir une sacrée relecture (francais / anglais) juste pour les fautes d'orthographe !

Oui, en effet. J'avais commencé à faire une passe ce soir just avant que tu pousses 70aa899, donc j'ai laissé tomber pour le moment pour éviter les conflits. J'ai quand même poussé une amélioration des fichiers goal de la mission 1. J'ai remarqué que pour certaines missions vers la fin la description des commandes utilise le nom de fichier/dossier/entier capitalisé dans la ligne de la commande. Je pense que c'est très bien donc j'ai fait ça pour la mission 1, et je crois qu'on devrait faire de même partout si tu es d'accord.

Au passage, petite question : j'ai utilisé des caractères UTF-8 pour avoir des guillemets « ... » en français, et “...” en anglais. Est-ce que c'est une bonne idée, ou est-ce que tu préfères éviter ça ?

Aussi, qu'est-ce que tu penses des notes que j'ai ajouté (donnant la signification de cd et pwd) ? Je pense que c'est pas mal de donner ce genre de chose parce que ça permet de se rappeler des commandes plus facilement.

D'ailleurs, je pense encore à un autre truc : ce serait peut-être pas mal d'avoir une petite introduction au début du jeu qui clarifie certains trucs. En particulier, expliquer qu'on utilise des analogies comme "lieu" pour "répertoire". Je trouve que le texte sur la page web de ton cours est pas mal:

Il est important de garder à l'esprit que les "missions" sont simplement des tâches que l'on rencontre couramment lors de l'utilisation d'un ordinateur :

• créer des répertoires
• créer des fichiers
• chercher des fichiers selon des critères simples ou complexes
• lancer ou arrêter d'autre programmes
• ...

Dans GameShell, les "objets" que vous rencontrerez sont simplement des fichiers standard (souvent avec un contenu aléatoire) et les "lieux" que vous visiterez sont simplement des répertoires. Ainsi, "construire une cabane" revient simplement à créer un répertoire, et "mettre les pièces dans le coffre" revient simplement à déplacer les fichiers "pièce" dans le répertoire "coffre".

[phyver]

Par contre, ça ne permet pas de protéger contre la suppression du coffre ou de la cabane par exemple. [... tar ... git ...] Dans ce cas, j'ai envie de dire, "bien fait pour lui" !

Je mets l'idée dans un coin, mais je ne ferais pas ça maintenant. (En tout cas, je préfère l'idée d'une archive...)

Je pense que c'est une bonne idée, ou en tout cas un truc similaire. C'est en fait assez facile d'ajouter un script d'intégration continue dans un dépôt sur GitHub, donc on pourrait faire ça pour tester sous différents systèmes. Je pourrai essayer de m'en occuper si tu veux.

Si tu t'y connais la dedans, je veux bien que tu regardes. Je n'ai jamais fait ça, et je ne suis pas du tout un pro de docker !

J'ai remarqué que pour certaines missions vers la fin la description des commandes utilise le nom de fichier/dossier/entier capitalisé dans la ligne de la commande. Je pense que c'est très bien donc j'ai fait ça pour la mission 1, et je crois qu'on devrait faire de même partout si tu es d'accord.

Oui, je le faisais au début. C'est parfois problématiques, comme dans

cat FICHIER1 FICHIER2 ... FICHIERn
Affiche les FICHIERs (???) donnés en argument

chmod [OPTION] FICHIER Change les droits d'accès pour le FICHIER ou le répertoire (???).

> Au passage, petite question : j'ai utilisé des caractères UTF-8 pour avoir des guillemets `« ... »` en français, et `“...”` en anglais. Est-ce que c'est une bonne idée, ou est-ce que tu préfères éviter ça ?
>
Dans le terminal, je préfère en général favoriser l'ASCII quand c'est possible.
En plus, avec les guillemets français, il ne faut pas oublier les espaces, qu'il faudrait mettre insécables.
(Et c'est sans parler du fait qu'ils sont parfois très moches.)

> Aussi, qu'est-ce que tu penses des notes que j'ai ajouté (donnant la signification de `cd` et `pwd`) ? Je pense que c'est pas mal de donner ce genre de chose parce que ça permet de se rappeler des commandes plus facilement.
>
Bonne idée, même si on ne sais parfois pas trop quoi dire.

ls Remarque : ls comme "list".

> D'ailleurs, je pense encore à un autre truc : ce serait peut-être pas mal d'avoir une petite introduction au début du jeu qui clarifie certains trucs. En particulier, expliquer qu'on utilise des analogies comme "lieu" pour "répertoire". Je trouve que le texte sur la page web de ton cours est pas mal:
> 
Oui, c'est une bonne idée. Émilie m'a fait la même remarque.
Je rajoute dans le TODO, que je mettrais sur le wiki du dépot.

Si tu veux faire des corrections ce week-end, commence plutôt par les missions de la fin, et je commencerais par les missions du début. (On avait fait l'inverse la dernière fois.)
Lundi, j'imprimerais tous les ``goal/fr.txt`` pour faire une relecture déconnecté.
Ça peut être bien de revoir aussi tous les messages `gettext` pour uniformiser. (C'est plus le bazar quand il faut changer l'anglais.)

Un dernier truc, je préfère un style "direct"

pwd Affiche le lieu courant.

plutot qu'indirecte

pwd Permet d'afficher le lieu courant.

[rlepigre]

[... tar ... git ...] Dans ce cas, j'ai envie de dire, "bien fait pour lui" !

Je mets l'idée dans un coin, mais je ne ferais pas ça maintenant. (En tout cas, je préfère l'idée d'une archive...)

OK, très bien. Mais du coup on pourrait prendre la même approche pour la suppression du château et compagnie, non ?

Je pense que c'est une bonne idée, ou en tout cas un truc similaire. C'est en fait assez facile d'ajouter un script d'intégration continue dans un dépôt sur GitHub, donc on pourrait faire ça pour tester sous différents systèmes. Je pourrai essayer de m'en occuper si tu veux.

Si tu t'y connais la dedans, je veux bien que tu regardes. Je n'ai jamais fait ça, et je ne suis pas du tout un pro de docker !

Je suis loin d'être un expert, mais je l'ai déjà fait. Je vais essayer. Par contre je ne sais pas trop si on peut faire ça de telle manière à ce qu'on puisse tester les missions avec xeyes.

J'ai remarqué que pour certaines missions vers la fin la description des commandes utilise le nom de fichier/dossier/entier capitalisé dans la ligne de la commande. Je pense que c'est très bien donc j'ai fait ça pour la mission 1, et je crois qu'on devrait faire de même partout si tu es d'accord.

Oui, je le faisais au début. C'est parfois problématiques, comme dans

cat FICHIER1 FICHIER2 ... FICHIERn
  Affiche les FICHIERs (???) donnés en argument

chmod [OPTION] FICHIER
  Change les droits d'accès pour le FICHIER ou le répertoire (???).

En effet... Pour le second on peut peut-être utiliser le mot OBJET au lieu de FICHIER. Pour le premier c'est moins clair.

Au passage, petite question : j'ai utilisé des caractères UTF-8 pour avoir des guillemets « ... » en français, et “...” en anglais. Est-ce que c'est une bonne idée, ou est-ce que tu préfères éviter ça ?

Dans le terminal, je préfère en général favoriser l'ASCII quand c'est possible. En plus, avec les guillemets français, il ne faut pas oublier les espaces, qu'il faudrait mettre insécables. (Et c'est sans parler du fait qu'ils sont parfois très moches.)

OK, on laisse tomber alors, et on utilise "..." partout?

Aussi, qu'est-ce que tu penses des notes que j'ai ajouté (donnant la signification de cd et pwd) ? Je pense que c'est pas mal de donner ce genre de chose parce que ça permet de se rappeler des commandes plus facilement.

Bonne idée, même si on ne sais parfois pas trop quoi dire.

ls
  Remarque : ls comme "list".

Oui, mais je me disais que c'est plus clair pour celui-là. Mais bon on peut toujours dire que ls est une abréviation de "liste", oui.

D'ailleurs, je pense encore à un autre truc : ce serait peut-être pas mal d'avoir une petite introduction au début du jeu qui clarifie certains trucs. En particulier, expliquer qu'on utilise des analogies comme "lieu" pour "répertoire". Je trouve que le texte sur la page web de ton cours est pas mal:

Oui, c'est une bonne idée. Émilie m'a fait la même remarque. Je rajoute dans le TODO, que je mettrais sur le wiki du dépot.

OK très bien.

Si tu veux faire des corrections ce week-end, commence plutôt par les missions de la fin, et je commencerais par les missions du début. (On avait fait l'inverse la dernière fois.)

OK, très bien. Je pense que c'est une bonne idée de faire un commit par mission, et de pousser tout de suite comme ça on évitera les problèmes. Et on pourra toujours squasher des commits plus tard.

Lundi, j'imprimerais tous les goal/fr.txt pour faire une relecture déconnecté. Ça peut être bien de revoir aussi tous les messages gettext pour uniformiser. (C'est plus le bazar quand il faut changer l'anglais.)

Oui, je crois qu'il faut relire l'anglais en priorité. Je vais faire jouer Bran dans un petit moment, et je vais prendre des notes sur les trucs à changer. Idéalement ce serait bien que tu ne changes pas trop de trucs dans la version anglaise en même temps.

Un dernier truc, je préfère un style "direct"

pwd
  Affiche le lieu courant.

plutot qu'indirecte

pwd
  Permet d'afficher le lieu courant.

OK, je suis assez d'accord avec ça, mais pour cd par exemple ça donne quelque chose de pas très clair. Ou alors il faut dire un truc comme "Déplace le joueur vers le LIEU donné." Qu'en penses-tu ?

[rlepigre]

On a fait une grosse passe avec Bran sur les fichiers "goal". Bran joue une partie, et moi je modifie en passant. On fait une pause (elle en est à la mission 20), et on finit en fin d'après-midi. J'ai aussi plein de notes avec des remarques, mais on a déjà amélioré plein de choses. En particulier certaines missions n'étaies pas super claires, et d'autres un peu déconnectées du l'univers du jeu. On a donc trouvé des trucs rigolos pour les relier à l'histoire.

Par exemple pour la mission 14 on a écrit:

It is taking too long to check for hidden spiders! Create an 
alias "la" to run the command ``ls -A`` in order to list all
files, including hidden ones, more easily.

Il faudra peut-être créer une araignée cachée dans le init.sh pour que ce soit plus facile de vérifier que la fonctionne.

[rlepigre]

Notes taken while Bran was playing

GameShell

The name gash is unfortunate: means an open wound, can mean a vagina apparently...

Suggestions:

• gsh
• gameshell
• ...

"to discover the goal of ..." → "to discover your first mission" "check that the goal has been achieved" → "check that the mission has been successfully completed"

Capitalise "mission" in the prompt?

Add something about capitalised "metavariables" in command lists at the beginning of the game.

Not clear that the .. introduced in mission 2 can be used in any file path.

Mission 1

Dungeon sounds more like an underground prison: replace by Main_Tower?

"Lets you move ..." → "Allows you to move to the given location." "Lets you restart ..." → "Allows you to restart..."

After gash check: "to discover your next goal" → "to discover your next mission".

Mission 4

"Cabin" → "Log_cabin"?

Mission 5

Create two salamanders to fit the mission description better.

Mission 8

Avoid using hidden files here: rm *spider does not work, there is no explanation that hidden files are not taken into account by patterns.

The explanation for wildcards is not super clear:

• confusion file/folder,
• try something like: "" stands in for all the files, "1" stands in for all the files whose name ends with "1", ...

Mission 9

There are only the only the standards in the Entrance, so * can be used in cp: add other objects?

Mission 10

Alternative objects:

• suit_of_armour
• decorative_sword
• stag_head
• tapestries

Mission 12

This is disconnected form the story: ask for the day the king was born in? Or maybe find a date on a tombstone somewhere?

Mission 13

Also feels disconnected from the story. This is fixed.

TODO add a hidden spider on the first floor, or wherever the player is?

Mission 18

Botanical_garden → Botanical_gardens

Using just Garden or Flower_garden would be better according to Bran.

Change "Pffft": not a great choice. In English use "Phew" (relief)? Also change "back to" into "back at"

Mission 19

The tree command uses colours by default on Bran's PC.

Mission 23

The mission is too hard, we should introduce the pipe with something simpler. I liked the head and tail version to get the middle of the recipe. But this mission is nice once you know a bit more how pipes work.

Mission 24

Invert cats and rats?

Introduce somewhere that patterns must start with "." for hidden files.

Mission 25

Seems the mission can get in a subshell: no subprocesses. Maybe due to the check of mission 24?

Missions 26 to the end

Will go back to it later, Bran is a bit tired. I think there is quite a bit gap in difficulty.

[phyver]

The name gash is unfortunate: means an open wound, can mean a vagina apparently... Suggestions:

• gsh
• gameshell
• ...

Argh. I liked gash, as it is reminiscent of bash...

• gameshell is too long.
• gsh it is, unless one of us comes up with a better alternative.

The tree command uses colours by default on Bran's PC.

I guess it comes from the LS_COLORS environment variable... Is it fixed with my last commit?

I'll implement most of the rest, and will probably come back with questions.

Will go back to it later, Bran is a bit tired.

Thanks Bran!

[phyver]

Je viens de faire quelques changements.

Sinon

Add something about capitalised "metavariables" in command lists at the beginning of the game.

Tu mettrais ça où ?

"Lets you move ..." → "Allows you to move to the given location." "Lets you restart ..." → "Allows you to restart..."

Et plutôt que

pwd
See the path to your current location.

vous pensez quoi de

pwd
Show the path to your current location.

"Cabin" → "Log_cabin"?

Sauf raison linguistique importante, je garde Cabin, pour éviter les problèmes de Log[-_][Cc]abin...

Ou alors, on fait construire une Chambre qui contient un Coffre...

Mission 8 Avoid using hidden files here: rm *spider does not work, there is no explanation that hidden files are not taken into account by patterns.

Pour le moment, j'ai ajouté une remarque sur les jokers et les fichiers cachés. Cette mission arrive juste après la 7, qui introduit les fichiers cachés.

Par contre, c'est effectivement la première qui utilisent les motifs. On pourrait la bouger après la mission 10. Tu en penses quoi ?

The explanation for wildcards is not super clear:

Je vais essayer de revoir ça.

Mission 9 There are only the only the standards in the Entrance, so * can be used in cp: add other objects?

Bonne idée. TODO

Mission 12 This is disconnected form the story: ask for the day the king was born in?

Ça vous convient mieux ? J'aime bien l'idée de la pierre tombale. Je réfléchis...

Mission 13 Also feels disconnected from the story. This is fixed. TODO add a hidden spider on the first floor, or wherever the player is?

DONE

Mission 23 The mission is too hard, we should introduce the pipe with something simpler. I liked the head and tail version to get the middle of the recipe. But this mission is nice once you know a bit more how pipes work.

La mission avec head et tail était vraiment très artificielle. (C'est nettement plus pratique d'utiliser sed ou awk pour ça.) Je vais plutôt découper cette mission en 2 :

• formatter les 7 dernières étapes de la recette
• formatter les 7 dernières étapes numérotées Tu en penses quoi ?

Invert cats and rats?

J'aime bien les rats, avec les références à Ratatouille

Mission 25 Seems the mission can get in a subshell: no subprocesses. Maybe due to the check of mission 24?

Tu te souviens comment vous avez fait ça ?

[rlepigre]

Argh. I liked gash, as it is reminiscent of bash...

Oui, moi aussi... Mais bon, Bran a éclaté de rire en voyant ça au début.

• gameshell is too long.
• gsh it is, unless one of us comes up with a better alternative.

Ouais, je suis d'accord que c'est mieux. Mais bon attendons peut-être un peu pour voir si on trouve une meilleur idée. D'ailleurs, j'ai remarqué que "GameShell" dans Google a beaucoup d'entrées, a priori il y a une console de jeu qui a ce nom. Mais bon, c'est peut-être pas super grave.

The tree command uses colours by default on Bran's PC.

I guess it comes from the LS_COLORS environment variable... Is it fixed with my last commit?

Oui, je viens d'essayer c'est bon.

Add something about capitalised "metavariables" in command lists at the beginning of the game.

Tu mettrais ça où ?

Peut-être dans le message d'accueil ? C'est peut-être pas hyper important, mais c'est une convention qui ne va pas de soi. (C'est un truc que j'ai du expliquer à Bran et elle comprenait vraiment pas au début.)

Et plutôt que

pwd
  See the path to your current location.

vous pensez quoi de

pwd
  Show the path to your current location.

Bran préfère la première option: on a essayé de formuler les descriptions de commandes de façon à se placer du point de vue de l'utilisateur. Et a priori c'est ce qui est le plus naturel.

"Cabin" → "Log_cabin"?

Sauf raison linguistique importante, je garde Cabin, pour éviter les problèmes de Log[-_][Cc]abin...

Peut-être Wooden_cabin alors? D'après Bran Cabin tout seul n'est pas très naturel. Mais ça passe si on veut le garder. (C'est dans la forêt, donc on comprend quand même a priori.)

Ou alors, on fait construire une Chambre qui contient un Coffre...

Je pense qu'on peut garder la Cabin, ou la changer en Wooden_cabin (mais je vérifie avec Bran demain).

Mission 8 Avoid using hidden files here: rm *spider does not work, there is no explanation that hidden files are not taken into account by patterns.

Pour le moment, j'ai ajouté une remarque sur les jokers et les fichiers cachés. Cette mission arrive juste après la 7, qui introduit les fichiers cachés.

Par contre, c'est effectivement la première qui utilisent les motifs. On pourrait la bouger après la mission 10. Tu en penses quoi ?

Oui, c'est une bonne idée. Ça permet de ne pas introduire trop de choses à la fois.

Mission 9 There are only the only the standards in the Entrance, so * can be used in cp: add other objects?

Bonne idée. TODO

Ouais, Bran a fait un cp * ... et ça m'a semblé être de la triche.

Mission 12 This is disconnected form the story: ask for the day the king was born in?

Ça vous convient mieux ? J'aime bien l'idée de la pierre tombale. Je réfléchis...

Oui, c'est déjà mieux je pense. Mais c'est vrai qu'un truc avec un peu plus d'étapes (qui demandent à utiliser d'autres commandes vues avant) serait encore mieux. On pourrait avoir une crypte avec les tombeaux d'anciens rois (avec des dates de naissance / mort choisies statiquement), puis demander à l'utilisateur lequel des roi est né un mardi et mort un jeudi (par exemple).

Mission 23 The mission is too hard, we should introduce the pipe with something simpler. I liked the head and tail version to get the middle of the recipe. But this mission is nice once you know a bit more how pipes work.

La mission avec head et tail était vraiment très artificielle. (C'est nettement plus pratique d'utiliser sed ou awk pour ça.)

Je suis assez d'accord, mais ça avais l'avantage d'être simple (avec des commandes facile à comprendre).

Je vais plutôt découper cette mission en 2 :

• formatter les 7 dernières étapes de la recette
• formatter les 7 dernières étapes numérotées Tu en penses quoi ?

Pourquoi pas, mais je ne suis pas certain de comprendre ce que tu proposes exactement. Dans la version actuelle il faut trois commandes différentes, donc deux sont nouvelles (nl et fold), et aussi le pipe. Il faudrait introduire chacune des commandes d'abord je pense, ou en tout cas n'utiliser pas plus qu'un pipe à la fois au début.

Pour nl on pourrait faire une mission ou le vieux gars te demande de numéroter les étapes de la recette (pour introduire la redirection de stdout) avec une solution:

nl recette.txt > tmp
mv tmp recette.txt

en expliquant qu'on peut pas faire nl recette.txt > recette.txt.

Invert cats and rats?

J'aime bien les rats, avec les références à Ratatouille

Oui, je suis d'accord, finalement c'est pas mal !

Mission 25 Seems the mission can get in a subshell: no subprocesses. Maybe due to the check of mission 24?

Tu te souviens comment vous avez fait ça ?

Pas vraiment, mais je crois bien que c'est arrivé juste avec après le gash check de la mission 24. La commande ps ne donnait plus que le process de bash, alors que xeyes tournait toujours. On a fait un exit mais on est juste sorti du jeu, done je sais pas trop ce qui c'est passé. Et puis on n'a rien fait de bizarre pendant la partie il me semble. J'essayerai de reproduire plus tard en faisant une partie complète.

[phyver]

Et plutôt que

pwd
  See the path to your current location.

vous pensez quoi de

pwd
  Show the path to your current location.

Bran préfère la première option: on a essayé de formuler les descriptions de commandes de façon à se placer du point de vue de l'utilisateur. Et a priori c'est ce qui est le plus naturel.

Oui, mais c'est moins "standard". Les descriptions des commandes (dans man ou --help) sont plutôt du point de vue de la commande.

Peut-être Wooden_cabin alors? D'après Bran Cabin tout seul n'est pas très naturel. Mais ça passe si on veut le garder. (C'est dans la forêt, donc on comprend quand même a priori.)

Oui, mais c'est juste que les gens ne vont pas savoir s'il faut metter un tiret, un "souligné", une majuscule au deuxième nom, etc. Sinon, "tent", tipi "tipi", "hut", "shelter", ...

Je vais plutôt découper cette mission en 2 :

• formatter les 7 dernières étapes de la recette
• formatter les 7 dernières étapes numérotées Tu en penses quoi ?

Pourquoi pas, mais je ne suis pas certain de comprendre ce que tu proposes exactement.

En gros, une première mission où il faut faire

$ nl recette.txt | tail -n 7
$ gash check

et la suivante où il faut faire

$ nl recette.txt | tail -n 7 | fold
$ gash check

Et on pourrait peut-être supprimer la mission 22, qui fait un peu doublon avec la 21:

• 21 : introduction de head
• 22 : introduction de tail, nl et le pipe

• 23 : introduction fold, deux pipe

  Ça te parait trop dur ?

[rlepigre]

Et plutôt que

pwd
  See the path to your current location.

vous pensez quoi de

pwd
  Show the path to your current location.

Bran préfère la première option: on a essayé de formuler les descriptions de commandes de façon à se placer du point de vue de l'utilisateur. Et a priori c'est ce qui est le plus naturel.

Oui, mais c'est moins "standard". Les descriptions des commandes (dans man ou --help) sont plutôt du point de vue de la commande.

C'est vrai, mais est-ce que c'est vraiment important ? On ne donne pas vraiment des extraits de manuel.

Si on décide de tout formuler du point de vue de la commande, alors Bran dit qu'il faut un s:

pwd
   Shows the path to your current location.

Dit nous ce que tu préfères et on fera une passe.

Oui, mais c'est juste que les gens ne vont pas savoir s'il faut metter un tiret, un "souligné", une majuscule au deuxième nom, etc. Sinon, "tent", tipi "tipi", "hut", "shelter", ...

Oui, tu as raison, j'avais pas pensé à ça. Donc laissons Cabin, Bran dit que ça va, et que c'est just que c'est pas très spécifique. Mais bon comme c'est dans la forêt on comprend quand même très bien l'idée.

En gros, une première mission où il faut faire

$ nl recette.txt | tail -n 7
$ gash check

et la suivante où il faut faire

$ nl recette.txt | tail -n 7 | fold
$ gash check

Et on pourrait peut-être supprimer la mission 22, qui fait un peu doublon avec la 21:

Non, je pense que je laisserai la mission 22, c'est vrai que c'est similaire mais c'est très bien ! Si tu as compris tout de suit (comme Bran hier), alors tu la valide en deux secondes. Ça illustre aussi le fait que certaines commandes ont des options similaires.

• 21 : introduction de head
• 22 : introduction de tail, nl et le pipe
• 23 : introduction fold, deux pipe

Ça te parait trop dur ?

Peut-être un peu, on pourrait essayer d'être un tout petit peu plus progréssif:

• 21 : introduction de head,
• 22 : introduction de tail (comme avant),
• 23 : introduction de nl et du pipe avec un truc comme cat recette1 recette2 | nl,
• 24 : utilisation d'un autre pipe et de fold, du genre tail -n 7 potiion | fold,
• 25 : un truc plus compliqué avec deux pipes,
• 26 : un truc encore plus compliqué avec trois pipes (?).

Ce qu'on pourrait peut-être faire pour que ce soit un peu plus rigolo serait d'avoir un "grimoire": un dossier contenant en gros un fichier index (avec des noms de potions et pages correspondantes), et des fichier page_i pour pour chaque page. On pourrait donc demander d'afficher les n premières lignes de telle ou telle potion, et avoir des potions sur plusieurs pages pour justifier un cat grimoire/page5 grimoire/page6 | nl par exemple. On pourrait même avoir une mission pour compter les lignes dans le grimoire, où il faudrait faire cat grimoire/* | wc -l.

Si ce genre de chose te semble bien je peux m'occuper d'en faire une première version.

Au fait, je sais pas bien ce que tu as fais pour le fichier index.txt dans les missions. Est-ce qu'on peut virer les numéros au début des noms des dossiers de missions maintenant ? Et est-ce qu'on peut utiliser des sous-dossiers sous missions ?

[phyver]

Pas vraiment, mais je crois bien que c'est arrivé juste avec après le gash check de la mission 24. La commande ps ne donnait plus que le process de bash, alors que xeyes tournait toujours.

C'est bizarre !

On a fait un exit mais on est juste sorti du jeu, done je sais pas trop ce qui c'est passé.

Normalement, il doit y avoir un message qui demande de lancer gash reset dans ce cas. Vous l'aviez eu ?

Oui, mais c'est moins "standard". Les descriptions des commandes (dans man ou --help) sont plutôt du point de vue de la commande. C'est vrai, mais est-ce que c'est vraiment important ? On ne donne pas vraiment des extraits de manuel.

Non, mais je trouve que c'est plus facile d'être uniforme. Quand on veut décrire grep ou d'autres trucs, je trouve que c'est plus facile

Peut-être un peu, on pourrait essayer d'être un tout petit peu plus progréssif:

* 21 : introduction de `head`,
* 22 : introduction de `tail` (comme avant),
* 23 : introduction de `nl` et du pipe avec un truc comme `cat recette1 recette2 | nl`,

Ça n'a pas l'air d'être conforme POSIX, mais on peut faire nl recette 1 recette2. Peut-être

• 23 : utiliser une option, style nl -s "." recette.txt

  • 24 : utilisation d'un autre pipe et de fold, du genre tail -n 7 potiion | fold,
  • 25 : un truc plus compliqué avec deux pipes,
  • 26 : un truc encore plus compliqué avec trois pipes (?).

Peut-être

• 24 nl + tail + pipe
• 25 nl + tail + fold + 2 pipes
• un truc avec 3 pipes, si on trouve une idée.

Ce qu'on pourrait peut-être faire pour que ce soit un peu plus rigolo serait d'avoir un "grimoire": un dossier contenant en gros un fichier index (avec des noms de potions et pages correspondantes), et des fichier page_i pour pour chaque page. On pourrait donc demander d'afficher les n premières lignes de telle ou telle potion, et avoir des potions sur plusieurs pages pour justifier un cat grimoire/page5 grimoire/page6 | nl par exemple. On pourrait même avoir une mission pour compter les lignes dans le grimoire, où il faudrait faire cat grimoire/* | wc -l.

Si ce genre de chose te semble bien je peux m'occuper d'en faire une première version.

Vas y ! Jje ne suis pas sûr de voir exactement ce que tu as en tête.

Au fait, je sais pas bien ce que tu as fais pour le fichier index.txt dans les missions. Est-ce qu'on peut virer les numéros au début des noms des dossiers de missions maintenant ? Et est-ce qu'on peut utiliser des sous-dossiers sous missions ?

Normalement on peut utilisez des sous-dossiers. Je ne suis pas sûr qu'on puisse supprimer les numéros, car je crois que j'utilise un motif *_* pour les missions. Il faut que je vérifie. Mais j'aime bien laisser quand même des numéros pour les missions qui se suivent : 21, 22, 23, etc.

Je propose qu'on attende d'être repassé sur les missions avant de tester ça.

[rlepigre]

On a fait un exit mais on est juste sorti du jeu, done je sais pas trop ce qui c'est passé.

Normalement, il doit y avoir un message qui demande de lancer gash reset dans ce cas. Vous l'aviez eu ?

OK, c'est ce qu'il me semblait, mais je n'ai pas vu ce message.

Oui, mais c'est moins "standard". Les descriptions des commandes (dans man ou --help) sont plutôt du point de vue de la commande. C'est vrai, mais est-ce que c'est vraiment important ? On ne donne pas vraiment des extraits de manuel.

Non, mais je trouve que c'est plus facile d'être uniforme. Quand on veut décrire grep ou d'autres trucs, je trouve que c'est plus facile

OK. Je ne sais pas ce qui est le mieux. Pour les missions du début on avait l'impression que c'était bien mieux de se mettre du point de vue de l'utilisateur, mais ça marche peut-être moins bien avec des commandes plus compliquées. Il faudrait que je regarde plus d'examples (avec grep, find, ...) pour me faire une meilleure idée.

Ce qu'on pourrait peut-être faire pour que ce soit un peu plus rigolo serait d'avoir un "grimoire": un dossier contenant en gros un fichier index (avec des noms de potions et pages correspondantes), et des fichier page_i pour pour chaque page. On pourrait donc demander d'afficher les n premières lignes de telle ou telle potion, et avoir des potions sur plusieurs pages pour justifier un cat grimoire/page5 grimoire/page6 | nl par exemple. On pourrait même avoir une mission pour compter les lignes dans le grimoire, où il faudrait faire cat grimoire/* | wc -l. Si ce genre de chose te semble bien je peux m'occuper d'en faire une première version.

Vas y ! Jje ne suis pas sûr de voir exactement ce que tu as en tête.

J'ai commencé à faire un truc, il n'y a qu'une seule mission pour l'instant (dans le dossier missions/pipe_basics/01_head, il faut l'ajouter à l'index pour tester), mais il y a un fichier missions/pipe_basics/README.md qui donne certaines idées de missions que j'ai en tête. A priori le livre de potions que j'ai crée (tu peux le voir en essayant la mission) peut être réutilisé pour plein de missions différentes.

Au passage, pour ces missions on aurait vraiment envie de partager certaines choses, par exemple le livre de potions, dans un dossier missions/pipe_basics/common ou similaire. A priori toutes les missions du groupe auront le même init.sh qui va s'occuper de découper le livre en pages (au cas où il ait été supprimé). Mais bon, ça pose le problème des traductions: il faut que le template de traduction de chaque mission soit généré en prenant en compte missions/pipe_basics/common/*.sh.

Au fait, je sais pas bien ce que tu as fais pour le fichier index.txt dans les missions. Est-ce qu'on peut virer les numéros au début des noms des dossiers de missions maintenant ? Et est-ce qu'on peut utiliser des sous-dossiers sous missions ?

Normalement on peut utilisez des sous-dossiers. Je ne suis pas sûr qu'on puisse supprimer les numéros, car je crois que j'utilise un motif *_* pour les missions. Il faut que je vérifie.

OK, comme tu l'as vu j'ai commencé à utiliser des sous-dossiers, et ça semble marcher.

Mais j'aime bien laisser quand même des numéros pour les missions qui se suivent : 21, 22, 23, etc.

OK, je vais numéroter les missions dans mon nouveau dossier alors. Le seul truc qui me gène un peu est que c'est un peu étrange d'avoir ces numéros dans le nom des missions quand on fait gash index. Mais bon on pourrait aussi faire en sorte de virer le numéro dans la fonction correspondante.

Je propose qu'on attende d'être repassé sur les missions avant de tester ça.

OK très bien.

[rlepigre]

J'ai oublié de dire que j'aimerais bien que tu me dise ce que tu pense de ce que j'ai prévu pour les missions dans missions/pipe_basics. Et si tu as d'autres idées, elles sont les bienvenues ! Une fois qu'on a décidé ce qu'on fait pour chaque mission du groupe je m'occuperai d'en faire une première version complète.

[phyver]

Finalement, j'aime bien l'idée d'une "hutte" au lieu d'une "cabane". Tu peux demander à Bran ce qu'elle pense de "hut"?

J'ai commencé à faire un truc, il n'y a qu'une seule mission pour l'instant (dans le dossier missions/pipe_basics/01_head, il faut l'ajouter à l'index pour tester),

Tu peux aussi la donner en argument de start.sh.

J'aime beaucoup. J'ai commenté un peu ton README. Tu peux avancer la dessus si tu veux. Je vais arrêter de bosser sur les missions 21-23 car ça les remplace avantageusement. (Sauf peut-être ta dernière idée qui me parait un peu dure !) J'ai aussi ajouté une autre idée de mission pour utiliser la commande paste.

Au passage, pour ces missions on aurait vraiment envie de partager certaines choses, par exemple le livre de potions, dans un dossier missions/pipe_basics/common ou similaire. A priori toutes les missions du groupe auront le même init.sh qui va s'occuper de découper le livre en pages (au cas où il ait été supprimé). Mais bon, ça pose le problème des traductions: il faut que le template de traduction de chaque mission soit généré en prenant en compte missions/pipe_basics/common/*.sh.

C'est probablement assez simple de partager des données si on duplique le init.sh. La première mission peut par exemple copier le livre dans $GASH_MISSION_DATA, et les suivantes utilisent alors cette copie. On peut alors ajouter une dépendance sur cette première mission dans les suivantes.

Le problème, c'est qu'on est obligé d'inclure la première mission. C'est pareil pour les scripts traduits. Si la première mission on les met dans bin, ils sont ensuite accessibles (traduits) par les autres.

À ce propos, est-ce que ça te parait important de différencier un répertoire bin (ajouté dans le PATH) et un répertoire missions_bin (pas ajouté dans le PATH) ?

Une solution simple à implémenter serait d'autoriser des dossiers missions sans check.sh, qui ne serait alors pas comptabilisés dans la suite des missions... Je réfléchis.

OK, je vais numéroter les missions dans mon nouveau dossier alors. Le seul truc qui me gène un peu est que c'est un peu étrange d'avoir ces numéros dans le nom des missions quand on fait gash index. Mais bon on pourrait aussi faire en sorte de virer le numéro dans la fonction correspondante.

C'est différent quand tu génères une archive : les missions sont recopiées individuellement dans le dossier GASH_MISSIONS (sans sous-dossier donc) et sont renumérotées consécutivement. Je trouve que c'est bien d'avoir les missions dans l'ordre dans le dossier. Au pire il suffit de changer gash index pour qu'il supprime un prefixe lors de l'affichage.

[phyver]

Mon dernier commit ajoute des missions "factices" qui peuvent servir à partager des données. Il suffit de préfixer le dossier par ! dans le fichier index.txt, et dans ce cas, la mission est utilisé par start.sh pour initialiser la partie, et est ignorée dans la suite. Tu peux essayer d'utiliser ça dans tes missions "book of potions"...

Ça devrait suffire. Non ?

(Si tu as une autre idée de syntaxe que !..., dis le moi.)

[rlepigre]

Finalement, j'aime bien l'idée d'une "hutte" au lieu d'une "cabane". Tu peux demander à Bran ce qu'elle pense de "hut"?

Oui c'est pas mal. D'après Bran "Hut" fonctionne, donc on peut faire ça !

Tu peux aussi la donner en argument de start.sh.

Ah OK, je savais pas. C'est pratique !

J'aime beaucoup. J'ai commenté un peu ton README. Tu peux avancer la dessus si tu veux. Je vais arrêter de bosser sur les missions 21-23 car ça les remplace avantageusement. (Sauf peut-être ta dernière idée qui me parait un peu dure !) J'ai aussi ajouté une autre idée de mission pour utiliser la commande paste.

OK, je suis d'accord avec tes commentaires.

C'est probablement assez simple de partager des données si on duplique le init.sh. La première mission peut par exemple copier le livre dans $GASH_MISSION_DATA, et les suivantes utilisent alors cette copie. On peut alors ajouter une dépendance sur cette première mission dans les suivantes.

L'ennui c'est qu'il est compliqué de partager des scripts si ils ont besoin de traductions avec gettext. Ici par exemple je voudrais partager un script init_book.sh qu'on pourrait sourcer dans le init.sh de toutes les missions du groupe, en plus d'autres initialisations spécifiques pour la mission. Mais ce script init_book.sh a besoin de gettext pour la traduction des noms de dossiers et de fichiers.

Le problème, c'est qu'on est obligé d'inclure la première mission. C'est pareil pour les scripts traduits. Si la première mission on les met dans bin, ils sont ensuite accessibles (traduits) par les autres.

Le problème c'est la génération du template de traduction : pour chaque mission on devra aussi scanner les fichiers du dossier partagé. Par contre, la duplication des traductions ne devrait pas être un problème : les missions auront de toute façon besoin des chaines traduites dans les scripts du dossier externe.

En fait, je me demande si le plus simple ne serait pas d'utiliser des liens symboliques. On aurait donc un truc du genre :

missions/pipe_basics
├── shared
│   ├── book_of_potions
│   │   └── en.txt
│   └── init_book.sh
├── 01_head
│   ├── auto.sh
│   ├── check.sh
│   ├── goal
│   │   └── en.txt
│   ├── i18n
│   │   ├── en.po
│   │   └── template.pot
│   ├── init.sh
│   ├── Makefile
│   ├── shared -> ../shared
│   ├── static.sh
│   └── test.sh
├── ...
├── ...
└── ...

A priori git préserve les liens symboliques sans problème. Il suffirait alors (par exemple) de s'assurer qu'on remplace ces liens symboliques par des copies du dossier quand on crée l'archive.

Qu'en penses-tu ?

À ce propos, est-ce que ça te parait important de différencier un répertoire bin (ajouté dans le PATH) et un répertoire missions_bin (pas ajouté dans le PATH) ?

Je n'ai pas vraiment d'opinion là-dessus, si ce n'est que le second me semble assez peu utile.

C'est différent quand tu génères une archive : les missions sont recopiées individuellement dans le dossier GASH_MISSIONS (sans sous-dossier donc) et sont renumérotées consécutivement. Je trouve que c'est bien d'avoir les missions dans l'ordre dans le dossier. Au pire il suffit de changer gash index pour qu'il supprime un prefixe lors de l'affichage.

OK, comme tu veux. On peut effectivement changer ça à l'affichage.

Mon dernier commit ajoute des missions "factices" qui peuvent servir à partager des données. Il suffit de préfixer le dossier par ! dans le fichier index.txt, et dans ce cas, la mission est utilisé par start.sh pour initialiser la partie, et est ignorée dans la suite. Tu peux essayer d'utiliser ça dans tes missions "book of potions"...

Je n'aime pas trop cette option, ça me semble assez peu robuste pour la traduction et la génération des templates. J'ai l'impression que l'option que je propose plus haut est plus simple et robuste. Qu'en penses-tu ?

J'ai avancé un petit peu ce soir, mais surtout sur les fichiers du livre et des fichiers "goal" pour les premières missions. Je vais attendre qu'on ait convergé vers une solution satisfaisante pour partager des fichiers (ou qu'on décide de ne rien faire) pour ajouter les scripts. En faisant ça, je me rend compte que les missions utilisent assez peu le pipe. Il faudrait peut-être qu'on trouve deux ou trois autres missions avec le livre de potions qui ont besoin d'un ou deux pipes. Idéalement il faudrait éviter d'introduire trop d'autres commandes. Finalement je me dis que la mission qu'on avait et qui faisait un head | tail n'était pas si mal. C'est en effet un peu artificiel, mais c'est quand même pas idiot. Et l'avantage est que ça utilise des commandes déjà introduites.

[phyver]

C'est probablement assez simple de partager des données si on duplique le init.sh. La première mission peut par exemple copier le livre dans $GASH_MISSION_DATA, et les suivantes utilisent alors cette copie. On peut alors ajouter une dépendance sur cette première mission dans les suivantes.

L'ennui c'est qu'il est compliqué de partager des scripts si ils ont besoin de traductions avec gettext.

Normalement, c'est géré. (C'est même toi qui l'avait fait.) Pour chaque script dans bin, on écrit un fichier $GASH_LOCAL_BIN/LE_SCRIPT

#!/bin/sh
export TEXTDOMAIN=NOM_DE_LA_MISSION
exec LE_SCRIPT

C'est donc la mission qui introduit le script qui doit gérer la traduction. Les autres ne s'en occupent pas. Elles peuvent simplement lancer $GASH_LOCAL_BIN/LE_SCRIPT.

Pour partager les données (le fichier book_of_potions/en.txt, il faut par contre le copier dans le dossier $GASH_MISSION_DATA/book_of_potion.txt. (Et il faut donc que le script lui même y accède à cet endroit, pas par $MISSION_DIR/....) Une autre solution est que le script partagé génère les pages dans $GASH_MISSION_DATA ; et que chaque init.sh ne fasse que les recopier.

Y'a un truc que j'oublie ?

En fait, je me demande si le plus simple ne serait pas d'utiliser des liens symboliques. [...] A priori git préserve les liens symboliques sans problème. Il suffirait alors (par exemple) de s'assurer qu'on remplace ces liens symboliques par des copies du dossier quand on crée l'archive.

J'avais pensé à un truc comme ça, mais ça implique de revoir la génération de l'archive. (Pour le moment, elle recopie tous les dossiers missions "à plat" en les re-numérotant. Il faut aussi faire attention à ne pas dupliquer le dossier partagé : faire une simple copie dans le dossier de la mission n'est pas très satisfaisant. Rien d'impossible, mais j'ai l'impression que ma solution est plus simple. (Elle nécessite juste de jongler un peu avec le dossier $GASH_MISSION_DATA.)

À ce propos, est-ce que ça te parait important de différencier un répertoire bin (ajouté dans le PATH) et un répertoire missions_bin (pas ajouté dans le PATH) ?

Je n'ai pas vraiment d'opinion là-dessus, si ce n'est que le second me semble assez peu utile.

On n'utilise pour le moment pas de scripts / exécutables qui soient dans le PATH. Les scripts qu'on utilise pour générer les missions sont soit dans le dossier de la mission, soit dans $GASH_LOCAL_BIN pour être partagés. Je me dis que c'est bien qu'un script partagé maze_generator.sh ne soit pas dans le PATH, histoire qu'un joueur ne le lance pas par inadvertance. Le dossier $GASH_LOCAL_BIN n'apparait d'ailleurs plus dans le PATH depuis un moment.

Mon dernier commit ajoute des missions "factices" qui peuvent servir à partager des données. Je n'aime pas trop cette option, ça me semble assez peu robuste pour la traduction et la génération des templates.

Dis moi si les propositions évoquées plus haut te paraissent suffisantes.

Il faudrait peut-être qu'on trouve deux ou trois autres missions avec le livre de potions qui ont besoin d'un ou deux pipes. Idéalement il faudrait éviter d'introduire trop d'autres commandes.

Sans nouvelles commandes, on va vite être limités.

On peut introduire sed 's/avant/apres/' pour demander de corriger une erreur et remplacer les griffes dragon par des écailles de dragon.

Ou bien tr pour demander de déchiffrer une recette secrète. (En remplacement de la mission 35).

Ou bien grep et wc pour compter le nombre de potions qui utilisent un ingrédient : on commence chaque potion par une ligne

ingredients: ..., ..., ..., ...

et il faut faire grep ingredient page* | grep "sauge" | wc -l, en faisant attention parce que sans le premier grep, on compte aussi les étapes qui utilisent de la sauge.

Finalement je me dis que la mission qu'on avait et qui faisait un head | tail n'était pas si mal. C'est en effet un peu artificiel, mais c'est quand même pas idiot. Et l'avantage est que ça utilise des commandes déjà introduites.

On peut la garder. Je modifierais peut-être le check.sh pour qu'il accepte d'autres solutions (avec sed ou awk par exemple).

[phyver]

Pour les méta-variables, je propose : méta variables en majuscules dans les commandes, mais on ne les réutilise pas dans la description en langue naturelle :

mkdir REPERTOIRE
  Crée un répertoire.

mv FICHIER1 FICHIER2 ... FICHIERn REPERTOIRE
  Déplace les fichiers dans le répertoire.

Il y a quelques exceptions, comme

tail -n K FICHIER
  Affiche les K dernières lignes du fichier.

mais si on choisit bien les noms des variables, ça marche plutôt bien.

Pour l'explication, je pense que le mieux est de la mettre dans les 2 ou trois premiers fichiers goal.

Je fais un passage sur les fichiers en français pour faire des corrections, mais je ne touche pas aux fichiers anglais pour le moment.

[rlepigre]

L'ennui c'est qu'il est compliqué de partager des scripts si ils ont besoin de traductions avec gettext.

Normalement, c'est géré. (C'est même toi qui l'avait fait.) Pour chaque script dans bin, on écrit un fichier $GASH_LOCAL_BIN/LE_SCRIPT

Ah OK, je viens de comprendre ce que tu avais en tête. Moi je pensais sourcer le fichier, mais en fait si on execute le fichier il n'y a pas de problème. Donc oui, ça doit en fait très bien marcher avec ton approche !

Pour partager les données (le fichier book_of_potions/en.txt, il faut par contre le copier dans le dossier $GASH_MISSION_DATA/book_of_potion.txt. (Et il faut donc que le script lui même y accède à cet endroit, pas par $MISSION_DIR/....) Une autre solution est que le script partagé génère les pages dans $GASH_MISSION_DATA ; et que chaque init.sh ne fasse que les recopier.

Y'a un truc que j'oublie ?

OK, je vais essayer de faire ça ce soir.

En fait, je me demande si le plus simple ne serait pas d'utiliser des liens symboliques. [...] A priori git préserve les liens symboliques sans problème. Il suffirait alors (par exemple) de s'assurer qu'on remplace ces liens symboliques par des copies du dossier quand on crée l'archive.

J'avais pensé à un truc comme ça, mais ça implique de revoir la génération de l'archive. (Pour le moment, elle recopie tous les dossiers missions "à plat" en les re-numérotant. Il faut aussi faire attention à ne pas dupliquer le dossier partagé : faire une simple copie dans le dossier de la mission n'est pas très satisfaisant. Rien d'impossible, mais j'ai l'impression que ma solution est plus simple. (Elle nécessite juste de jongler un peu avec le dossier $GASH_MISSION_DATA.)

Oui, OK, tu as raison.

À ce propos, est-ce que ça te parait important de différencier un répertoire bin (ajouté dans le PATH) et un répertoire missions_bin (pas ajouté dans le PATH) ?

Je n'ai pas vraiment d'opinion là-dessus, si ce n'est que le second me semble assez peu utile.

On n'utilise pour le moment pas de scripts / exécutables qui soient dans le PATH. Les scripts qu'on utilise pour générer les missions sont soit dans le dossier de la mission, soit dans $GASH_LOCAL_BIN pour être partagés. Je me dis que c'est bien qu'un script partagé maze_generator.sh ne soit pas dans le PATH, histoire qu'un joueur ne le lance pas par inadvertance. Le dossier $GASH_LOCAL_BIN n'apparait d'ailleurs plus dans le PATH depuis un moment.

Oui, en effet. Et ce sera pareil pour le script générant le livre de potions.

Il faudrait peut-être qu'on trouve deux ou trois autres missions avec le livre de potions qui ont besoin d'un ou deux pipes. Idéalement il faudrait éviter d'introduire trop d'autres commandes.

Sans nouvelles commandes, on va vite être limités.

C'est vrai. Du coup ce groupe de mission est moins centré sur le pipe, mais ce n'est pas un problème.

On peut introduire sed 's/avant/apres/' pour demander de corriger une erreur et remplacer les griffes dragon par des écailles de dragon.

Pourquoi pas !

Ou bien tr pour demander de déchiffrer une recette secrète. (En remplacement de la mission 35).

C'est un bonne idée, mais la mission 35 fonctionne plutôt pas mal donc on devrait peut-être garder tr pour celle-là.

Ou bien grep et wc pour compter le nombre de potions qui utilisent un ingrédient : on commence chaque potion par une ligne

ingredients: ..., ..., ..., ...

OK, je vais réfléchir à ça. J'espérais que la version actuelle du livre (modulo améliorations des étapes) serait suffisante. J'ai peur qu'il devienne chiant à traduire si on met trop de contenu !

et il faut faire grep ingredient page* | grep "sauge" | wc -l, en faisant attention parce que sans le premier grep, on compte aussi les étapes qui utilisent de la sauge.

Finalement je me dis que la mission qu'on avait et qui faisait un head | tail n'était pas si mal. C'est en effet un peu artificiel, mais c'est quand même pas idiot. Et l'avantage est que ça utilise des commandes déjà introduites.

On peut la garder. Je modifierais peut-être le check.sh pour qu'il accepte d'autres solutions (avec sed ou awk par exemple).

Oui, pourquoi pas !

[rlepigre]

Pour les méta-variables, je propose : méta variables en majuscules dans les commandes, mais on ne les réutilise pas dans la description en langue naturelle :

OK, très bien.

Pour l'explication, je pense que le mieux est de la mettre dans les 2 ou trois premiers fichiers goal.

Oui, c'est une bonne idée. Peut-être qu'on devrait avoir une section optionnelle "Explanations" avant "Useful commands", et mettre là-dedans des remarques générales sur le fonctionnement du jeu, la syntaxe des commandes, ...

Je fais un passage sur les fichiers en français pour faire des corrections, mais je ne touche pas aux fichiers anglais pour le moment.

OK. Si tu veux faire les fichiers anglais tu peux, je ne touche à rien avant ce soir.

[rlepigre]

Bon, j'ai réussi à obtenir quelque chose qui me convient avec une mission "factice"!

Par contre il faut donne aux scripts du dossier bin l'accès au dossier de la mission d'où ils proviennent. Je pense que ce que j'ai fait va casser la création d'archive, il faudrait que tu jettes un œil. Le problème est qu'il faudrait donner le chemin vers le dossier de la mission après qu'il ait été renuméroté.

[phyver]

Bon, je vais essayer de me forcer à ne bosser sur GameShell qu'en soirée, parce que sinon mes corrections ne vont jamais se terminer !

Je ne vais pas trop intervenir sur les missions.

J'ai encore quelques trucs à faire sur le code, mais le gros truc, c'est de revoir toute la doc !

Concernant le nom, j'ai un peu réfléchis, avec des résultats pas très probants comme "Gamified Bash" (gab) ou similaire. Sauf si tu as une bonne idée, je pense rester sur "GameShell" (gsh). On sera en bonne companie (csh, ksh, tcsh, zsh). C'est aussi le petit nom du Glutathion (un antioxidant), mais je ne pense pas que ça soit problèmatique ! (Il faudrait l'intégrer dans une mission !)

On peut essayer de se donner 15 jours pour arriver à une version correcte, histoire de faire un peu de pub d'ici la fin du mois. (linuxfr, reddit, etc.) Ça te parait raisonnable ?

[rlepigre]

Bon, je vais essayer de me forcer à ne bosser sur GameShell qu'en soirée, parce que sinon mes corrections ne vont jamais se terminer !

Haha... Moi je me force à pas regarder dans la journée, sinon je ne ferais que ça!

Je ne vais pas trop intervenir sur les missions.

J'ai encore quelques trucs à faire sur le code, mais le gros truc, c'est de revoir toute la doc !

Oui, et il y a du boulot !

Concernant le nom, j'ai un peu réfléchis, avec des résultats pas très probants comme "Gamified Bash" (gab) ou similaire. Sauf si tu as une bonne idée, je pense rester sur "GameShell" (gsh). On sera en bonne companie (csh, ksh, tcsh, zsh). C'est aussi le petit nom du Glutathion (un antioxidant), mais je ne pense pas que ça soit problèmatique ! (Il faudrait l'intégrer dans une mission !)

Je vais réfléchir un peu plus avec Bran, mais pour l'instant j'ai pas trouvé d'autre idée.

On peut essayer de se donner 15 jours pour arriver à une version correcte, histoire de faire un peu de pub d'ici la fin du mois. (linuxfr, reddit, etc.) Ça te parait raisonnable ?

OK, ça me semble raisonnable. Par contre il faudra peut-être qu'on fasse tester le jeu autours de nous avant de faire de la pub. Par exemple, je pourrai l'envoyer à quelques un des mes collègues du MPI à qui j'avais parlé du jeu il y a quelque temps. Donc on peut peut-être faire une pré-release dans 15 jours et la diffuser pas trop largement, et puis se laisser 15 jours de plus pour que des gens puissent tester et qu'on puisse réparer le problèmes.

J'ai pas eu énormément de temps ces derniers jours, mais je devrais en avoir un peu plus la semaine prochaine. J'espère pouvoir terminer le groupe de mission et refaire une passe sur toutes les versions anglaises des missions avec Bran. En particulier, il faut qu'on regarde d'un peu plus près le entrées dans les fichiers de traduction comme on s'en sert de clé (et que c'est chiant à changer).

Il y a toujours un truc avec lequel je suis vraiment pas satisfait : la génération du template de mission, et l'ajout manuel de clés pour les fichiers "goal" et "treasure-msg". (Au passage, il faut que le Makefile prenne en compte les sources dans bin/, ce qui n'est pas le cas pour l'instant.) Après, c'est possible que je n'ai pas totalement compris comment tu te sert du Makefile, donc si tu écris un peu de doc ça peut m'aider. (Un truc qui n'est pas clair pour moi c'est à quel point la mise à jour des fichiers est "automatique" dés qu'on fait un changement dans les clés.)

Au fait, regarde, Bran travaille sur une illustration:

[phyver]

OK, ça me semble raisonnable. Par contre il faudra peut-être qu'on fasse tester le jeu autours de nous avant de faire de la pub. Par exemple, je pourrai l'envoyer à quelques un des mes collègues du MPI à qui j'avais parlé du jeu il y a quelque temps. Donc on peut peut-être faire une pré-release dans 15 jours et la diffuser pas trop largement, et puis se laisser 15 jours de plus pour que des gens puissent tester et qu'on puisse réparer le problèmes.

Bonne idée.

J'ai pas eu énormément de temps ces derniers jours, mais je devrais en avoir un peu plus la semaine prochaine. J'espère pouvoir terminer le groupe de mission et refaire une passe sur toutes les versions anglaises des missions avec Bran. En particulier, il faut qu'on regarde d'un peu plus près le entrées dans les fichiers de traduction comme on s'en sert de clé (et que c'est chiant à changer).

C'est sûr ! Je viens de repasser un peu sur ces fichiers, et c'est pas hyper marrant.

Il y a toujours un truc avec lequel je suis vraiment pas satisfait : la génération du template de mission, et l'ajout manuel de clés pour les fichiers "goal" et "treasure-msg".

Je trouve que ça marche plutôt bien... Au pire, on peut ajouter un goal.sh, ou un _goal.sh (supprimé dans les archives exécutables). C'est ce que fait le script new-mission.sh.

En parlant de goal.sh, je vais supprimer la fonctionnalité qui fait passer le fichier goal/en.txt dans envsubstsi la première ligne contient des variables. Si on veut faire ça, il faudra passer par un fichier goal.sh, qui peut garantir que les variables existent vraiment (cf mission 12).

(Au passage, il faut que le Makefile prenne en compte les sources dans bin/, ce qui n'est pas le cas pour l'instant.)

Par défaut, xgettext regarde juste les fichiers *.sh à la racine de la mission, mais il y a une variable OTHER dans les Makefile, dans laquelle tu peux mettre les autres fichiers. (Regarde dans la mission 33.) Si on ajoute bin/*, ça provoque une erreur lorsque le répertoire bin n'existe pas.

Après, c'est possible que je n'ai pas totalement compris comment tu te sert du Makefile, donc si tu écris un peu de doc ça peut m'aider. (Un truc qui n'est pas clair pour moi c'est à quel point la mise à jour des fichiers est "automatique" dés qu'on fait un changement dans les clés.)

Quand je fais un changement, je lance make, qui met à jours les fichiers template.pot (rien à faire pour celui là) et ajoute les clés dans les fichiers *.po. C'est pas génial, parce que les valeurs sont vides. Quand tu modifies des clés, ça introduit en général des paires clés / valeurs "fuzzy". La nouvelle clé qui ressemble à l'ancienne est taggée "fuzzy" et la valeurs est la même que l'ancienne.

À un moment, je générais un fichier intermédiaire pour que les nouvelles valeurs soient égales à la clé. C'est bien, parce que ça veut dire qu'on n'a rien à faire pour en.po. Je ne sais plus pourquoi je l'avais enlevé... (Par contre, quand tu génère un nouveau fichier .po, je le génère avec les valeurs égales aux clés.)

make add-locations ajoute en plus les positions des clés dans les fichiers. C'est pratique pour repérer des clés qui ont disparues : elles n'ont pas de position. Par contre, je refais toujours un make pour enlever ces positions. Sinon, le moindre changement d'un script t'oblige à regénérer les fichiers.

Un truc très bizarre et pas pratique, c'est que faire un make add-locations suivi dunmaken'est pas idempotent : ça inverse les méta-données degettext(encoding, etc.) et les clés qui n'aparaissent pas dans un fichier (notamment la clé pour legoal`.

Bref, ça serait bien de nettoyer un peu tout ça.

On peut aussi trier par clés, ce qui est plutôt bien, mais rend les nouvelles clés plus difficiles à trouver quand tu en ajoutes. (Actuellement, elles se retrouvent à la fin.)

Bref, ça serait bien de nettoyer un peu tout ça.

• dans quel ordre on met les clés (ordre des fichiers, ordres des clés, ordre "chronologique") ? => ordre des clés
• est-ce qu'on veut les valeurs vides ou en anglais par défaut ? => en anglais
• est-ce qu'on veut aligner les clés / valeurs (option --indent) ? => oui ?
• est-ce qu'on veut garder les fichiers en.po dans le dépot ? (on peut toujours les générer avec msgen) => je sais pas trop
• est-ce qu'on veut garder les emplacements dans les fichiers ? => plutôt non, à condition qu'on puisse facilement les ajouter / supprimer

Dis moi si tu as un avis sur ces questions.

Au fait, regarde, Bran travaille sur une illustration:

Génial ! Par contre, je n'oserais pas utiliser libcaca pour l'afficher dans une mission !

[rlepigre]

OK, merci pour les explication !

Bref, ça serait bien de nettoyer un peu tout ça.

Oui, ce serait pas mal en effet.

• dans quel ordre on met les clés (ordre des fichiers, ordres des clés, ordre "chronologique") ? => ordre des clés

Ça veut dire quoi "order des clés" ? C'est pas la même chose que ce que tu appelles ll'ordre des fichiers ?

• est-ce qu'on veut les valeurs vides ou en anglais par défaut ? => en anglais

Oui, c'est pratique et ça permet d'éviter des erreurs stupides (du genre quand on a qu'un "en" qui devient "fr" on ne risque pas de se louper sur le nom d'un dossier).

• est-ce qu'on veut aligner les clés / valeurs (option --indent) ? => oui ?

Je suis pas certain de l'effet de cette option, mais aligner des trucs c'est souvent plus lisible.

• est-ce qu'on veut garder les fichiers en.po dans le dépot ? (on peut toujours les générer avec msgen) => je sais pas trop

Je pense qu'on devrait le garder, il ne coûte pas cher.

• est-ce qu'on veut garder les emplacements dans les fichiers ? => plutôt non, à condition qu'on puisse facilement les ajouter / supprimer

Tu parles des commentaires qui sont insérés automatiquement ? Je ne les trouvent pas très utiles, mais s'ils sont générés c'est pas idiot de les avoir.

[phyver]

• dans quel ordre on met les clés (ordre des fichiers, ordres des clés, ordre "chronologique") ? => ordre des clés

Ça veut dire quoi "order des clés" ? C'est pas la même chose que ce que tu appelles ll'ordre des fichiers ?

Non, c'est par ordre lexicographique des clés. C'est par exemple pratique sur le fichier de GameShell, parce que tous les message Error: ... se retrouvent ensemble. C'est moins important sur les missions, mais ça permet par exemple d'avoir tous les chemins $GASH_HOME/... au même endroit.

Le seul problème, c'est que quand on ajoute des messages, ils se retrouvent au milieu du fichier. Si on ne précise pas d'ordre, ils sont à la fin...

• est-ce qu'on veut les valeurs vides ou en anglais par défaut ? => en anglais

Oui, c'est pratique et ça permet d'éviter des erreurs stupides (du genre quand on a qu'un "en" qui devient "fr" on ne risque pas de se louper sur le nom d'un dossier).

Je vais remettre cette fonctionnalité.

• est-ce qu'on veut aligner les clés / valeurs (option --indent) ? => oui ?

Je suis pas certain de l'effet de cette option, mais aligner des trucs c'est souvent plus lisible.

Je vais ajouter ça.

• est-ce qu'on veut garder les fichiers en.po dans le dépot ? (on peut toujours les générer avec msgen) => je sais pas trop

Je pense qu'on devrait le garder, il ne coûte pas cher.

Oui. Ce que je ferais peut-être, une fois qu'on a fini de corriger les .po, c'est de tous les régénérer pour être sûr qu'ils sont bien cohérents avec les template.pot...

• est-ce qu'on veut garder les emplacements dans les fichiers ? => plutôt non, à condition qu'on puisse facilement les ajouter / supprimer

Tu parles des commentaires qui sont insérés automatiquement ? Je ne les trouvent pas très utiles, mais s'ils sont générés c'est pas idiot de les avoir.

Je trouve que c'est bien de pouvoir les ajouter (make add-locations), mais de ne pas les garder dans le dépot. Si tu ajoutes un commentaire dans init.sh, ça fait un commit sur init.sh, template.pot, en.po et fr.po. (Ou alors, tu te retrouves avec des positions qui ne sont pas synchronisées.

[phyver]

• est-ce qu'on veut les valeurs vides ou en anglais par défaut ? => en anglais

Oui, c'est pratique et ça permet d'éviter des erreurs stupides (du genre quand on a qu'un "en" qui devient "fr" on ne risque pas de se louper sur le nom d'un dossier).

Je vais remettre cette fonctionnalité.

Finalement, non. Je vais laisser des chaines vide, et utiliser https://www.vim.org/scripts/script.php?script_id=2530 J'ai juste modifié quelques touches, mais c'est assez génial.