Compatibilité CMD et CMDebug / TCC-RT, partie 1

L'objectif de notre nouveau débogueur batch autonome CMDebug consiste à exécuter les fichiers batch CMD.EXE avec une compatibilité aussi proche que possible de 100 %. J'ai demandé aux utilisateurs de m'envoyer tous les fichiers batch CMD qu'ils avaient trouvés et qui ne fonctionnaient pas correctement dans TCC.

Un utilisateur a envoyé un fichier de commandes Microsoft qui n'a pas pu s'exécuter dans TCC (et a exposé quelques bogues (manques ?) jusque-là inconnus pour moi dans CMD.EXE).

Le premier concernait la manière dont ils appelaient la commande interne SET. Pour des raisons inconnues, le développeur a choisi de toujours citer les arguments SET, c'est-à-dire :

définir "var1=insérez votre valeur ici"

Maintenant, même si cela ne servait à rien, TCC (Et CMDebug) n’a eu aucun problème pour analyser la commande.

Y a-t-il des cas où vous mettriez tout entre guillemets ? Oui, par exemple :

définir "var1=insertion>drôle|personnages&ici"

Si vous souhaitez utiliser quelque chose comme un séparateur de commande ou des caractères de redirection, vous devez les citer (ou les échapper) pour empêcher le processeur de commandes de les interpréter comme un caractère spécial. Mais dans le cas de ce fichier batch, il n'y avait jamais de caractères spéciaux dans la valeur nécessitant des guillemets doubles.

Donc, si TCC gère les guillemets doubles, quel était le problème ? Le développeur avait également quelques déclarations qui ressemblaient à ceci :

définir "var1 = une valeur" et plus de texte là-bas

TCC supposé que « andmoretexthere » devait être ajouté à la valeur de var1. Mais ce que fait réellement CMD.EXE, c'est ignorer tout ce qui se trouve après le guillemet fermant, transformant la ligne en :

var1=une valeur

C'était inattendu pour moi (et non documenté). Et s'il devait être jeté, pourquoi l'auteur du fichier batch l'a-t-il inclus ? Il ne s’agit même pas pour CMD de rechercher des devis correspondants – par exemple :

définissez "var1=une" valeur "ici" et "plus" ici

résulte en:

var1=une"valeur"ici"et"plus

Ainsi, CMD recherche un guillemet double avant le nom de la variable, et s'il en trouve un, il recherche le *dernier* guillemet double sur la ligne et jette tout ce qui le suit. Pourquoi? Qui sait? Pourquoi le développeur de ce fichier batch a-t-il ajouté ce texte supplémentaire après la dernière citation ? Une faute de frappe? Une intelligence interne excessive ?? Je n'ai aucune idée.

J'ai ajouté une blague pour cela TCC, mais à moins de citer l’intégralité de l’instruction SET, vous ne la rencontrerez jamais.

Dans le prochain article, je parlerai de l'autre problème de ce fichier batch : une utilisation curieuse de la syntaxe de substitution de variable CMD et le bug CMD que l'auteur du fichier batch a contourné de manière surprenante (du moins pour TCC!) chemin.