Cela me fâche d’avoir utilisé Unix au collège et de travailler maintenant sous Windows. Quelle est l'histoire derrière cette décision? Quelqu'un sait pourquoi cela a fonctionné de cette façon?
Unix a introduit /
comme séparateur de répertoires vers 1970. Je ne sais pas pourquoi ce caractère a été choisi; le système ancêtre Multics utilisait >
, mais les concepteurs de Unix avaient déjà utilisé >
avec <
pour la redirection dans le shell (voir Pourquoi le répertoire racine est-il désigné par le signe /
? ).
MS-DOS 2.0 a introduit \
comme séparateur de répertoire au début des années 1980. La raison pour laquelle /
n'a pas été utilisée est que MS-DOS 1.0 (qui ne prend pas du tout en charge les répertoires) utilisait déjà /
pour introduire des options de ligne de commande. Il a pris cette utilisation de /
à partir de CP/M , puis à partir de VMS . Vous pouvez lire une explication plus détaillée de la raison pour laquelle ce choix a été fait sur le blog de Larry Osterman (MS-DOS avait même brièvement la possibilité de changer le caractère d'option en -
et le séparateur de répertoire à /
, mais cela ne colle pas).
/
il est reconnu par la plupart des API de niveau programmeur (dans toutes les versions de DOS et Windows). Vous pouvez donc souvent, mais pas toujours, utiliser /
comme séparateur de répertoire sous Windows. Une exception notable est que vous ne pouvez pas utiliser /
comme séparateur après le préfixe \\?
qui (même sous Windows 7) est le seul moyen de spécifier un chemin utilisant Unicode ou contenant plus de 260 caractères.
Certains éléments de l'interface utilisateur prennent en charge /
en tant que séparateur de répertoire sous Windows, mais pas tous. Certains programmes ne font que transmettre les noms de fichiers à l'API sous-jacente, de sorte qu'ils prennent en charge /
et \
indifféremment. Dans l'interpréteur de commandes (dans command.com
ou cmd
), vous pouvez utiliser /
dans de nombreux cas, mais pas toujours; cela dépend en partie de la version de Windows (par exemple, cd /windows
fonctionne dans XP et 7 mais pas dans Windows 9x). La zone de saisie du chemin de l'explorateur accepte /
(au moins de XP up; probablement parce qu'il accepte également les URL). D'autre part, la boîte de dialogue d'ouverture de fichier standard rejette les barres obliques .
L'API Windows sous-jacente peut accepter la barre oblique inverse ou la barre oblique afin de séparer les composants de répertoire et de fichier d'un chemin, mais Microsoft a pour convention d'utiliser une barre oblique inversée. Les API qui renvoient les chemins mettent une barre oblique inversée.
MS-DOS 2.0 a copié le système de fichiers hiérarchique sous Unix et a donc utilisé la barre oblique, mais (éventuellement sur l'insistance de IBM ) a ajouté une barre oblique inverse pour permettre la saisie de chemins dans la commande Shell tout en préservant la compatibilité avec MS-DOS 1.0 et CP/M où la barre oblique était l'indicateur d'option de ligne de commande.
Comparer
dir/w
qui montre le répertoire courant en format large contre
dir\w
qui exécute le fichier w
dans le directeur dir
.
Références: