pathchkposix - En ligne dans le Cloud

PROGRAMME:

Nom

pathchk — vérifier les noms de chemin

SYNOPSIS

chemin [−p] [−P] chemin d'accès

DESCRIPTION

Notre chemin L'utilitaire doit vérifier qu'un ou plusieurs chemins sont valides (c'est-à-dire qu'ils pourraient
être utilisé pour accéder ou créer un fichier sans provoquer d'erreurs de syntaxe) et portable (c'est-à-dire,
aucun résultat de troncature de nom de fichier). Des contrôles de portabilité plus poussés sont fournis par le −p
et −P options.

Par défaut, le chemin le service public doit vérifier chaque composant de chaque chemin d'accès basé sur l'opérande
sur le système de fichiers sous-jacent. Un diagnostic doit être rédigé pour chaque chemin d'accès opérande
que:

* Est plus long que {PATH_MAX} octets (voir Chemin d'accès Variable VALEURS dans les définitions de base
tome de POSIX.1‐2008, )

* Contient tout composant de plus de {NAME_MAX} octets dans son répertoire conteneur

* Contient n'importe quel composant dans un répertoire qui n'est pas consultable

* Contient toute séquence d'octets qui n'est pas valide dans son répertoire contenant

Le format du message de diagnostic n'est pas spécifié, mais doit indiquer l'erreur
détecté et le correspondant chemin d'accès opérande.

Il n'est pas considéré comme une erreur si un ou plusieurs composants d'un chemin d'accès l'opérande ne
exister tant qu'un fichier correspondant au chemin spécifié par les composants manquants pourrait être
créé qui ne viole aucune des vérifications spécifiées ci-dessus.

OPTIONS

Notre chemin l'utilitaire doit être conforme au volume Base Definitions de POSIX.1‐2008, Blog
12.2, Services Publics Syntaxe Recommandations.

L'option suivante doit être prise en charge :

−p Au lieu d'effectuer des vérifications basées sur le système de fichiers sous-jacent, écrivez un
diagnostique pour chaque chemin d'accès opérande que :

* Est plus long que {_POSIX_PATH_MAX} octets (voir Minimum VALEURS dans la base
Volume des définitions de POSIX.1‐2008, )

* Contient tout composant de plus de {_POSIX_NAME_MAX} octets

* Contient n'importe quel caractère dans n'importe quel composant qui n'est pas dans le nom de fichier portable
Jeu de caractères

−P Rédiger un diagnostic pour chacun chemin d'accès opérande que :

* Contient un composant dont le premier caractère est le personnage

* Est vide

OPÉRANDES

L'opérande suivant doit être pris en charge :

chemin d'accès Un chemin à vérifier.

STDIN

Non utilisé.

CONTRIBUTION DES DOSSIERS

Aucun.

ENVIRONNEMENT VARIABLES

Les variables d'environnement suivantes doivent affecter l'exécution de chemin:

LANGUE Fournissez une valeur par défaut pour les variables d'internationalisation qui ne sont pas définies ou
nul. (Voir le volume Définitions de base de POSIX.1‐2008, Blog 8.2,
Internationalisation Variables la préséance des variables d'internationalisation
utilisé pour déterminer les valeurs des catégories de paramètres régionaux.)

LC_TOUS S'il est défini sur une valeur de chaîne non vide, remplace les valeurs de tous les autres
variables d'internationalisation.

LC_CTYPE Déterminer la localisation pour l'interprétation des séquences d'octets de données de texte
sous forme de caractères (par exemple, des caractères à un octet par opposition aux caractères à plusieurs octets dans
arguments).

LC_MESSAGES
Déterminez les paramètres régionaux qui doivent être utilisés pour affecter le format et le contenu de
messages de diagnostic écrits dans l'erreur standard.

NLSPATH Déterminer l'emplacement des catalogues de messages pour le traitement des LC_MESSAGES.

ASYNCHRONE ÉVÈNEMENTS

Par défaut.

SORTIE STD

Non utilisé.

STDERR

L'erreur standard ne doit être utilisée que pour les messages de diagnostic.

SORTIE DES DOSSIERS

Aucun.

ÉLARGI DESCRIPTION

Aucun.

EXIT STATUT

Les valeurs de sortie suivantes doivent être renvoyées :

0 Tous chemin d'accès les opérandes ont réussi toutes les vérifications.

>0 Une erreur s'est produite.

CONSÉQUENCES OF LES ERREURS

Par défaut.

Notre Abonnement les sections are informatif.

INSCRIPTION UTILISATION

Notre tester l'utilitaire peut être utilisé pour déterminer si un chemin d'accès donné nomme un fichier existant ;
il ne donne cependant aucune indication sur le fait qu'un élément du chemin d'accès
a été tronqué dans un répertoire où la fonctionnalité _POSIX_NO_TRUNC n'est pas en vigueur. Les
chemin l'utilitaire ne vérifie pas l'existence du fichier ; il effectue des vérifications pour déterminer si
un chemin d'accès existe ou pourrait être créé sans troncature de composant de chemin d'accès.

Notre nul option dans le shell (voir le set spécial intégré) peut être utilisé pour atomiquement
créer un fichier. Comme pour toutes les sémantiques de création de fichiers dans le volume System Interfaces de
POSIX.1‐2008, il garantit la création atomique, mais dépend toujours des applications sur lesquelles se mettre d'accord
conventions et coopérer sur l'utilisation des fichiers après leur création.

Pour vérifier qu'un chemin d'accès répond aux exigences de portabilité des noms de fichiers, les applications
devrait utiliser à la fois le −p et −P options ensemble.

EXEMPLES

Pour vérifier que tous les chemins d'accès d'une archive d'échange de données importée sont légitimes et
sans ambiguïté sur le système actuel :

# Cette (ici) suppose qui aucune chemins d'accès in le archives
# contiennent caractères.
pax −f archives | sed -e 's/[^[:alnum:]]/\\&/g' | xarg chemin −−
if [ $? −éq 0 ]
puis
pax -r −f archives
d'autre
echo Enquêter d'ouvrabilité avant l'importation fichiers.
sortie 1
fi

Pour vérifier que tous les fichiers de la hiérarchie de répertoires actuelle peuvent être déplacés vers n'importe quel système
conforme au volume System Interfaces de POSIX.1‐2008 qui prend également en charge le pax
utilitaire:

trouver . −exécutable chemin −p −P {} +
if [ $? −éq 0 ]
puis
pax -w −f ../archiver .
d'autre
echo Portable archives ne peut pas be créé.
sortie 1
fi

Pour vérifier qu'un chemin d'accès fourni par l'utilisateur nomme un fichier lisible et que l'application peut
créer un fichier étendant le chemin donné sans troncature et sans écraser aucun
fichier existant :

maisons $− in
*C*) réinitialiser="";;
*) reset="définir +C"
set -C;;
Esac
tester -r "$chemin" && chemin "$chemin.out" &&
rm "$chemin.out" > "$chemin.out"
if [ $? −ne 0 ]; puis
printf "%s : %s pas trouvé or %s.out échoue \
création chèques.\n" $0 "$chemin$chemin"
$réinitialiser # Réinitialiser le nul option in maisons a piège
# on EXIT dépend on le
sortie 1
fi
$réinitialiser
TRAITEMENT DES SEMENCES < "$chemin" > "$chemin.out"

Les hypothèses suivantes sont faites dans cet exemple :

1. TRAITEMENT DES SEMENCES représente le code qui est utilisé par l'application pour utiliser $ path une fois que c'est
vérifié que $path.out fonctionne comme prévu.

2. L'état de la nul L'option est inconnue lorsque ce code est invoqué et doit être
mis à la sortie à l'état dans lequel il se trouvait lorsque ce code a été invoqué. (Les réinitialiser la variable est
utilisé dans cet exemple pour restaurer l'état initial.)

3. Notez l'utilisation de :

rm "$chemin.out" > "$chemin.out"

une. le chemin commande a déjà vérifié, à ce stade, que $path.out n'est pas
tronqué.

b. Avec le nul jeu d'options, le shell vérifie que $path.out ne fait pas déjà
exister avant d'invoquer rm.

c. Si le shell a réussi à créer $path.out, rm l'enlève pour que le
l'application peut recréer le fichier dans le TRAITEMENT DES SEMENCES étape.

ré. Si la TRAITEMENT DES SEMENCES step veut que le fichier existe déjà lorsqu'il est appelé, le :

rm "$chemin.out" > "$chemin.out"

doit être remplacé par :

> "$chemin.out"

qui vérifie que le fichier n'existait pas déjà, mais laisse $path.out en place
destiné à être utilisé par TRAITEMENT DES SEMENCES.

RAISONNEMENT

Notre chemin L'utilitaire était nouveau pour la norme ISO POSIX-2:1993. Il, avec le set
-C(nul) ajoutée au shell, remplace l'option mktemp, nom de domaine valide et engendrent
services publics qui figuraient dans les premières propositions. Tous ces utilitaires étaient des tentatives pour résoudre
plusieurs problèmes courants :

* Vérifier la validité (pour plusieurs définitions différentes de ``valide'') d'un nom de chemin
fournis par un utilisateur, générés par une application, ou importés d'une source externe.

* Créer atomiquement un fichier.

* Effectuez diverses fonctions de gestion des chaînes pour générer un nom de fichier temporaire.

Notre engendrent utilitaire, inclus dans une première proposition, fournissait la vérification et la création atomique
en une seule invocation de l'utilitaire ; ce sont des problèmes orthogonaux et n'ont pas besoin d'être regroupés
en un seul utilitaire. Notez que le nul L'option fournit également un moyen de créer un
verrou pour la synchronisation des processus ; car il fournit un atomique engendrent, il n'y a pas de course
entre un test d'existence et la création suivante s'il n'existait pas.

Avoir une fonction comme tmpnam() dans la norme ISO C est important dans de nombreux
langues. Le langage de programmation shell, cependant, a une manipulation de chaîne intégrée
installations, ce qui rend très facile la construction de noms de fichiers temporaires. Les noms nécessaires
dépendent évidemment de l'application, mais sont fréquemment d'une forme similaire à :

$TMPDIR/application_abreviation$$.suffixe

Dans les cas où il est probable qu'il y ait conflit pour un suffixe donné, un simple shell pour or
tout en la boucle peut être utilisée avec le shell nul possibilité de créer un fichier sans risque de
collisions, tant que les applications essayant d'utiliser le même espace de nom de fichier sont
coopérer sur l'utilisation des fichiers après leur création.

A des fins historiques, −p ne vérifie pas l'utilisation du personnage comme le
premier caractère dans un composant du chemin d'accès, ou pour un vide chemin d'accès opérande.

FUTUR DIRECTIONS

Aucun.

Utilisez pathchkposix en ligne à l'aide des services onworks.net