aenf - En ligne dans le Cloud

PROGRAMME:

Nom

nouveau fichier aegis - ajouter de nouveaux fichiers à créer par un changement

SYNOPSIS

égide -Nouveau fichier nom de fichier... [ option...]
égide -Nouveau fichier -Lister [ option...]
égide -Nouveau fichier -Aidez-moi

DESCRIPTION

La égide -Nouveau fichier La commande est utilisée pour ajouter de nouveaux fichiers à un changement. Les fichiers nommés seront
être ajouté à la liste des fichiers dans le changement.

Pour chaque fichier nommé, un nouveau fichier est créé dans le répertoire de développement, s'il ne
existent déjà. Si le fichier existe déjà, il ne sera pas modifié.

Si vous voulez qu'un nouveau fichier source soit exécutable (scripts shell, par exemple) alors vous
utilisez simplement la normale chmod(1) commande. Si l'un des bits de l'exécutable du fichier est défini sur
aede(1) fois que le fichier est mémorisé comme exécutable et que tous les bits d'exécution (moins le
umask du projet) sera défini par la suite aecp(1) commandes.

Si vous nommez un répertoire sur la ligne de commande, toute l'arborescence des répertoires sera recherchée
pour les nouveaux fichiers. (Remarque : absolument tout sera ajouté, y compris les fichiers de points et
fichiers binaires, vous devrez donc d'abord nettoyer tous les fichiers indésirables.) Les fichiers ci-dessous nommés
répertoire qui sont déjà dans le changement, ou dans le projet, sera ignoré. Les
nom_fichier_accepte ainsi que nom_fichier_rejeter modèles dans le projet aegis.conf fichier sera également
être appliqué, voir aepconf(5) pour plus d'informations.

Annuaire Exemple
Il y a des moments où une commande telle que
$ aenf Fubar/*
aegis : projet "example" : changement 42 : "fubar/glorp" déjà en cours de changement
aegis : projet "exemple" : changement 42 : 1 erreur fatale trouvée, aucun nouveau fichier ajouté
$
échouera comme indiqué. Il existe plusieurs manières de gérer cela, la plus simple étant de
nommez simplement le répertoire :
$ aenf fubar
aegis : projet "example" : modification 42 : fichier "fubar/smiley" ajouté
aegis : projet "example" : modification 42 : fichier "fubar/frownie" ajouté
$
Vous pouvez également utiliser le trouver(1) commande pour une sélection de fichier arbitrairement complexe, mais vous
doit d'abord exclure les fichiers que la commande ci-dessus exclut automatiquement :
$ aelcf > exclure
$ Aelpf >> exclure
$ trouver fubar De type f | \
grep -v -f exclure | \
xarg égide --nouveau fichier -v
aegis : projet "example" : modification 42 : fichier "fubar/smiley" ajouté
aegis : projet "example" : modification 42 : fichier "fubar/frownie" ajouté
$
Si vous n'utilisez pas la liste d'exclusion, le trouver(1) commande nécessitera un réglage fin pour votre
style de répertoire de développement. Si vous utilisez le style lien symbolique, vous devrez ajouter
le trouver -nlien 1 option en plus de la trouver De type f option.
$ trouver fubar De type f -nliens 1 | \
xarg égide --nouveau fichier -v
aegis : projet "example" : modification 42 : fichier "fubar/smiley" ajouté
aegis : projet "example" : modification 42 : fichier "fubar/frownie" ajouté
$
Si vous utilisez le style de répertoire de développement de copie complète, vous devrez utiliser le
méthode de liste d'exclusion, ci-dessus.

Déposez votre dernière attestation Gabarits
Lorsqu'un nouveau fichier est créé dans le répertoire de développement, le projet config le fichier est
recherché un modèle pour le nouveau fichier. Si un modèle est trouvé, le nouveau fichier sera
initialisé au modèle, sinon il sera créé vide. Voir aepconf(5) pour plus
</br>L’Information.

La forme la plus simple consiste à utiliser des fichiers modèles, tels que
modèle_fichier =
[
{
motif = [ "*.c" ];
body = "${read_file ${source template/c abs}}" ;
},
{
motif = [ "test/*/.sh" ];
body = "${read_file ${source template/test abs}}" ;
},
];
Comme vous pouvez le voir, les fichiers modèles font partie de la source du projet, vous pouvez donc ajouter le
les avis de droits d'auteur et les wrappers appropriés, etcL’ $source la substitution les localise,
s'ils ne font pas partie du changement en cours (et ils ne le font généralement pas).

Les fichiers modèles eux-mêmes contiennent des substitutions. Les $nom de fichier la substitution est
disponible et contient le nom du fichier en cours de création. Cela peut être manipulé dans
différentes manières lors de la construction du contenu de fichier approprié. Voir aesub(5) pour plus
informations sur les remplacements.

Il est également possible d'exécuter une commande pour créer le nouveau fichier. Vous pouvez le faire au lieu de
spécifier une chaîne de corps, à savoir:
modèle_fichier =
[
{
motif = [ "*" ];
body_command = "perl ${source template.pl abs} $filename" ;
},
];
La commande est exécutée avec un répertoire courant défini en haut du répertoire de développement.
C'est une erreur si la commande ne parvient pas à créer le fichier. Vous pouvez mélanger et assortir les deux
techniques, corps chaîne et corps_commande, si tu veux.

Déposez votre dernière attestation Nom Limites
Il existe un certain nombre de contrôles disponibles pour limiter la forme des noms de fichiers de projet. Tous
ces champs se trouvent dans le fichier de configuration du projet, voir aepconf(5) pour plus
informations. Les plus importants sont brièvement décrits ici :

maximum_filename_length = entier ;
Ce champ est utilisé pour limiter la longueur des noms de fichiers. Tous les nouveaux fichiers peuvent ne pas avoir
composants de chemin plus longs que cela. La valeur par défaut est 255 si elle n'est pas définie. Pour un maximum
portabilité, vous devez le définir sur 14.

posix_filename_charset = booléen ;
Ce champ peut être utilisé pour limiter les caractères autorisés dans les noms de fichiers à ceux
explicitement autorisé par POSIX. Par défaut à non s'il n'est pas défini, c'est-à-dire quel que soit votre
le système d'exploitation tolérera, à l'exception des espaces blancs et des caractères high-bit-on.
Pour une portabilité maximale, vous devez définir ceci sur oui.

dos_filename_required = booléen ;
Ce champ peut être utilisé pour limiter les noms de fichiers afin qu'ils soient conformes au DOS 8+3
limites de nom de fichier et au jeu de caractères de nom de fichier DOS. Par défaut à non si non
défini.

windows_filename_required = booléen ;
Ce champ peut être utilisé pour limiter les noms de fichiers afin qu'ils soient conformes à Windows98
et les limites de nom de fichier et le jeu de caractères WindowsNT. Par défaut à non s'il n'est pas défini.

shell_safe_filenames = booléen ;
Ce champ peut être utilisé pour limiter les noms de fichiers afin qu'ils ne contiennent pas de shell
caractères spéciaux. Par défaut à oui s'il n'est pas défini. Si ce champ est défini sur non,
vous devrez utiliser le ${citation} substitution autour des noms de fichiers dans les commandes, pour
assurez-vous que les noms de fichiers contenant des caractères spéciaux du shell n'ont pas
Effets secondaires. Des caractères étranges dans les noms de fichiers peuvent également embrouiller votre dépendance
outil d'entretien.

allow_white_space_in_filenames = booléen ;
Ce champ peut être utilisé pour autoriser les espaces blancs dans les noms de fichiers. Cette volonté
autoriser l'apparition des caractères suivants dans les noms de fichiers : retour arrière (BS, \b, 0x08),
tabulation horizontale (HT, \t, 0x09), nouvelle ligne (NL, \n, 0x0A), tabulation verticale (VT, \v,
0x0B), saut de page (FF, \f, 0x0C) et retour chariot (CR, \r, 0x0D). Par défaut à
false s'il n'est pas défini.

Notez que ce champ ne remplace pas les autres filtres de nom de fichier. Ce sera
nécessaire de définir explicitement shell_safe_filenames = non également. Ce sera
nécessaire de définir dos_filename_required = non (la valeur par défaut) également. Ce sera
nécessaire de définir posix_filename_charset = non (la valeur par défaut) également.

L'utilisateur doit prendre grand soin d'utiliser la substitution ${quote} autour de tous les fichiers
noms dans les commandes de la configuration du projet. Et même alors, les remplacements
qui attendent une liste de noms de fichiers séparés par des espaces auront des résultats indéfinis.

allow_non_ascii_filenames = booléen ;
Ce champ peut être utilisé pour autoriser les noms de fichiers avec des caractères non-ascii imprimables dans
eux. Habituellement, cela signifierait un UTF8 ou un jeu de caractères international quelconque.
La valeur par défaut est false si elle n'est pas définie.

Notez que ce champ ne remplace pas les autres filtres de nom de fichier. Ce sera
nécessaire de définir explicitement shell_safe_filenames = non également. Ce sera
nécessaire de définir dos_filename_required = non (la valeur par défaut) également. Ce sera
nécessaire de définir posix_filename_charset = non (la valeur par défaut) également.

filename_pattern_accept = [ chaîne ];
Ce champ est utilisé pour spécifier une liste de modèles de noms de fichiers acceptables.
La valeur par défaut est "*" si elle n'est pas définie.

filename_pattern_reject = [ chaîne ];
Ce champ est utilisé pour spécifier une liste de modèles de noms de fichiers inacceptables.

Veuillez Remarque: Aegis consulte également le système de fichiers sous-jacent, pour déterminer sa notion de
taille maximale du fichier. Lorsque la taille de fichier maximale du système de fichiers est inférieure à
longueur_nom_fichier maximum, le système de fichiers gagne. Cela peut arriver, par exemple, lorsque vous êtes
en utilisant le système de fichiers Linux UMSDOS, ou lorsque vous avez un NFS monté sur un ancien V7
système de fichiers. Réglage longueur_nom_fichier maximum à 255 dans ces cas ne modifie pas le
fait que les limites des systèmes de fichiers sous-jacents sont beaucoup plus petites (12 et 14, respectivement).

Si vos répertoires de développement (ou l'ensemble de votre projet) se trouvent sur des systèmes de fichiers avec le nom de fichier
limitations, ou une partie des builds hétérogènes ont lieu dans un tel environnement,
cela aide à dire à Aegis ce qu'ils sont (en utilisant le projet config champs du fichier) afin que vous
ne vous heurtez pas à la situation où le projet s'appuie sur le plus permissif
environnements, mais échoue avec des erreurs mystérieuses dans les environnements les plus limités.

Si vos répertoires de développement se trouvent régulièrement sur un système de fichiers Linux UMSDOS, vous
il vaut probablement mieux régler dos_filename_required = oui, et aussi changer le
development_directory_template champ. Développement hétérogène avec différentes fenêtres
les environnements peuvent également l'exiger.

Déposez votre dernière attestation Nom Interprétation
Le programme égide tentera de déterminer les noms de fichiers du projet à partir des noms de fichiers
donné sur la ligne de commande. Tous les noms de fichiers sont stockés dans les projets égide en tant que relatifs
à la racine de l'arborescence de répertoires de base. L'annuaire de développement et le
répertoire d'intégration sont des ombres de ce répertoire de base, et donc ces noms relatifs
postulez ici aussi. Les fichiers nommés sur la ligne de commande sont d'abord convertis en chemins absolus
si nécessaire. Ils sont ensuite comparés au chemin de référence, le répertoire de développement
chemin et le chemin du répertoire d'intégration, pour déterminer un nom relatif à la ligne de base. Il est
une erreur si le fichier nommé se trouve en dehors de l'une de ces arborescences de répertoires.

La -BAse_RElative L'option peut être utilisée pour que les noms de fichiers relatifs soient interprétés comme
par rapport au chemin de la ligne de base ; les noms de fichiers absolus seront toujours comparés aux différents
chemins afin de déterminer un nom relatif à la ligne de base.

La nom_fichier_relatif_préférence dans le fichier de configuration utilisateur peut être utilisé pour modifier
ce comportement par défaut. Voir aeuconf(5) pour plus d'informations.

Changer le Type of a Déposez votre dernière attestation
Si vous souhaitez modifier le type d'un fichier (par exemple, d'un fichier test à un fichier source, ou vice
vice versa) vous pouvez le faire en deux changements, en utilisant d'abord aerm(1) en un seul changement puis
en utilisant aenf(1) ou aent(1) dans un deuxième changement, ou vous pouvez combiner les deux étapes dans le même
monnaie. N'oubliez pas d'utiliser le aerm -pas de blanc option ou vous obtiendrez un nouveau plus particulier
modèle de fichier.

Déposez votre dernière attestation Action Le réglage
Lorsque cette commande s'exécute, elle vérifie d'abord les fichiers de modifications par rapport aux fichiers de projets. Si
il y a des incohérences, les actions du fichier seront ajustées comme suit :

create Si un fichier est en cours de création, mais qu'un autre ensemble de modifications est intégré qui
crée le fichier, l'action de fichier dans l'ensemble de modifications encore en cours de développement sera
ajusté à "modifier".

modifier Si un fichier est en cours de modification, mais qu'un autre ensemble de modifications est intégré, ce qui supprime
le fichier, l'action du fichier dans l'ensemble de modifications encore en cours de développement sera
ajusté à "créer".

remove Si un fichier est supprimé, mais qu'un autre ensemble de modifications est intégré, ce qui supprime
le fichier, le fichier sera supprimé de l'ensemble de modifications encore en cours de développement.

Notification
La nouvelle_commande_fichier dans le fichier de configuration du projet est exécuté, s'il est défini. Les projet_-
fichier_commande est également exécuté, s'il est défini, et s'il y a eu une intégration récemment. Voir
aepconf(5) pour plus d'informations.

TEST CORRÉLATIONS

La commande « aegis -Test -SUGgest » peut être utilisée pour que aegis suggère une régression appropriée
teste votre modification, en fonction des fichiers source de votre modification. Ceci automatiquement
concentre les efforts de test sur des tests pertinents, réduisant le nombre de tests de régression
nécessaire d'être sûr que vous n'avez pas introduit de bogue.

Les corrélations de test sont générées par la commande "aegis -Integrate_Pass", qui
associe chaque test de la modification à chaque fichier source de la modification. Ainsi, chaque
Le fichier source accumule une liste de tests qui lui ont été associés dans le passé.
Ce n'est pas aussi exact que l'analyse de couverture de code, mais c'est une approximation raisonnable dans
entraine toi.

La aecpde Géographie (1) et avec la aenf(1) les commandes sont utilisées pour associer des fichiers à une modification. Pendant qu'ils
n'effectuez pas activement l'association, ce sont les fichiers utilisés par aeipassde Géographie (1) et avec la
aet(1) pour déterminer quels fichiers sources sont associés à quels tests.

Teste Corrélation Précision
En supposant que les corrélations de test sont exactes et que les tests sont uniformément
répartis dans l'espace fonctionnel, il y aura moins de 1/nombre chance qu'un
le test pertinent n'a pas été exécuté par le "aegis -Test -SUGgest nombre" commande. Un petit
quantité de bruit est ajoutée à la pondération de test, de sorte que des choses inattendues sont parfois
testé, et les mêmes tests ne sont pas exécutés à chaque fois.

La précision de la corrélation des tests peut être améliorée en s'assurant que :

· Chaque changement doit être fortement ciblé, sans inclusions de fichiers gratuites. Cette
évite les fausses corrélations.

· Chaque élément de nouvelle fonctionnalité doit être ajouté dans un changement individuel, plutôt que
plusieurs ensemble. Cela corrèle fortement les tests avec la fonctionnalité.

· Chaque bogue devrait être corrigé dans un changement individuel, plutôt que plusieurs ensemble. Cette
corrèle fortement les tests avec la fonctionnalité.

· Les corrélations de test seront perdues si les fichiers sont déplacés. C'est parce que les corrélations sont par
nom.

Le meilleur moyen pour les tests d'établir une corrélation précise avec les fichiers source est lorsqu'un changement
contient un test et exactement les fichiers relatifs à la fonctionnalité testée. Trop
de nombreux fichiers parasites affaibliront l'utilité des tests de corrélation.

OPTIONS

Les options suivantes sont comprises

-Construire
Cette option peut être utilisée pour spécifier que le fichier est construit lors d'une construction
(souvent uniquement une version intégrée), afin que l'historique de celui-ci puisse être conservé. C'est
utile pour générer des fichiers de correctifs, où un historique des fichiers générés est
important. Les fichiers créés de cette manière ne peuvent pas être copiés dans une modification, bien que
ils peuvent être supprimés. Évitez d'utiliser des fichiers de ce type, dans la mesure du possible.

-BAse_RElative
Cette option peut être utilisée pour que les noms de fichiers relatifs soient considérés par rapport à
la base de l'arbre source. Voir aeuconf(5) pour l'utilisateur correspondant
préférence.

-Current_RElative
Cette option peut être utilisée pour que les noms de fichiers relatifs soient considérés par rapport à
le répertoire courant. C'est généralement la valeur par défaut. Voir aeuconf(5) pour le
préférence correspondante de l'utilisateur.

-Changer nombre
Cette option peut être utilisée pour spécifier un changement particulier dans un projet. Voir
égide(1) pour une description complète de cette option.

-Configuré
Cette option peut être utilisée pour spécifier que le fichier est un projet Aegis
fichier de configuration. Le fichier de configuration du projet par défaut est appelé aegis.conf,
cependant, n'importe quel nom de fichier peut être utilisé. Vous pouvez également utiliser plusieurs fichiers,
répartir le contenu sur plusieurs fichiers, qui doivent tous être de ce type.

-Aidez-moi
Cette option peut être utilisée pour obtenir plus d'informations sur la façon d'utiliser le égide
.

-Garder
Cette option peut être utilisée pour conserver les fichiers et/ou répertoires habituellement supprimés ou
remplacé par la commande. Par défaut à l'utilisateur delete_file_preference si non
spécifié, voir aeuconf(5) pour plus d'informations.

-Non_Conserver
Cette option peut être utilisée pour s'assurer que les fichiers et/ou répertoires sont supprimés
ou remplacé par la commande. Par défaut à l'utilisateur delete_file_preference si non
spécifié, voir aeuconf(5) pour plus d'informations.

-Lister
Cette option peut être utilisée pour obtenir une liste de sujets appropriés pour cette commande.
La liste peut être plus générale que prévu.

-Not_Logging
Cette option peut être utilisée pour désactiver l'enregistrement automatique de la sortie et des erreurs à
un fichier. Ceci est souvent utile lorsque plusieurs commandes aegis sont combinées dans un shell
scripts.

-Projet prénom
Cette option peut être utilisée pour sélectionner le projet d'intérêt. Quand non -Projet
l'option est spécifiée, le AEGIS_PROJET variable d'environnement est consultée. Si
qui n'existe pas, l'utilisateur $HOME/.aegisrc le fichier est examiné pour un défaut
domaine du projet (voir aeuconf(5) pour plus d'informations). Si cela n'existe pas,
lorsque l'utilisateur ne travaille que sur des modifications au sein d'un même projet, le projet
nom par défaut à ce projet. Sinon, c'est une erreur.

-Modèle
Cette option peut être utilisée pour spécifier qu'un nouveau modèle de fichier doit être utilisé, même
si le fichier existe déjà.

-No_TEMPplate
Cette option peut être utilisée pour spécifier qu'un nouveau modèle de fichier ne doit pas être utilisé,
même si le fichier n'existe pas (tout fichier vide sera créé).

-Laconique
Cette option peut être utilisée pour que les annonces produisent le strict minimum de
informations. Il est généralement utile pour les scripts shell.

-Verbeux
Cette option peut être utilisée pour amener aegis à produire plus de sortie. Par défaut égide
ne produit une sortie que sur les erreurs. Lorsqu'il est utilisé avec le -Lister option cette option
provoque l'ajout d'en-têtes de colonnes.

-Attendez Cette option peut être utilisée pour exiger que les commandes Aegis attendent les verrous d'accès, si
ils ne peuvent pas être obtenus immédiatement. Par défaut à l'utilisateur lock_wait_preference
si non spécifié, voir aeuconf(5) pour plus d'informations.

-Non attends
Cette option peut être utilisée pour exiger que les commandes Aegis émettent une erreur fatale si l'accès
les serrures ne peuvent pas être obtenues immédiatement. Par défaut à l'utilisateur
lock_wait_preference si non spécifié, voir aeuconf(5) pour plus d'informations.

Voir aussi égide(1) pour les options communes à toutes les commandes aegis.

Toutes les options peuvent être abrégées ; l'abréviation est documentée en lettres majuscules,
toutes les lettres minuscules et les traits de soulignement (_) sont facultatifs. Vous devez utiliser consécutivement
séquences de lettres facultatives.

Toutes les options sont insensibles à la casse, vous pouvez les saisir en majuscules ou en minuscules ou un
combinaison des deux, la casse n'a pas d'importance.

Par exemple : les arguments "-project, "-PROJ" et "-p" sont tous interprétés comme signifiant le
-Projet option. L'argument "-prj" ne sera pas compris, car consécutifs
les caractères facultatifs n'ont pas été fournis.

Les options et autres arguments de ligne de commande peuvent être mélangés arbitrairement sur la ligne de commande,
après les sélecteurs de fonction.

Les noms d'options longs GNU sont compris. Étant donné que tous les noms d'option pour égide sont longues,
cela signifie ignorer le "-" de début supplémentaire. Les "--option=Plus-value" la convention est aussi
compris.

RECOMMANDÉ ALIAS

L'alias recommandé pour cette commande est
csh% alias aenf 'aegis -nf \!* -v'
sh$ aenf(){aegis -nf "$@" -v}

LES ERREURS

C'est une erreur si le changement n'est pas dans le va développé Etat.
C'est une erreur si la modification n'est pas attribuée à l'utilisateur actuel.
C'est une erreur si le fichier fait déjà partie de la modification.
C'est une erreur si le fichier fait déjà partie de la ligne de base.
C'est une erreur si les fichiers nommés sur la ligne de commande ne sont pas des fichiers normaux et non
répertoires. (Si vous avez besoin de liens symboliques ou de fichiers spéciaux, créez-les au moment de la construction.)

EXIT STATUT

La égide La commande se terminera avec un statut de 1 en cas d'erreur. Les égide la commande ne fera que
quitter avec un statut de 0 s'il n'y a pas d'erreurs.

ENVIRONNEMENT VARIABLES

See égide(1) pour une liste des variables d'environnement qui peuvent affecter cette commande. Voir
aepconf(5) pour le fichier de configuration du projet projet_spécifique champ pour savoir comment définir
variables d'environnement pour toutes les commandes exécutées par Aegis.

Utiliser aenf en ligne en utilisant les services onworks.net