Forum Linux.débutant Recherche d'exercices a faire avec le SHELL Unix

Posté par . Licence CC by-sa.
Tags :
0
20
oct.
2016

voila pour le moment je suis le super tuto de openclassroom " reprenez le control grace a linux" tres complet et claire

il propose souvent de samuser avec les commande quil nous apprend pour les integrer, cest ce que je fais, mais jaimerais de vrais exercie pour debutant pour vraiment se prendre la main, je sais pas si vous voyez se que je veux dire

la par exemple je suis sur

touch
mkdir
head
teil
cat
less
cp
mv
rm
sudo

donc je mamuse a deplacer des fichier creer des dossier , etc…

cest sur que sa maide a memoriser les commande, les bon reflex ( TAB)
mais j'aimerais des exercice qui donne un vrai "but" a atteindre meme si je sais que ces comande son encore tres basiue, mais la n'est pas la question

en esperant que sa existe, merci d'avance

  • # Je ne sais pas

    Posté par . Évalué à 4.

    Je n’ai pas trop d’idée d’exercices concrets là comme ça mais une chose est sûre, tu devrais installer les pages de manuel en français et les lire de A-Z. Je ne te dis pas d’essayer de tout comprendre, si tu buttes sur un truc tu passes simplement à la suite, par contre ça te donnera une bonne vu d’ensemble de chaque programme.

    Ça pourra peut-être te donner des idées d’utilisation par rapport à ce que tu fais, ce que tu aimes… Et ça ne sera sûrement pas du temps perdu pour toi si tu veux vraiment apprendre le shell.

    Je te donnes ma liste de commande que tu devrais étudier, parce que bon… cat c’est pas bien passionnant.

    cp, rm, ln, find, grep, df, du, ls

    Tu peux aussi lire le manuel de bash (l’interpréteur) lui-même. Pareil, si tu as du mal sur un point ne t’obstine pas, tu y reviendras…

    La commande dont on se sert le plus souvent c’est la commande man :)

    Si tu n’as pas ce manuel en français, indique quelle distribution tu utilises on pourra peut-être te dire comment les installer.

    • [^] # Re: Je ne sais pas

      Posté par . Évalué à 0.

      Je te donne(S?????)
      Bon d'accord, c'est vrai que la proximité insidieuse du "te" dans cette construction complexe incite à la faute…

      LOL.

      • [^] # Re: Je ne sais pas

        Posté par . Évalué à 2.

        J’ai vraiment du mal avec la conjugaison, je fais des efforts croyez-moi :)

  • # La base de la base à ne pas faire : UUOC

    Posté par . Évalué à 4.

    Fais une recherche dessus … ;)

    • [^] # Re: La base de la base à ne pas faire : UUOC

      Posté par . Évalué à 2. Dernière modification le 20/10/16 à 20:00.

      J’ai failli dire qu’en plus d’être pas très passionnant cat était rarement utile en pensant à ça, c’est vrai qu’on l’utilise peu, mais je me suis abstenu, parce que quand même, cat permet de concatener des fichiers, ça peut servir parfois :)

      • [^] # Re: La base de la base à ne pas faire : UUOC

        Posté par . Évalué à 2.

        "cat -A file" : probablement une des options les plus utiles quand on travaille en milieu hétérogène. Ça permet de voir tous les caractères de controle, comme le \r présent dans les fins de lignes sous windows. Quand on transfert/édite des fichiers sous les 2 environnements, c'est vite indispensable.

  • # shell unix

    Posté par . Évalué à 0. Dernière modification le 20/10/16 à 20:12.

    merci jutilise ubuntu

    jai pas encore toucher a man, je reviendrais sur le forum une fois avoir fini le tuto dopen classroom, qui me parait pas mal, il couvre un peu tout, et en plus de sa je me suis procurer le livre parlez vous shell ? de thomas hugel,

    pareil que le tuto mais avec dautre info, donc commme tu dis je vais dabord tout lire , mais quand meme essayer de compredre chaque logique, et je reviendrai ici quand j'en saurai un peu plus ou pour parler un peu de cette comman MAN

    et cat je ne compte pas lutiliser, je lai juste appris cette aprem, alors cest sortis tout seul
    ce que jutilise le plus cest mkdir , lauch, mv , cp ,

    et la jattaque le chapitre sur nano. sa va commencer a etre interessant

    et jai bosser la fonction ln mais javoue ne pas vraiment avoir compri lutiliter davoir deux fichier liee , je comprend pas le but du concept

    • [^] # Re: shell unix

      Posté par . Évalué à 2.

      et jai bosser la fonction ln mais javoue ne pas vraiment avoir compri lutiliter davoir deux fichier liee , je comprend pas le but du concept

      ln te permet de créer un lien symbolique.
      Par exemple dans mon tuto sur zoneminder pour que zoneminder enregistre les informations sur un autre disque dur, plus tôt que de changer sa configuration, j'ai déplacé tout ses fichiers data et j'ai créé un lien symbolique avec "sudo ln -s /media/raidSSD/zoneminder /var/cache/zoneminder" à la place du dossier auquel zoneminder s'attend.
      Quand zoneminder tente d'accéder à "/var/cache/zoneminder" il est redirigé vers "/media/raidSSD/zoneminder" sans s'en apercevoir.
      Ce mécanisme est aussi utilisé pour passer à travers les anti trackers et anti pub sur internet.

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: shell unix

        Posté par . Évalué à 2.

        Pas spécialement un lien symbolique : ln sert d'abord à créer un lien dur, ce qui a d'ailleurs longtemps été la norme avant même l'existence des liens symboliques. On en retrouve une trace dans la man page de ln :

        CONFORMITÉ
        POSIX.2. Toutefois, POSIX.2 (1996) ne parle pas des liens symboliques. Ceux-ci ont été introduits par BSD, et n'existent pas dans Système V release 3 et antérieurs.

        Aujourd'hui, ils tombent un peu en désuétude et mériteraient justement d'être ré-enseignés proprement. Je pense que c'est précisément parce qu'ils n'existent pas sous Dos/Windows mais qu'a contrario, les raccourcis Windows ressemblent de loin aux liens symboliques que les gens ont fini par prendre l'habitude de n'utiliser que ceux-là.

        • [^] # Re: shell unix

          Posté par . Évalué à 2.

          Mwouais j'ai du mal avec cet argument populiste ;-) Je pense que c'est parce qu'il permet de pointer en dehors du filesystem qu'il est utilisé.

    • [^] # Re: shell unix

      Posté par . Évalué à 2.

      jai bosser la fonction ln mais javoue ne pas vraiment avoir compri lutiliter davoir deux fichier liee , je comprend pas le but du concept

      Peut-être que tu connais un peu Windows ? Tu peux voir un lien symbolique comme un raccourcis Windows…

      Par contre c’est plus puissant, évidemment :)

      Tu peux avoir N lien symboliques qui pointent vers un même programme. Ce même programme se comportera différemment selon le nom du lien symbolique qu’on a utilisé pour le lancer, par exemple :

      lrwxrwxrwx 1 root root 2 juil.  3  2015 /usr/bin/unxz -> xz
      lrwxrwxrwx 1 root root 2 juil.  3  2015 /usr/bin/xzcat -> xz
      

      On pourrait très bien n’avoir que le programme xz lui-même, et utiliser la bonne option selon que l’on veut lire décompresser un fichier .xz ou le décompresser seulement temporairement et afficher son contenu. C’est simplement plus pratique, plus simple à retenir.

      Ça peut servir d’avoir des noms plus simples. Si par exemple tu dois accéder souvent à un dossier qui se trouve à un emplacement avec un nom long et compliqué tu peux simplement faire un lien, par exemple dans ton $HOME, pour pouvoir simplement faire cd /home/bob/lelienversledossier, c’est plus simple à taper…

      • [^] # Re: shell unix

        Posté par . Évalué à 1.

        Par contre c’est plus puissant, évidemment :)

        N'empêche que ça n'est pas parfait:
        - on n'a pas moyen de retrouver les liens qui pointent vers un fichier sans faire de recherche exhaustive
        - un lien symbolique peut être invalide et n'empêche pas la suppression d'un fichier pointé.
        - un lien dur n'est jamais invalide mais ne peut pas sortir d'un filesystem
        - modèle de permission pas flexible.

        Pour ce qui est de ton te exemple il marche tout aussi bien avec des lien durs. D'ailleurs c'est généralement la solution retenue pour ce cas de figure, je ne comprends pas pourquoi xz ne le fait pas. Le lien dur a l'avantage que l'on voit directement le nombre de lien et d'empêcher la suppression du fichier tant qu'il reste un lien existant.

    • [^] # Re: shell unix

      Posté par . Évalué à 4.

      Bonjour,

      jai pas encore toucher a man

      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. :-)

  • # Sécurité

    Posté par . Évalué à 2.

    Si tu aimes la sécurité, tu peux craquer ton réseau wifi avec aircrack-ng et sa suite (si tu veux pas tricher, crée un réseau WEP plus facile/rapide à casser), puis tu peux faire un beau MITM avec ettercap-ng (voir etterfilter qui permet de faire des regex) et après ça injection de malware avec msf sur une fausse page lorsque la target tente de joindre facebook.

    Mes premières lignes de commande (nostalgie nostalgie) ^ ^

    Si non tu peux jouer avec grep et tes fichiers logs aussi : tu installes apache2 tu met une bête page web, tu postes des links sur twitter vers ta page puis avec cat /var/log/apache2/access.log | grep "seQueTuCherche" | grep -v "seQueTuNeVeuxPasVoir" tu t'amuse a observer les bots (astuces ici)

    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Sécurité

      Posté par . Évalué à 4.

      EEEEEH !!! Faut suivre, on a parlé de UUOC et tu nous en mets un beau. Faut pas donner de mauvaises habitudes aux débutants.

      • [^] # Re: Sécurité

        Posté par . Évalué à 3.

        Je mourerai moins con, merci :P

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: Sécurité

        Posté par . Évalué à 3. Dernière modification le 21/10/16 à 04:31.

        Bah faut arrêter avec ce dogme uuoc. En mode interactif. c'est un workflow plus naturel je trouve. Pour 2 raisons liées à l'utilisation de l'historique : 1) on fait un cat simple pour voir le contenu du fichier avant d'effectuer un traitement 2) garder la partie fixe (on change rarement le fichier lors de la mise au point d'un pipeline) à gauche (chez moi lorsque je reprends la dernière commande, mon curseur se trouve en fin de ligne).

        • [^] # Re: Sécurité

          Posté par . Évalué à 2.

          Oui. Par contre ça prend du sens quand tu boucles un million de fois de ne pas forker un processus à chaque fois…

          • [^] # Re: Sécurité

            Posté par . Évalué à 3.

            Si on en est à ce niveau d'optimisation peut-être vaudrait-il mieux commencer par questionner la pertinence de faire ce traitement par un script shell ?

            • [^] # Re: Sécurité

              Posté par . Évalué à 2.

              Bah, boucler sur des fichiers d'1 million de lignes sur lequel tu dois faire un traitement simple, ça se fait très bien en shell.

              • [^] # Re: Sécurité

                Posté par . Évalué à 1.

                Toutafé d'accord, mon point est que parler d'overhead de cat dans ce genre de situation est absurde. Rien que compiler une regex doit prendre plus de temps qu'un fork+exec. Un argument plus "valable" serait la copie dans un pipe, et encore ça me semble tout autant négligeable proportionnellement. Bref j'attends une démonstration avec des chiffres, bonne chance ;-)

                • [^] # Re: Sécurité

                  Posté par . Évalué à 2.

                  Bah, sur le principe, ouvrir un process qui va parser plus d'1 million de lignes, et qui va rien en faire, c'est ridicule.

                  Après j'ai pas de fichier d'1 million de lognes sous la main à traiter donc je ne peux pas mesurer.

  • # Morpion

    Posté par . Évalué à 3.

    Tu peux aussi essayer de faire des petits jeux, par exemple un morpion.
    Voici par exemple une petite ébauche faite à l'arrache:

        #! /bin/bash
        echo -e "1 2 3\n4 5 6\n7 8 9" > plateau
    
        cat plateau
    
        echo "Sur quelle case jouer ?"
        read position
        sed -i "s/$position/X/g" plateau
        cat plateau
    
        echo "Sur quelle case jouer ?"
        read position
        sed -i "s/$position/O/g" plateau
        cat plateau
    
        rm plateau

    Pour réussir à faire ce jeu, il te faudra aussi comprendre comment faire des boucles ainsi que des conditions.

  • # etonnant moyen d'apprendre

    Posté par . Évalué à 4.

    pour apprendre windows, on n'apprend pas (peut-etre à tort) à utiliser

    cd
    dir
    copy
    move
    mkdir
    rmdir
    del

    du coup j'ai un peu du mal à comprendre comment on peut apprendre à utiliser linux en commencant par apprendre

    cd
    ls
    cp
    mv
    mkdir
    rmdir
    rm

    pour moins cela fait partie des usages AVANCES, bien loin du debutant qui demarres sur un nouveau systeme.
    d'ailleurs mes parents ont utilisé Linux pendant plus de 10ans, sans jamais faire une ligne de commande

    • [^] # Re: etonnant moyen d'apprendre

      Posté par . Évalué à 3.

      pour apprendre windows, on n'apprend pas (peut-etre à tort) à utiliser

      Bah je suis assez vieux pour avoir dû apprendre ces commandes, à la maison comme à l’école, parce que les PC utilisaient DOS…

      pour moins cela fait partie des usages AVANCES, bien loin du debutant qui demarres sur un nouveau systeme.

      Apprendre qu’un ordinateur peut se programmer, qu’on peu lui faire enchaîner des actions sans avoir à taper sur son clavier ou utiliser une souris, ça permet de mieux comprendre les autres logiciels, y compris avec GUI… Et puis la base de l’informatique ça reste de traiter de l’information de la manière la plus automatisée possible…

      Je ne vois pas trop ce que pourrait représenter « apprendre Linux » s’il s’agit d’utiliser Gnome ou KDE de manière basique pour regarder des photos de chaton…

      C’est sûr qu’il y a plein de domaines autres, plus intéressant que le shell, mais je crois qu’il faut forcément en passer par là si tu veux t’intéresser à je ne sais pas, le web, XMPP, la programmation, etc… par exemple…

      Et ce n’est pas forcément propre à Linux, sous Windows aussi tu vas finir par mettre le nez dans, si ce n’est du cmd.exe ou du Powershell, du VisualBasic ou autre :)

      • [^] # Re: etonnant moyen d'apprendre

        Posté par . Évalué à 2.

        Bah je suis assez vieux pour avoir dû apprendre ces commandes, à la maison comme à l’école, parce que les PC utilisaient DOS…

        donc tu as appris à utiliser DOS
        pas à utiliser windows :p

        en plus on est vendredi, j'ai le droit

    • [^] # Re: etonnant moyen d'apprendre

      Posté par . Évalué à 4.

      mes parents ont utilisé Linux pendant plus de 10ans, sans jamais faire une ligne de commande

      Je sais que Linux est prêt pour le desktop.

    • [^] # Re: etonnant moyen d'apprendre

      Posté par . Évalué à 0.

      d'ailleurs mes parents ont utilisé Linux pendant plus de 10ans, sans jamais faire une ligne de commande

      puis un jour ils ont acheté une imprimante en promo et ils sont vite revenus au magasin acheter une licence windows. tout le monde la connaît cette histoire !

      • [^] # Re: etonnant moyen d'apprendre

        Posté par . Évalué à 5.

        euh … les miens ils sont pas stupide. Quand une imprimante ne marche pas, ils la ramènent là ou ils l'ont eue.

      • [^] # Re: etonnant moyen d'apprendre

        Posté par . Évalué à 3.

        ils ont demandé conseil à un "sage" pour prendre une imprimante qui fonctionnerait avec leur linux,
        car en cherchant sur le carton du produit, aucune n'avait marqué "compatible linux"

    • [^] # Re: etonnant moyen d'apprendre

      Posté par . Évalué à 2.

      Il a pas dit qu'il voulait apprendre Linux mais le "shell linux".

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.