Il est dit que sous Unix et Linux en général, vous devez éviter d'avoir des espaces dans le nom de fichier d'un fichier (fichier ordinaire, dir, lien, fichier de périphérique, ...).
Mais je fais ça tout le temps. Pour un nom de fichier avec un espace à l'intérieur,
- Dans Nautilus, le caractère espace est affiché comme un espace.
- Dans le terminal Bash, j'utilise soit
\
pour représenter un espace, soit pour enfermer le nom de fichier dans une paire de guillemets doubles. - dans les fichiers de certaines applications (Nautilus, je ne sais pas si le système d'exploitation le fera également), le nom de fichier est écrit avec l'espace remplacé par
%20
.
Un espace n'est-il vraiment pas autorisé dans un nom de fichier?
Comment utilisez-vous ou gérez-vous correctement un espace dans un nom de fichier?
-rf ~
(usetouch -- "-rf ~"
), mais je ne le recommanderais pas./
séparateur). L'utilisation des 254 octets restants ouvre la porte à toutes les manières de "noms" indescriptibles de eldritch. Évidemment, c'est fou, mais tout le monde n'est pas d'accord sur ce qu'est "sain d'esprit", et différents personnages briseront différents outils. L'intersection de la santé mentale de chacun est assez petite .Réponses:
Les espaces, et en fait tous les caractères sauf
/
et NUL, sont autorisés dans les noms de fichiers. La recommandation de ne pas utiliser d'espaces dans les noms de fichiers vient du risque qu'ils soient mal interprétés par un logiciel qui les prend mal en charge. On peut dire que ce logiciel est bogué. Mais sans doute, les langages de programmation tels que les scripts shell facilitent trop l'écriture de logiciels qui se cassent lorsqu'ils sont présentés avec des noms de fichiers avec des espaces, et ces bogues ont tendance à passer car les scripts shell ne sont pas souvent testés par leurs développeurs en utilisant des noms de fichiers avec des espaces dans leur.Les espaces remplacés par
%20
n'apparaissent pas souvent dans les noms de fichiers. Cela est principalement utilisé pour les URL (Web). Bien qu'il soit vrai que le codage% à partir d'URL fait parfois son chemin dans les noms de fichiers, souvent par accident.la source
bash
. J'ai essayé quelques choses telles que le citer avec Ctrl-V et quelque chose comme$(echo -e \\0)
ça, mais cela n'a pas fonctionné. Le fait est que la raison pour laquelle NUL ne peut pas être utilisé dans les noms de fichiers est qu'il ne peut pas être utilisé dans les chaînes C (car c'est le terminateur de chaîne) et toutes les API sous-jacentes ainsi que pratiquement toutes les chaînes gérées par les programmes C utilisent ce format . Puisqu'ilbash
est écrit en C, il peut simplement ne prendre en charge aucune chaîne contenant NUL. Je peux me tromper, il pourrait y avoir un moyen obscur ...NUL
et bash, vous avez besoin$'\0'
. Par exemple:find . -print0 | while read -d $'\0' f; do echo "$f"; done
Les espaces sont autorisés dans les noms de fichiers, comme vous l'avez observé.
Si vous regardez l'entrée "la plupart des systèmes de fichiers UNIX" dans ce graphique dans wikipedia , vous remarquerez:
Tout jeu de caractères 8 bits est autorisé. Nous pouvons également subsumer ASCII 7 bits sous ce parapluie, car il s'agit d'un sous-ensemble de divers ensembles 8 bits et est toujours implémenté à l'aide d'octets 8 bits.
Les seuls caractères interdits sont
/
et "null". "Null" fait référence à un octet zéro, mais ceux-ci ne sont de toute façon pas autorisés dans les données de texte.Cependant , si vous utilisez le shell, vous pouvez vous rendre compte qu'il existe certains caractères qui créeront un problème, le plus important
*
, qui est un opérateur de remplacement POSIX.Selon la façon dont vous voulez définir les "tracas", vous pouvez y inclure des espaces (espaces, tabulations, nouvelles lignes, etc.), car cela crée le besoin de citer avec
""
. Mais cela est inévitable, car les espaces sont autorisés, alors ...Dans un contexte shell / ligne de commande, encapsulez le nom de fichier entre guillemets simples ou doubles (mais notez qu'il ne s'agit pas des mêmes problèmes WRT), ou échappez aux espaces avec
\
, par exemple:la source
touch $(echo -e "foo\00bar")
- les-e
processus en\0N
tant que valeur octale, mais ils se perdent quelque part, car cela crée simplement un fichier nomméfoobar
. Bien sûr, NULL n'est pas imprimable, mais je vous garantis qu'il a disparu à cause de la restriction de la chaîne C.foo[NULL]bar
finirait commefoo
pour la plupart des intentions et des fins. Le fait que cela ne se produise pasecho -e
montre que le NULL a été élagué quelque part./
qui est le séparateur de répertoire et ne peut pas être cité, donc peut être dans un chemin d'accès mais pas dans un nom de fichier).La raison est en grande partie historique - WAY retour dans la brume des espaces temporels n'était pas autorisé dans les noms de fichiers, donc les espaces ont été utilisés comme séparateurs de mots clés / noms de fichiers. Les futurs interpréteurs de shell devaient être rétrocompatibles avec les anciens scripts, et nous sommes donc coincés avec le mal de tête que nous avons aujourd'hui.
Les développeurs de processus qui n'ont pas besoin de beaucoup traiter avec les humains peuvent rendre les choses beaucoup plus faciles en supprimant complètement les espaces. Apple le fait, le contenu de / System / Library / CoreServices / contient très peu d'espaces, les programmes avec espaces sont ouverts au nom de l'utilisateur et WouldLookStrangeIfCamelCased. Des chemins similaires Unix uniquement évitent également les espaces.
(anecdote quelque peu apparentée: au milieu des années 90, un drone Windows a dit "Nommez une chose que vous pouvez faire sur un Mac que je ne peux pas faire sous Windows" -> "Utilisez 12 caractères dans un nom de fichier." -> Silence. Les espaces étaient également possible dans ces 12 caractères)
la source
Donc oui, comme cela est dit à plusieurs reprises ailleurs, un nom de fichier peut contenir presque n'importe quel caractère. Mais il faut dire qu'un nom de fichier n'est pas un fichier. Il a un certain poids en tant qu'attribut de fichier dans la mesure où vous avez généralement besoin d'un nom de fichier pour ouvrir un fichier, mais le nom d' un fichier ne pointe que vers le fichier réel. Il s'agit d'un lien, stocké dans le répertoire qui l'a enregistré, à côté du numéro d'inode - qui est une approximation beaucoup plus proche d'un fichier réel .
Alors, vous savez, appelez ça comme vous voulez. Le noyau s'en fiche - toutes les références de fichiers qu'il gérera traiteront de toute façon les vrais numéros d'inode. Le nom de fichier est une chose pour la consommation humaine - si vous voulez en faire une chose folle, eh bien, c'est votre système de fichiers. Ici, je vais faire des trucs fous:
Je vais d'abord créer 20 fichiers et les nommer avec uniquement des espaces, chaque nom de fichier contenant un espace de plus que le dernier:
C'est un peu drôle. Regardez mon
ls
:Maintenant, je vais refléter ce répertoire:
Voici
../mirror/
le contenu de:D'accord, mais vous demandez peut-être - mais à quoi ça sert? Comment savoir lequel est lequel? Comment pouvez-vous être sûr d'avoir lié le bon numéro d'inode au bon nom de fichier?
Bien...
SORTIE
Voir, le numéro d'inode contenu dans
../mirror/"${tgt%% .*}"
et celui référencé par se./' '
réfèrent au même fichier. Ils décrivent le même fichier. Ils le nomment, mais rien de plus. Il n'y a pas de mystère, vraiment, juste quelques inconvénients que vous pourriez vous faire, mais qui auront finalement peu ou pas d'effet sur le fonctionnement de votre système de fichiers Unix à la fin.la source