Handle scriptum.lua line endings and loading correctly on macOS

[Copilot]

consul.scriptum.setup created scriptum.lua in text mode, leaving newline conversion to Lua/runtime behavior. This change makes line endings explicit so Windows keeps CRLF output while macOS writes LF output, and also fixes macOS loading/execution issues caused by mixed line endings and direct dofile usage.

• What changed

  • Detect the current OS from package.config.
  • Normalize the embedded example script to \n, then rewrite it with the platform-specific line ending.
  • Write scriptum.lua in binary mode to avoid implicit newline conversion during file creation.
  • Normalize line endings when reading consul.scriptum, so LF, CRLF, and CR entries are all accepted.
  • Execute clicked scriptum entries by opening them through consul.io_open(..., "rb"), normalizing line endings, and loading them with loadstring instead of calling dofile directly.

• Behavior

  • Windows (\) → generated scriptum.lua uses \r\n
  • macOS (/) → generated scriptum.lua uses \n
  • consul.scriptum is parsed correctly on macOS regardless of whether it uses LF, CRLF, or CR
  • scriptum.lua is opened through the macOS-aware consul.io_open path before execution

• Updated write path

  -- Detect OS via path separator
  local is_windows = package.config:sub(1, 1) == '\\'
  local line_ending = is_windows and "\r\n" or "\n"
  
  -- Normalize line endings then apply the correct one for the current OS
  local script_content = consul.scriptum.example_script:gsub("\r\n", "\n"):gsub("\n", line_ending)
  
  -- Write in binary mode to prevent automatic line ending conversion
  f = io.open(consul.scriptum.path_example, "wb")
  if f then
      f:write(script_content)
      f:close()
  end

• Scope

  • Limited to src/consul/consul.lua, covering:
    • example scriptum.lua creation
    • consul.scriptum line parsing
    • scriptum.lua file loading/execution on click

Original prompt

Contexte

Dans le fichier src/consul/consul.lua, la fonction consul.scriptum.setup crée le fichier scriptum.lua lors du premier démarrage s'il n'existe pas encore.

Actuellement, le fichier est écrit en mode texte ("w") avec des \n, ce qui laisse Lua gérer automatiquement les fins de ligne. On souhaite un contrôle explicite selon l'OS :

• Windows → terminateurs \r\n (CRLF) — comportement actuel à conserver
• macOS → terminateurs \n (LF) — conforme iOS/macOS

Modification à apporter

Dans src/consul/consul.lua, dans la fonction consul.scriptum.setup, remplacer le bloc d'écriture de consul.scriptum.path_example :

f = io.open(consul.scriptum.path_example, "w")
if f then
    f:write(consul.scriptum.example_script)
    f:close()
end

Par :

-- Detect OS via path separator
local is_windows = package.config:sub(1, 1) == '\\'
local line_ending = is_windows and "\r\n" or "\n"

-- Normalize line endings then apply the correct one for the current OS
local script_content = consul.scriptum.example_script:gsub("\r\n", "\n"):gsub("\n", line_ending)

-- Write in binary mode to prevent automatic line ending conversion
f = io.open(consul.scriptum.path_example, "wb")
if f then
    f:write(script_content)
    f:close()
end

Résumé du comportement attendu

OS	package.config:sub(1,1)	line_ending	Résultat fichier
Windows	\	\r\n	CRLF ✅
macOS	/	\n	LF ✅

Aucune autre modification ne doit être apportée au fichier.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Au premier démarrage du pack, un fichier scriptum.lua est créé si il n'existe pas.
J'ai besoin que si le pack s'execute depuis windows il soit créer comme actuellement, mais que si le pack s'execute sur macos, le terminateur de ligne soit conforme a ios

Assistant: Laissez-moi d'abord explorer le dépôt pour comprendre la structure actuelle.

Assistant: Le fichier de logging n'est pas celui que je cherche. Laissez-moi chercher directement le code de création de scriptum.lua.

Assistant: Je n'ai pas encore trouvé le code exact qui crée scriptum.lua. Laissez-moi chercher directement dans les fichiers liés à scriptum.

User: C'est dans le fichier @consul.lua, cherche exemple_script

Assistant: J'ai trouvé le code. La création de scriptum.lua se fait dans la fonction setup de consul.scriptum, vers la ligne ~2856 de consul.lua.

Voici la section concernée :

f = io.open(consul.scriptum.path_example, "w")
if f then
    f:write(consul.scriptum.example_script)
    f:close()
end

Et example_script est une string multiligne [[ ... ]] avec des \n.

---

Le problème

En mode texte ("w"), Lua fait automatiquement la conversion :

• Windows → \n devient \r\n ✅
• macOS → \n reste \n ✅ (c'est déjà le comportement conforme)

Cependant, si vous voulez contrôle explicite selon la plateforme (pour garantir le comportement quelle que soit la configuration), la bonne approche est d'ouvrir en mode binaire ("wb") et d'injecter manuellement le bon terminateur de ligne.

---

Solution proposée

Ajoutez une détection de l'OS via package.config (le séparateur de chemin est \ sur Windows, / sur macOS/Linux), puis adaptez les terminateurs :

-- Détection de l'OS
local is_windows = package.config:sub(1, 1) == '\\'
local line_ending = is_windows and "\r\n" or "\n"

-- Adapter l'example_script avec le bon terminateur de ligne
local script_content = consul.scriptum.example_script:gsub("\r\n", "\n"):gsub("\n", line_ending)

-- Écriture en mode binaire pour éviter toute conversion automatique
f = io.open(consul.scriptum.path_example, "wb")
if f then
    f:write(script_content)
    f:close()
end

---

Ce que ça fait

OS	package.config:sub(1,1)	line_ending	Fichier produit
Windows	\	\r\n	CRLF (actuel ✅)
macOS	/	\n	LF (conforme iOS ✅)

Le :gsub("\r\n", "\n"):gsub("\n", line_ending) normalise d'abord toutes les fins de ligne en \n, puis applique le bon terminateur — ce qui évite les doublons \r\r\n si la string source contenait déjà des \r\n.

Voulez-vous que je crée une PR avec cette modification directement dans consul.lua ?

User: Fait une pr qui pointe vers ma branche macos-support

Assistant: L'agent n'a pas retourné de résultat. Je vais effectuer la modification directement.

Assistant: Je ne peux pas directement créer la pull request car la configuration de votre dépôt ne permet pas l'accès à l'agent de modification. Vous pouvez cependant effectuer ces étapes manuellement ou ajuster la configuration et me...

This pull request was created from Copilot chat.

[smardine]

@copilot , il y a encore une erreur :

macos_scriptum.lua.txt
windows_scriptum.lua.txt
consul.scriptum.txt

Voila deux fichiers scriptum.lua, j'ai du les renommer en .txt pour pouvoir les uploader.
le fichier consul.scriptum a du etre egaelement renommer en .txt pour pouvoir etre uploader
Celui qui s'apelle windows_scriptum.lua.txt est au bon format et fonctionne sous windows, il s'affiche bien dans la console de consul scriptum
Celui qui s'apelle macos_scriptum.lua.txt ne fonctionne pas, meme en passant au format binaire.

Lorsque je lance le jeu sous mac, voici les scenario :

avec LF comme terminateur dans ce fichier et consul.scriptum.txt: je vois sciptum dans la console mais quand je clique dessus, j'ai l'erreur :
[2026-05-21 09:19:56] [ERROR] scriptum:OnComponentLClickUp: Error executing script: scriptum.lua attempt to call a string value
avec CRLF (encoding windows ) dans les deux fichiers, je ne vois plus scriptum dans la console
avec CR (encoding mac) dans les deux fichiers, je ne vois plus scriptum dans la console.

Je me demande si le probleme n'est pas l'ouverture du fichier scriptum.lua sur mac (comme j'ai deja fait la modif dans console, verifie que c'est bien consul.io_open qui est utilisé pour ouvrir ce fichier lors du clic sur le nom du script

[Copilot]

@copilot , il y a encore une erreur :

macos_scriptum.lua.txt
...

Corrigé dans 3e36c30. Le clic sur une entrée scriptum ne passe plus par dofile direct : le fichier est maintenant ouvert via consul.io_open(..., "rb"), normalisé (CRLF/CR/LF), puis exécuté avec loadstring. J’ai aussi remplacé la lecture de consul.scriptum par une lecture complète + normalisation des fins de ligne, donc les listes en LF, CRLF ou CR sont désormais acceptées sur macOS.