Quelles conditions doivent être remplies pour qu'un fichier soit un fichier texte tel que défini par POSIX?

POSIX définit un fichier texte comme:

Un fichier qui contient des caractères organisés en zéro ou plusieurs lignes. Les lignes ne contiennent pas de caractères NUL et aucune ne peut dépasser {LINE_MAX} octets de longueur, y compris le caractère <newline>. Bien que POSIX.1-2017 ne fasse pas de distinction entre les fichiers texte et les fichiers binaires (voir la norme ISO C), de nombreux utilitaires ne produisent une sortie prévisible ou significative que lorsqu'ils fonctionnent sur des fichiers texte. Les utilitaires standard qui ont de telles restrictions spécifient toujours des "fichiers texte" dans leurs sections STDIN ou INPUT FILES.

Source: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403

Cependant, il y a plusieurs choses que je trouve peu claires:

1. Un fichier texte doit-il être un fichier normal? Dans l'extrait ci-dessus, il n'est pas dit explicitement que le fichier doit être un fichier normal

2. Un fichier peut-il être considéré comme un fichier texte s'il contient un caractère et un seul caractère (c'est-à-dire un seul caractère qui ne se termine pas par une nouvelle ligne)? Je sais que cette question peut sembler compliquée, mais ils utilisent le mot "caractères" au lieu de "un ou plusieurs caractères". D'autres peuvent être en désaccord, mais s'ils signifient "un ou plusieurs caractères", je pense qu'ils devraient le dire explicitement

3. Dans l'extrait ci-dessus, il fait référence aux "lignes". J'ai trouvé quatre définitions avec une ligne dans leur nom: "Ligne vide", "Ligne d'affichage", "Ligne incomplète" et "Ligne". Suis-je censé déduire qu'ils signifient "Ligne" en raison de leur omission de "Vide", "Affichage" et "Incomplet" - ou les quatre définitions incluses sont-elles toutes considérées comme une ligne dans l'extrait ci-dessus?

Toutes les questions qui viennent après ce bloc de texte dépendent de la déduction que "caractères" signifie "un ou plusieurs caractères":

4. Puis-je inférer en toute sécurité que si un fichier est vide, il ne s'agit pas d'un fichier texte car il ne contient pas un ou plusieurs caractères?

Toutes les questions qui viennent après ce bloc de texte dépendent de la déduction que dans l'extrait ci-dessus, une ligne est définie comme une "ligne", et que les trois autres définitions contenant "ligne" dans leur nom doivent être exclues:

5. Le «zéro» dans «zéro ou plusieurs lignes» signifie-t-il qu'un fichier peut toujours être considéré comme un fichier texte s'il contient un ou plusieurs caractères qui ne se terminent pas par un retour à la ligne?

6. Est-ce que «zéro ou plusieurs lignes» signifie qu'une fois qu'une seule «ligne» (0 ou plusieurs caractères plus une nouvelle ligne de fin) entre en jeu, il devient illégal que la dernière ligne soit une «ligne incomplète» (une ou plusieurs non caractères de nouvelle ligne à la fin d'un fichier)?

7. Est-ce que "aucune [aucune ligne] ne peut dépasser {LINE_MAX} octets de longueur, y compris le caractère de nouvelle ligne" signifie qu'il y a une limitation au nombre de caractères autorisés dans une "ligne" donnée dans un fichier texte (en passant, la valeur de LINE_MAX sur Ubuntu 18.04 et FreeBSD 11.1 est "2048")?

1. Un fichier texte doit-il être un fichier normal? Dans l'extrait ci-dessus, il n'est pas dit explicitement que le fichier doit être un fichier normal

   Non; l'extrait note même spécifiquement l'entrée standard en tant que fichier texte potentiel. D'autres utilitaires standard, tels que make, utilisent spécifiquement le fichier spécial de caractères /dev/null comme fichier texte .

2. Un fichier peut-il être considéré comme un fichier texte s'il contient un caractère et un seul caractère (c'est-à-dire un seul caractère qui ne se termine pas par une nouvelle ligne)?

   Ce caractère doit être un <newline>, ou ce n'est pas une ligne , et donc le fichier dans lequel il se trouve n'est pas un fichier texte. Un fichier contenant exactement l'octet 0A est un fichier texte sur une seule ligne. Une ligne vide est une ligne valide.

3. Dans l'extrait ci-dessus, il fait référence aux "lignes". J'ai trouvé quatre définitions avec une ligne dans leur nom: "Ligne vide", "Ligne d'affichage", "Ligne incomplète" et "Ligne". Suis-je censé inférer qu'ils signifient "Ligne" en raison de leur omission de "Vide", "Affichage" et "Incomplet"

   Ce n'est pas vraiment une inférence, c'est juste ce qu'il dit. Le mot «ligne» a reçu une définition adaptée au contexte et c'est donc de cela qu'il parle.

4. Puis-je inférer en toute sécurité que si un fichier est vide, il ne s'agit pas d'un fichier texte car il ne contient pas un ou plusieurs caractères?

   Un fichier vide se compose de zéro (ou plusieurs) lignes et est donc un fichier texte.

5. Le «zéro» dans «zéro ou plusieurs lignes» signifie-t-il qu'un fichier peut toujours être considéré comme un fichier texte s'il contient un ou plusieurs caractères qui ne se terminent pas par un retour à la ligne?

   Non, ces personnages ne sont pas organisés en lignes.

6. Est-ce que «zéro ou plusieurs lignes» signifie qu'une fois qu'une seule «ligne» (0 ou plusieurs caractères plus une nouvelle ligne de fin) entre en jeu, il devient illégal que la dernière ligne soit une «ligne incomplète» (une ou plusieurs non caractères de nouvelle ligne à la fin d'un fichier)?

   Ce n'est pas illégal , ce n'est tout simplement pas un fichier texte. Un utilitaire exigeant qu'un fichier texte lui soit donné peut se comporter de manière négative s'il est donné à la place.

7. Est-ce que «aucune [aucune ligne] ne peut dépasser {LINE_MAX} octets de longueur, y compris le caractère de nouvelle ligne» signifie qu'il y a une limitation au nombre de caractères autorisés dans une «ligne» donnée dans un fichier texte

   Oui.

Cette définition essaie simplement de définir des limites sur ce qu'un utilitaire basé sur du texte ( par exemple,grep ) acceptera définitivement - rien de plus. Ils sont également libres d'accepter les choses plus libéralement, et le font souvent dans la pratique. Ils sont autorisés à utiliser un tampon de taille fixe pour traiter une ligne, à supposer qu'une nouvelle ligne apparaît avant qu'elle ne soit pleine, etc. Vous lisez peut-être trop de choses.

Comme défini par POSIX:

Oui, un fichier texte est (essentiellement):

Un fichier qui contient des caractères organisés en zéro ou plusieurs lignes.

Il serait utile d'inclure également ces définitions:

3.92 Chaîne de caractères

Une séquence contiguë de caractères se terminant par et incluant le premier octet nul.

3.195 Ligne incomplète

Une séquence d'un ou plusieurs caractères non <nouvelle> à la fin du fichier.

3.206 Ligne

Une séquence de zéro ou plusieurs caractères non <nouvelle> plus un caractère <nouvelle> de fin.

3.243 Caractère de nouvelle ligne (<nouvelle>)

Un caractère qui dans le flux de sortie indique que l'impression doit commencer au début de la ligne suivante. C'est le caractère désigné par '\ n' dans le langage C. Il n'est pas spécifié si ce caractère est la séquence exacte transmise à un périphérique de sortie par le système pour effectuer le mouvement vers la ligne suivante.

3.247 NUL

Un caractère avec tous les bits mis à zéro.

Notez qu'un "fichier texte" ne doit pas contenir d'octets NUL.

Alors:

1. Un fichier texte doit-il être un fichier normal?
   Non, ce n'est pas nécessaire. Un "fichier texte" est défini en termes de ce qu'il contient lors de la lecture. Si un fichier contient "zéro ou plusieurs lignes", c'est un fichier texte. Certains fichiers, comme /dev/stdin, peuvent contenir un fichier texte s'ils sont lus en même temps et non lors de la prochaine lecture.
2. Un fichier peut-il être considéré comme un fichier texte s'il contient un caractère et un seul caractère…?
   Non, c'est une ligne incomplète (3.195).
   Un fichier texte ne doit contenir que des «lignes incomplètes».
3. Suis-je censé en déduire qu'ils signifient «Line»…?
   Oui tu devrais.
4. Puis-je inférer en toute sécurité que si un fichier est vide, ce n'est pas un fichier texte…?
   Non, un fichier vide (zéro caractère) est un "fichier texte" valide.
   D'en haut: … zéro ou plusieurs lignes… . Zéro ligne (zéro caractère) est un "fichier texte" valide.
5. … Considéré comme un fichier texte s'il contient un ou plusieurs caractères qui ne se terminent pas par une nouvelle ligne?
   Non, une "ligne incomplète" n'est pas (techniquement) une "ligne" valide.

6. Le «zéro» dans «zéro ou plusieurs lignes» signifie-t-il qu'un fichier peut toujours être considéré comme un fichier texte s'il contient un ou plusieurs caractères qui ne se terminent pas par un retour à la ligne?
   Non, une ligne incomplète n'est pas une "ligne". Un fichier texte ne doit pas comporter de lignes incomplètes.

7. … Y a-t-il une limitation du nombre de caractères autorisés dans une «ligne» donnée dans un fichier texte…?
   Oui, pas plus de {LINE_MAX} octets (par opposition aux caractères) ne seront autorisés dans une ligne donnée d'un "fichier texte" valide.
   La valeur de {LINE_MAX} est donnée dans le fichier <limits.h>
   (lire aussi Sensible line buffer size in C? ):

   {LINE_MAX}
   Sauf indication contraire, la longueur maximale, en octets, de la ligne d'entrée d'un utilitaire (entrée standard ou autre fichier), lorsque l'utilitaire est décrit comme traitant des fichiers texte. La longueur comprend la place pour la queue.
   Valeur minimale acceptable: {_POSIX2_LINE_MAX}

   Pour un système basé sur GNU, il n'y a pas de limite définie (sauf la mémoire) :

   Macro: int LINE_MAX
   La plus grande ligne de texte prise en charge par les utilitaires POSIX.2 orientés texte. (Si vous utilisez les versions GNU de ces utilitaires, il n'y a pas de limite réelle, sauf celle imposée par la mémoire virtuelle disponible, mais la bibliothèque ne peut pas vous le dire.)

   Il semble être défini posix_lim.hpour être 2048 (au moins pour les systèmes GNU Linux 64 bits):

   $ grep -ri 'POSIX2_LINE_MAX' /usr/include/ 
   
   /usr/include/x86_64-linux-gnu/bits/xopen_lim.h:#define NL_LANGMAX       _POSIX2_LINE_MAX
   /usr/include/x86_64-linux-gnu/bits/posix2_lim.h:#define _POSIX2_LINE_MAX                2048
   /usr/include/x86_64-linux-gnu/bits/posix2_lim.h:#define LINE_MAX                _POSIX2_LINE_MAX
   

   Il peut également être trouvé à l'aide de l' utilitaire POSIX getconf :

   $ getconf LINE_MAX
   2048
   

Connexes: Pourquoi les fichiers texte devraient-ils se terminer par une nouvelle ligne?