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 Marotte ⛧ . É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 pseudovalide . É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 Marotte ⛧ . É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 totof2000 . Évalué à 4.
Fais une recherche dessus … ;)
[^] # Re: La base de la base à ne pas faire : UUOC
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 20 octobre 2016 à 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 jigso . É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 valarr . Évalué à 0. Dernière modification le 20 octobre 2016 à 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 EauFroide . Évalué à 2.
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 Obsidian . É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 :
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 benja . É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 Marotte ⛧ . Évalué à 2.
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 :
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 benja . Évalué à 1.
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 Obsidian . É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. :-)
# Sécurité
Posté par EauFroide . É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 totof2000 . É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 EauFroide . Évalué à 3.
Je mourerai moins con, merci :P
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Sécurité
Posté par benja . Évalué à 3. Dernière modification le 21 octobre 2016 à 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 Marotte ⛧ . É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 benja . É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 totof2000 . É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 benja . É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 totof2000 . É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 Dareg . Évalué à 3.
Tu peux aussi essayer de faire des petits jeux, par exemple un morpion.
Voici par exemple une petite ébauche faite à l'arrache:
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 NeoX . Évalué à 4.
pour apprendre windows, on n'apprend pas (peut-etre à tort) à utiliser
du coup j'ai un peu du mal à comprendre comment on peut apprendre à utiliser linux en commencant par apprendre
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 Marotte ⛧ . Évalué à 3.
Bah je suis assez vieux pour avoir dû apprendre ces commandes, à la maison comme à l’école, parce que les PC utilisaient DOS…
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 NeoX . Évalué à 2.
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 Marotte ⛧ . Évalué à 4.
Je sais que Linux est prêt pour le desktop.
[^] # Re: etonnant moyen d'apprendre
Posté par xcomcmdr . Évalué à 3.
"I know Kung Fu"
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: etonnant moyen d'apprendre
Posté par Obsidian . Évalué à 2.
« Our free trial of kung-fu has expired ! »
[^] # Re: etonnant moyen d'apprendre
Posté par pseudovalide . Évalué à 0.
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 totof2000 . É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 NeoX . É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 steph1978 . Évalué à 2.
Il a pas dit qu'il voulait apprendre Linux mais le "shell linux".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.