man signifie « manuel » et sert à afficher la page de manuel de la commande qui t'intéresse. Y recourir doit devenir un réflexe et c'est souvent vers elle qu'on te renverra en premier lieu chaque fois que tu demanderas de l'aide. Indice : on sort de la page concernée en appuyant sur « Q » (toujours bon à savoir la première fois).
Essaie man mkdir, par exemple.
et cat je ne compte pas lutiliser, je lai juste appris cette aprem, alors cest sortis tout seul
cat, tu l'utiliseras tout le temps. :-) Et probablement à tort, comme tout le monde. « cat » signifie catenate et sert à concaténer sur la sortie standard le contenu de tous les fichiers dont tu auras précisé le nom, successivement et dans l'ordre. C'est utile en soi, mais comme le résultat est envoyé sur la sortie standard, laquelle est elle-même renvoyée vers l'écran à défaut d'instructions contraires, alors ça devient utile pour visualiser facilement le contenu d'un fichier, même si tu n'en spécifies qu'un seul. En ce sens, ça rend le même service que la commande « type » sous DOS.
Les UUOC dont on te parle dans les autres commentaires viennent du fait qu'il est tentant de se servir de cette commande pour afficher le contenu du fichier puis le rediriger vers une autre commande à l'aide d'un pipe « | », alors que les opérateurs de redirection « < » et « > » servent précisément à cela, et qu'il est bon de prendre l'habitude de les utiliser directement, plutôt qu'instancier un processus qui, effectivement, n'était pas nécessaire.
t jai bosser la fonction ln mais javoue ne pas vraiment avoir compri lutiliter davoir deux fichier liee , je comprend pas le but du concept
C'est très pratique quand plusieurs fichiers doivent avoir le même contenu, ou qu'un même fichier doit porter plusieurs noms. Il faut se souvenir qu'UNIX a été d'emblée un système multi-utilisateurs et que jusqu'à une époque pas très lointaine (jusqu'à la fin des années 90, en gros), l'espace disque était limité et précieux.
Quand tu crées un lien dur (ln tout seul), tu donnes en fait plusieurs noms au même fichier. Quand tu édites ce fichier, tu vois tes modifications quelque soit le nom sous lequel tu l'ouvres ensuite et (surtout) il n'y a qu'un seul exemplaire des données sur le disque. Tous les noms renvoient vers le même endroit physique. Une fois déclarés, tous les liens sont semblables. Il n'y a pas de moyen de savoir a posteriori si une entrée est le nom original d'un fichier ou s'il s'agit d'un lien dur.
Le système conserve le nombre de liens durs référençant un même fichier (dans l'inode). Chaque fois que tu effaces un fichier, ce nombre est décrémenté et ce n'est que lorsqu'il arrive à zéro (donc quand plus aucun lien ne référence le fichier) que l'espace disque qu'il occupe est réellement libéré.
C'est utile si, par exemple, tu souhaites mettre par défaut un fichier en lecture seule dans le répertoire de tous les utilisateurs de ton système. Cela évite de consommer de l'espace inutilement avec des copies et laisse malgré tout la latitude à chacun de l'effacer quand ça lui chante. Lorsque tous les utilisateurs ont effacé leur propre « copie », l'espace disque est libéré.
C'est très pratique également si tu veux faire apparaître un même fichier à différents endroits d'une même partition, lorsque les processus qui doivent y accéder ne peuvent se promener librement sur la totalité de l'arborescence, soit à cause de droits d'accès en vigueur, soit lorsque tu utilises chroot.
Les liens symboliques, à présent, sont des fichiers distincts qui ne contiennent qu'une simple chaîne de caractères, qui correspond au chemin d'accès au fichier original. En ce sens, ils ressemblent un peu aux raccourcis *.lnk mais ils ne contiennent aucune autre information et surtout, ils sont gérés directement au niveau du système de fichiers par l'OS, si bien que n'importe quel programme faisant un open sur un lien symbolique ouvrira en fait le fichier pointé et pas le lien symbolique lui-même, de façon complètement transparente et ce même si le programme n'est pas explicitement prévu pour.
C'est utile pour toutes sortes d'applications : pour créer des alias, mais également pour être automatiquement redirigé vers le fichier à utiliser à un moment donné (lequel peut changer), etc. On les utilise notamment dans /lib et /usr/lib pour rediriger une version d'une bibliothèque vers la bonne sous-version.
Les liens durs et les liens symboliques ont chacun leurs avantages et leurs inconvénients, mais une chose est certaine : quand on y a goûté, on n'a plus envie de revenir en arrière. Ceci est également vrai pour Unix en général, et pour les logiciels libres de façon plus globale encore. :-)
[^] # Re: shell unix
Posté par Obsidian . En réponse au message Recherche d'exercices a faire avec le SHELL Unix. Évalué à 4.
Bonjour,
man signifie « manuel » et sert à afficher la page de manuel de la commande qui t'intéresse. Y recourir doit devenir un réflexe et c'est souvent vers elle qu'on te renverra en premier lieu chaque fois que tu demanderas de l'aide. Indice : on sort de la page concernée en appuyant sur « Q » (toujours bon à savoir la première fois).
Essaie man mkdir, par exemple.
cat, tu l'utiliseras tout le temps. :-) Et probablement à tort, comme tout le monde. « cat » signifie catenate et sert à concaténer sur la sortie standard le contenu de tous les fichiers dont tu auras précisé le nom, successivement et dans l'ordre. C'est utile en soi, mais comme le résultat est envoyé sur la sortie standard, laquelle est elle-même renvoyée vers l'écran à défaut d'instructions contraires, alors ça devient utile pour visualiser facilement le contenu d'un fichier, même si tu n'en spécifies qu'un seul. En ce sens, ça rend le même service que la commande « type » sous DOS.
Les UUOC dont on te parle dans les autres commentaires viennent du fait qu'il est tentant de se servir de cette commande pour afficher le contenu du fichier puis le rediriger vers une autre commande à l'aide d'un pipe « | », alors que les opérateurs de redirection « < » et « > » servent précisément à cela, et qu'il est bon de prendre l'habitude de les utiliser directement, plutôt qu'instancier un processus qui, effectivement, n'était pas nécessaire.
C'est très pratique quand plusieurs fichiers doivent avoir le même contenu, ou qu'un même fichier doit porter plusieurs noms. Il faut se souvenir qu'UNIX a été d'emblée un système multi-utilisateurs et que jusqu'à une époque pas très lointaine (jusqu'à la fin des années 90, en gros), l'espace disque était limité et précieux.
Quand tu crées un lien dur (ln tout seul), tu donnes en fait plusieurs noms au même fichier. Quand tu édites ce fichier, tu vois tes modifications quelque soit le nom sous lequel tu l'ouvres ensuite et (surtout) il n'y a qu'un seul exemplaire des données sur le disque. Tous les noms renvoient vers le même endroit physique. Une fois déclarés, tous les liens sont semblables. Il n'y a pas de moyen de savoir a posteriori si une entrée est le nom original d'un fichier ou s'il s'agit d'un lien dur.
Le système conserve le nombre de liens durs référençant un même fichier (dans l'inode). Chaque fois que tu effaces un fichier, ce nombre est décrémenté et ce n'est que lorsqu'il arrive à zéro (donc quand plus aucun lien ne référence le fichier) que l'espace disque qu'il occupe est réellement libéré.
C'est utile si, par exemple, tu souhaites mettre par défaut un fichier en lecture seule dans le répertoire de tous les utilisateurs de ton système. Cela évite de consommer de l'espace inutilement avec des copies et laisse malgré tout la latitude à chacun de l'effacer quand ça lui chante. Lorsque tous les utilisateurs ont effacé leur propre « copie », l'espace disque est libéré.
C'est très pratique également si tu veux faire apparaître un même fichier à différents endroits d'une même partition, lorsque les processus qui doivent y accéder ne peuvent se promener librement sur la totalité de l'arborescence, soit à cause de droits d'accès en vigueur, soit lorsque tu utilises chroot.
Les liens symboliques, à présent, sont des fichiers distincts qui ne contiennent qu'une simple chaîne de caractères, qui correspond au chemin d'accès au fichier original. En ce sens, ils ressemblent un peu aux raccourcis *.lnk mais ils ne contiennent aucune autre information et surtout, ils sont gérés directement au niveau du système de fichiers par l'OS, si bien que n'importe quel programme faisant un open sur un lien symbolique ouvrira en fait le fichier pointé et pas le lien symbolique lui-même, de façon complètement transparente et ce même si le programme n'est pas explicitement prévu pour.
C'est utile pour toutes sortes d'applications : pour créer des alias, mais également pour être automatiquement redirigé vers le fichier à utiliser à un moment donné (lequel peut changer), etc. On les utilise notamment dans /lib et /usr/lib pour rediriger une version d'une bibliothèque vers la bonne sous-version.
Les liens durs et les liens symboliques ont chacun leurs avantages et leurs inconvénients, mais une chose est certaine : quand on y a goûté, on n'a plus envie de revenir en arrière. Ceci est également vrai pour Unix en général, et pour les logiciels libres de façon plus globale encore. :-)