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. :-)
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à.
Il ne faudra pas s’attendre toutefois à ce que la parité fonctionnelle soit complètement respectée. Certains points cruciaux ne seront pas gérés, notamment les DRM pour la diffusion des contenus multimédias, et surtout la prise en charge des GPU pour les calculs 3D.
Sinon, pour le reste, j'en pense la même chose qu'à peu près tout le monde. Le fait d'avoir « activé sur demande » le plug-in me permet de mesurer combien sont rares les fois où j'en ai réellement besoin (surtout quand les pages qui le réclament ne le font que pour diffuser de la pub). Mais si elles sont rares, elles ne sont pas totalement inexistantes : certains sites (notamment des sites d'informations) persistent à diffuser leur vidéos en Flash et, bien sûr, je suis attaché à un certain nombre de jeux Flash assez bien réalisés qu'il serait dommage de ne pas pouvoir émuler d'une manière ou d'une autre.
Comme son nom l'indique, « touch » sert à « toucher au fichier ».
Autrement dit, cela sert à obtenir le même comportement qu'en faisant un « open » dessus, à l'exclusion de toute autre opération associée. Donc, formellement, ça crée le fichier s'il n'existe pas et ça met à jour les timestamps dans tous les cas.
Par défaut, la valeur des nouveaux timestamps correspondent à l'heure courant mais il est possible de passer une option pour antidater un fichier (ou le dater dans le futur), parce qu'il aurait été idiot de définir une autre commande rien que pour ce cas.
Si tu utilises « > fichier » à la place, non seulement ça ne marchera pas en zsh mais en plus ça tronquera ton fichier s'il existe déjà (= le videra entièrement).
une de mes connaissances utilise un système embarqué maison pour faire de la domotique. Son problème est que de temps en temps son système ne communique plus avec UN équipement
Avez-vous une idée de ce qui pourrait résister à un reboot mais pas à un down puis up ? Car là je bloque.
À vue de nez un conflit d'adresse. Deux machines doivent partager la même adresse à un moment donné. Ça arrive de temps en temps quand tout un réseau est fait pour utiliser le DHCP mais que l'on a oublié qu'une machine a été configurée dans son coin avec une adresse statique…
ou sinon justifier un peu pourquoi ton choix s'est porté vers cette distribution…
Avec un peu de recherche, on tombe sur ça : http://www.linuxmao.org/AV+Linux
Donc, c'est une distribution de Linux orientée musique et ça justifie donc pleinement son choix.
Maintenant, ça n'explique pas pourquoi « ses comptes ne sont plus reconnus systématiquement ».
La seule fois où ça m'est arrivé avec une machine aux comptes locaux (pas de LDAP ou assimilé) était sous Fedora 20 avec une Gnomerie/Lennarterie/Freedesktoperie : GDM perdait sa connexion avec DBus pour une raisons inconnue et c'était par ce biais qu'il authentifiait les utilisateurs, même quand la session était ouverte, mais l'écran verrouillé. Et comme toutes les touches de contrôles (Ctrl-Alt-F1, Ctrl-Alt-Backspace) étaient désactivées « pour le bien de l'utilisateur » (y compris SysRq), il n'y avait aucun moyen de s'en sortir. La seule façon que j'ai trouvée pour ne pas perdre les données qu'il y avait derrière était de faire un ssh depuis une machine tierce et d'envoyer dbus-send --print-reply --type=method_call --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.UnlockSessions
Par contre, il est clair que ce cas de figure est exceptionnel, expérimental, et purement inadmissible. Mais surtout, en tout état de cause, ça revient au redémarrage. Il n'y a aucune raison d'avoir à réinstaller.
Pouvez vous m'aider SVP car je pense que je vais revenir a windows,que l'on dit instable et merdique mais qui demarre toujours …lui !!
« Démarre toujours » ? Tu t'emportes un peu là ! En presque 20 ans, je n'ai JAMAIS eu à réinstaller un Linux à cause d'une panne. Pas une fois. Il y a bien eu quelques dysfonctionnements occasionnels mais rien que je n'aie pu réparer. J'aimerais pouvoir en dire autant de Windows. Et même quand Windows démarre, on sait à quel point il peut devenir inutilisable au bout d'un certain temps lui aussi.
On peut t'aider mais il nous faut plus de détails : nous ne sommes pas derrière ton écran pour voir ce que tu vois.
Perso, soit il n'existe pas et il faut qu'on se débrouille seuls, soit il existe et il mérite juste une condamnation pour non assistance à personnes en danger.
S'il revient, il va surtout nous dire : « alors je peux pas vous laisser seuls deux petits millénaires sans que vous vous foutiez sur la gueule, bande de petits salopards ? » :-)
Un grand merci, à mon tour (et un peu tard), pour ce journal de qualité qui me révèle l'étendue de mon ignorance dans le domaine alors même que j'utilise des logiciels de versioning comme tout le monde et de longue date (en ayant commencé avec CVS).
Cela dit :
Reste un petit goût amer, comment un produit si efficace peut-il avoir une interface en ligne de commande aussi inconsistante, imprévisible sans qu'on l'ait remis à plat ?
Vous aussi, ça vous défrise de faire git checkout sur un nom de branche pour l'activer ?
Vous aussi, vous vous demandez pourquoi il faut faire un git checkout -b pour créer une branche et un git branch -d pour la supprimer ?
Pas vraiment puisqu'en réalité, ce ne sont pas les commandes officielles pour faire cela mais des raccourcis bien pratiques. Et si tout le monde les prend en exemple, c'est bien parce que les développeurs les utilisent et qu'ils ont une raison d'être.
L'interface de Git, c'est un peu comme le jeu « Pyramide ». Personne ne comprend de quoi il s'agit, jusqu'au moment où on explique qu'il s'agit simplement de trouver des mots en rapport avec d'autres dans un contexte donné (celui-là même qui manque en général). Du coup, les commandes servent chacune à gérer un thème en particulier, et ont un comportement par défaut :
git branch → Affiche les branches existantes ;
git branch nomdebranche → Crée une branche ;
git branch -f nomdebranche → Force la création d'une branche (sémantique habituelle de -f) ;
git branch -d nomdebranche → Efface une branche (delete) ;
Présenté comme cela, ça se tient. Les options « -b » et « -B » de checkout permettent ensuite de faire cela à la volée, parce qu'on fait rarement l'un sans l'autre.
J'avais essayé ce tutoriel : http://pcottle.github.io/learnGitBranching/ bien pratique pour se faire la main quand on part de rien (Je n'arrive plus à savoir, malheureusement, si je l'ai découvert ici, sur la tribune ou en cherchant des tutoriels par moi-même…).
Cela dit, j'admets que cela concerne uniquement « branch » et que l'on pourrait disserter longtemps sur la pertinence du reste du langage de git.
Vous aussi vous avez bookmarké la moitié de Stack Overflow et vous collectionnez les cheat cheet sur Git ? …
Effectivement, j'ai posté trop vite. Ça me paraissait évident quand j'ai posté alors que dans le contexte, j'aurais pu tout-à-fait le faire aussi… :-\
Méa culpa donc, mais attention quand même à la façon de spécifier les arguments. Autant « cd rep ; ln ../* . » donne de bons résultats, autant « ln -s * rep/ » me produit des liens symboliques qui s'auto-référencent. Sans compter que dans les deux cas, l'un de ces liens concerne le répertoire « rep » lui-même…
Hmm. En fait, c'est moi le noob, visiblement. Sylvain a raison (juste au dessus), la commande « ln » peut elle aussi prendre n arguments. Par contre, attention à la façon dont on les spécifie.
Pas tant que ça, parce que « cp » et « mv » peuvent attendre un nombre arbitraire (supérieur à zéro) de fichiers sources, pourvu que le dernier soit un répertoire, ce qui n'est pas valable pour « ln ».
En plus, nombreux sont les cas ou la destination précède la source : la création d'une archive par exemple (*.tar ou autre) et tous les cas où l'on utilise une lvalue avant un « = », en particulier avec les alias du shell.
Sauf que ce faisant, tu ne crées pas un deuxième utilisateur omnipotent mais un homonyme du premier, qui partagera donc les mêmes UID/GID. Et bizarrement, quand ils seront résolus, tous les fichiers que tu auras créé auront pour propriétaire « root » et pas « monuser .
Je voudrais créer un utilisateur par défaut qui serait toujours root avec des droits SU ? Est-ce possible et comment faire ?
En une phrase : C'est une ânerie ! Et on insiste parce que c'est une erreur assez courante.
Le « root » d'un système Unix n'est pas comparable à « l'administrateur » de Windows. Peux-tu nous expliquer pourquoi tu veux faire cela ? Il y a 99 chances sur 100 pour que la meilleure solution à apporter à ton problème soit autre chose.
Par contre, pour l'avoir fait récemment sur un vieux portable à base de Centrino, je confirme que ça marche avec 512 Mo (après ajout d'une barrette, que l'on avait installé il y a déjà un bon bout de temps). Pour le prix, l'utilisateur a un bureau LXDE, un client mail Sylpheed et un Firefox récent qui tourne correctement sans que ce soit insupportable. Le bureau permet d'afficher ses fichiers dessus normalement et il me semble que même la suite bureautique est utilisable. J'arrive même à prendre la main dessus avec un VNC ou un SSH sans difficulté.
Il faut quand même se souvenir qu'il n'y a pas si longtemps, ça représentait beaucoup de mémoire et on pensait pouvoir tout faire tourner sur ce genre de machine quand on en avait une.
Par contre, ce n'est même pas la peine d'essayer avec GNOME.
Si tu prends un seul meuble, non. Mais même sans se reconvertir en grossiste, et spécialement sur ce produit, si tu en prends en deuxième, tu doubles ton rayon d'action acceptable. Il faut avoir envie de voyager mais en faisant un achat groupé entre trois ou quatre personnes et en commandant chacun deux ou trois produits pour équiper son salon ou sa cuisine, ça redevient vite intéressant, surtout si on n'envoie qu'une seule personne faire le voyage et que les autres attendent tranquillement que leurs paquets arrivent sur le bas de leur porte… :-)
Surtout qu'en se débrouillant bien, on peut faire un plein à l'étranger aussi pour le voyage retour et faire là aussi de substantielles économies.
Et la différence de prix est loin d'être anecdotique.
600 - 350 = 250 € !
À ce prix-là, même quand on habite en région parisienne, c'est presque rentable de prendre sa voiture pour aller faire ses courses à l'étranger et revenir !
[^] # 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. :-)
[^] # Re: shell unix
Posté par Obsidian . En réponse au message Recherche d'exercices a faire avec le SHELL Unix. É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: la fin des jeux en flash et des videos de chatons ?
Posté par Obsidian . En réponse au journal Flash info. Évalué à 5.
Ben, de toutes façons :
Sinon, pour le reste, j'en pense la même chose qu'à peu près tout le monde. Le fait d'avoir « activé sur demande » le plug-in me permet de mesurer combien sont rares les fois où j'en ai réellement besoin (surtout quand les pages qui le réclament ne le font que pour diffuser de la pub). Mais si elles sont rares, elles ne sont pas totalement inexistantes : certains sites (notamment des sites d'informations) persistent à diffuser leur vidéos en Flash et, bien sûr, je suis attaché à un certain nombre de jeux Flash assez bien réalisés qu'il serait dommage de ne pas pouvoir émuler d'une manière ou d'une autre.
[^] # Re: À quand une émission de téléréalité ?
Posté par Obsidian . En réponse au journal "Meilleur dev de France" ?. Évalué à 4.
Pas sûr.
Et c'est bien ça le plus triste, d'ailleurs…
[^] # Re: shell touch
Posté par Obsidian . En réponse au journal La sortie de `ls` vient de changer. Évalué à 4.
Comme son nom l'indique, « touch » sert à « toucher au fichier ».
Autrement dit, cela sert à obtenir le même comportement qu'en faisant un « open » dessus, à l'exclusion de toute autre opération associée. Donc, formellement, ça crée le fichier s'il n'existe pas et ça met à jour les timestamps dans tous les cas.
Par défaut, la valeur des nouveaux timestamps correspondent à l'heure courant mais il est possible de passer une option pour antidater un fichier (ou le dater dans le futur), parce qu'il aurait été idiot de définir une autre commande rien que pour ce cas.
Si tu utilises « > fichier » à la place, non seulement ça ne marchera pas en zsh mais en plus ça tronquera ton fichier s'il existe déjà (= le videra entièrement).
# Conflit d'adresse ?
Posté par Obsidian . En réponse au message Coupure de connexion réseau. Évalué à 9.
À vue de nez un conflit d'adresse. Deux machines doivent partager la même adresse à un moment donné. Ça arrive de temps en temps quand tout un réseau est fait pour utiliser le DHCP mais que l'on a oublié qu'une machine a été configurée dans son coin avec une adresse statique…
[^] # Re: Ras le bol des couteaux
Posté par Obsidian . En réponse au message super marre de Linux !!!!. Évalué à 5.
Avec un peu de recherche, on tombe sur ça : http://www.linuxmao.org/AV+Linux
Donc, c'est une distribution de Linux orientée musique et ça justifie donc pleinement son choix.
Maintenant, ça n'explique pas pourquoi « ses comptes ne sont plus reconnus systématiquement ».
La seule fois où ça m'est arrivé avec une machine aux comptes locaux (pas de LDAP ou assimilé) était sous Fedora 20 avec une Gnomerie/Lennarterie/Freedesktoperie : GDM perdait sa connexion avec DBus pour une raisons inconnue et c'était par ce biais qu'il authentifiait les utilisateurs, même quand la session était ouverte, mais l'écran verrouillé. Et comme toutes les touches de contrôles (Ctrl-Alt-F1, Ctrl-Alt-Backspace) étaient désactivées « pour le bien de l'utilisateur » (y compris SysRq), il n'y avait aucun moyen de s'en sortir. La seule façon que j'ai trouvée pour ne pas perdre les données qu'il y avait derrière était de faire un ssh depuis une machine tierce et d'envoyer dbus-send --print-reply --type=method_call --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.UnlockSessions
Par contre, il est clair que ce cas de figure est exceptionnel, expérimental, et purement inadmissible. Mais surtout, en tout état de cause, ça revient au redémarrage. Il n'y a aucune raison d'avoir à réinstaller.
« Démarre toujours » ? Tu t'emportes un peu là ! En presque 20 ans, je n'ai JAMAIS eu à réinstaller un Linux à cause d'une panne. Pas une fois. Il y a bien eu quelques dysfonctionnements occasionnels mais rien que je n'aie pu réparer. J'aimerais pouvoir en dire autant de Windows. Et même quand Windows démarre, on sait à quel point il peut devenir inutilisable au bout d'un certain temps lui aussi.
On peut t'aider mais il nous faut plus de détails : nous ne sommes pas derrière ton écran pour voir ce que tu vois.
[^] # Re: Dieu n'existe pas
Posté par Obsidian . En réponse au journal Paris sous les balles. Évalué à 4.
S'il revient, il va surtout nous dire : « alors je peux pas vous laisser seuls deux petits millénaires sans que vous vous foutiez sur la gueule, bande de petits salopards ? » :-)
[^] # Re: Mécontent de PA
Posté par Obsidian . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 5.
Une LFS, bien sûr ! :-)
(→[])
[^] # Re: La réponse 4
Posté par Obsidian . En réponse au sondage Combien de fois répondez-vous à un sondage donné ?. Évalué à 6.
e) Je m'appelle Sergio. Personne ne va plus vite que Sergio !
[^] # Re: Une autre ! Une autre ! Bon, d'accord.
Posté par Obsidian . En réponse au journal Testez votre intuition. Évalué à 4.
Ce qui ferait au total 1200 kilomètres en 8 heures, soit 150 kilomètres par heure, sur les 200 pourtant attendus.
[^] # Re: Euh…
Posté par Obsidian . En réponse au message question sur sed et /dev/urandom. Évalué à 3.
Ctrl+V Ctrl+O, probablement.
Sinon
echo -e "\033c"marche bien aussi.[^] # Re: Pocket
Posté par Obsidian . En réponse au journal Firefox 38.0.5 : bien plus qu'une version de maintenance. Évalué à 1.
Aïe !
# Git branch
Posté par Obsidian . En réponse au journal Git a fêté ses 10 ans hier .... Évalué à 3. Dernière modification le 21 mai 2015 à 13:32.
Un grand merci, à mon tour (et un peu tard), pour ce journal de qualité qui me révèle l'étendue de mon ignorance dans le domaine alors même que j'utilise des logiciels de versioning comme tout le monde et de longue date (en ayant commencé avec CVS).
Cela dit :
Pas vraiment puisqu'en réalité, ce ne sont pas les commandes officielles pour faire cela mais des raccourcis bien pratiques. Et si tout le monde les prend en exemple, c'est bien parce que les développeurs les utilisent et qu'ils ont une raison d'être.
L'interface de Git, c'est un peu comme le jeu « Pyramide ». Personne ne comprend de quoi il s'agit, jusqu'au moment où on explique qu'il s'agit simplement de trouver des mots en rapport avec d'autres dans un contexte donné (celui-là même qui manque en général). Du coup, les commandes servent chacune à gérer un thème en particulier, et ont un comportement par défaut :
git branch → Affiche les branches existantes ;
git branch nomdebranche → Crée une branche ;
git branch -f nomdebranche → Force la création d'une branche (sémantique habituelle de -f) ;
git branch -d nomdebranche → Efface une branche (delete) ;
Présenté comme cela, ça se tient. Les options « -b » et « -B » de checkout permettent ensuite de faire cela à la volée, parce qu'on fait rarement l'un sans l'autre.
J'avais essayé ce tutoriel : http://pcottle.github.io/learnGitBranching/ bien pratique pour se faire la main quand on part de rien (Je n'arrive plus à savoir, malheureusement, si je l'ai découvert ici, sur la tribune ou en cherchant des tutoriels par moi-même…).
Cela dit, j'admets que cela concerne uniquement « branch » et que l'on pourrait disserter longtemps sur la pertinence du reste du langage de git.
Je suis obligé de dire que oui. :-)
[^] # Re: Et à coté de ça
Posté par Obsidian . En réponse au journal L'Armée Française et ses logiciels, bis repetita.... Évalué à 9.
Désirs d'avenir : 41800 € en 2010
->[]
[^] # Re: cp
Posté par Obsidian . En réponse au journal lns: ln -s pour les étourdis. Évalué à 2.
Effectivement, j'ai posté trop vite. Ça me paraissait évident quand j'ai posté alors que dans le contexte, j'aurais pu tout-à-fait le faire aussi… :-\
Méa culpa donc, mais attention quand même à la façon de spécifier les arguments. Autant « cd rep ; ln ../* . » donne de bons résultats, autant « ln -s * rep/ » me produit des liens symboliques qui s'auto-référencent. Sans compter que dans les deux cas, l'un de ces liens concerne le répertoire « rep » lui-même…
[^] # Re: cp
Posté par Obsidian . En réponse au journal lns: ln -s pour les étourdis. Évalué à 2.
Hmm. En fait, c'est moi le noob, visiblement. Sylvain a raison (juste au dessus), la commande « ln » peut elle aussi prendre n arguments. Par contre, attention à la façon dont on les spécifie.
[^] # Re: cp
Posté par Obsidian . En réponse au journal lns: ln -s pour les étourdis. Évalué à 8.
Pas tant que ça, parce que « cp » et « mv » peuvent attendre un nombre arbitraire (supérieur à zéro) de fichiers sources, pourvu que le dernier soit un répertoire, ce qui n'est pas valable pour « ln ».
En plus, nombreux sont les cas ou la destination précède la source : la création d'une archive par exemple (*.tar ou autre) et tous les cas où l'on utilise une lvalue avant un « = », en particulier avec les alias du shell.
[^] # Re: 0:0
Posté par Obsidian . En réponse au message Devenir root. Évalué à 4.
Sauf que ce faisant, tu ne crées pas un deuxième utilisateur omnipotent mais un homonyme du premier, qui partagera donc les mêmes UID/GID. Et bizarrement, quand ils seront résolus, tous les fichiers que tu auras créé auront pour propriétaire « root » et pas « monuser .
# Ânerie
Posté par Obsidian . En réponse au message Devenir root. Évalué à 4.
En une phrase : C'est une ânerie ! Et on insiste parce que c'est une erreur assez courante.
Le « root » d'un système Unix n'est pas comparable à « l'administrateur » de Windows. Peux-tu nous expliquer pourquoi tu veux faire cela ? Il y a 99 chances sur 100 pour que la meilleure solution à apporter à ton problème soit autre chose.
Bon courage.
[^] # Re: Ah les MàJ de Windows.
Posté par Obsidian . En réponse au journal La blague. Évalué à 8.
Ça, c'est si tu as de la chance. Si ça avait été un concours de l'éducation nationale, ça aurait été « ah, dommage ! Tant pis pour vous. ».
[^] # Re: plus simple
Posté par Obsidian . En réponse à la dépêche Pourquoi ne faut-il absolument pas brancher ses appareils USB sur des bornes publiques ?. Évalué à 8. Dernière modification le 09 mars 2015 à 12:59.
Le pont diviseur, en l'occurrence… ^ ^
[^] # Re: A essayer
Posté par Obsidian . En réponse au message Quel version de linux sur ordinateur de 224 RAM. Évalué à 2.
Par contre, pour l'avoir fait récemment sur un vieux portable à base de Centrino, je confirme que ça marche avec 512 Mo (après ajout d'une barrette, que l'on avait installé il y a déjà un bon bout de temps). Pour le prix, l'utilisateur a un bureau LXDE, un client mail Sylpheed et un Firefox récent qui tourne correctement sans que ce soit insupportable. Le bureau permet d'afficher ses fichiers dessus normalement et il me semble que même la suite bureautique est utilisable. J'arrive même à prendre la main dessus avec un VNC ou un SSH sans difficulté.
Il faut quand même se souvenir qu'il n'y a pas si longtemps, ça représentait beaucoup de mémoire et on pensait pouvoir tout faire tourner sur ce genre de machine quand on en avait une.
Par contre, ce n'est même pas la peine d'essayer avec GNOME.
[^] # Re: Meme constat
Posté par Obsidian . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 4. Dernière modification le 26 février 2015 à 14:41.
Si tu prends un seul meuble, non. Mais même sans se reconvertir en grossiste, et spécialement sur ce produit, si tu en prends en deuxième, tu doubles ton rayon d'action acceptable. Il faut avoir envie de voyager mais en faisant un achat groupé entre trois ou quatre personnes et en commandant chacun deux ou trois produits pour équiper son salon ou sa cuisine, ça redevient vite intéressant, surtout si on n'envoie qu'une seule personne faire le voyage et que les autres attendent tranquillement que leurs paquets arrivent sur le bas de leur porte… :-)
Surtout qu'en se débrouillant bien, on peut faire un plein à l'étranger aussi pour le voyage retour et faire là aussi de substantielles économies.
[^] # Re: Meme constat
Posté par Obsidian . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 7.
600 - 350 = 250 € !
À ce prix-là, même quand on habite en région parisienne, c'est presque rentable de prendre sa voiture pour aller faire ses courses à l'étranger et revenir !