Ubuntu-fr

Salut @loutch,

  Peux-tu nous partager ton script permettant de connaître le morceau en cours de lecture, s'il te plait ?
Tu as réussi à détecter le changement de titre je te laisse donc la suppression de l'image du morceau précédent.

D'après ce que je comprend ce qui te pose problème c'est la récupération de la pochette via google image.

La réponse courte

titre=$(head -1 artiste_titre.txt)
lienMiniature=$(wget -U'Googlebot-Image/1.0' -qO - "www.google.fr/search?q=$titre\&tbm=isch" | perl -pe 's!.*?<img .*?src="([^"]*)".*!$1!')
wget -qO miniatureGoogleImage $lienMiniature

La réponse longue

[HS]Pour information le moyen le plus sûr et souvent le plus simple pour interroger des services distants comme google image est d'utiliser les interfaces de programmation mis à disposition par les propriétaires des services.
A savoir que ces interfaces sont souvent utilisables avec une clé gratuite ou non. Pour exemple : http://stackoverflow.com/questions/5338 … search-api
Si tu veux faire des recherches là-dessus l'acronyme anglais est API, on parle aussi pour ces cas de web services.[/HS]

Cependant la solution ci-après utilise directement les pages web, les données souhaitées sont isolées via l'analyse des sources HTML de ces pages.
Leur récupération s'effectue à l'aide d'expressions rationnelles (toujours pour des recherches l'abréviation anglaise est regex).
Cela a pour inconvénient d'être extrêmement sensible aux modifications des sources HTML et de récupérer toute la page pour une seule information.

J'utilise ici les options longues alors que la réponse courte utilise les courtes et même un raccourci -1 de head qui n'est pas une option standard la "bonne" syntaxe est head -n 1.
Les options longues sont préférables dans les scripts car plus compréhensible pour un travail ultérieur.

# Récupération de ton travail :)
titre=$(head --lines=1 artiste_titre.txt)

# Affection du lien de la 1ere miniature de google image à la variable lienMiniature
# Utilisation de wget avec un agent utilisateur robot --user-agent 'Googlebot-Image/1.0' : la page téléchargée est plus légère
# --quiet : silencieux, pas d'affichage par wget
# --output-document=- : document dans lequel sont sauvés les sources HTML téléchargées.
# - : ici la page étant un résultat intermédiaire il n'est pas nécessaire de la sauver son contenu est envoyé en flux à la commande suivant le tube
# | : un tube permet de traiter le résultat d'une commande avec la commande qui suit le tube
# \ : ici notre tube est suivi de \ afin de taper la commande de traitement du résultat sur une nouvelle ligne (de même & est échappé)
lienMiniature=$(wget --user-agent 'Googlebot-Image/1.0' --quiet --output-document=- "www.google.fr/search?q=${title}\&tbm=isch" |\

# la commande suivant le tube est celle-ci
# filtre pour ne récupérer que le lien de la première image
# .*?<img : tout jusqu'à la première balise img
# .*?src=" : tout jusqu'au premier attribut src (ici celui de la première balise img)
# ([^"]*)" : tout ce qui n'est pas un " jusqu'au prochain " = récupération du lien
# .* : d'autres caractères après sont autorisées
# $1 : premier et unique élément récupéré
perl -pe 's!.*?<img .*?src="([^"]*)".*!$1!')

# Téléchargement silencieux vers le fichier miniatureGoogleImage depuis le lien précédement récupéré
wget --quiet --output-document="miniatureGoogleImage" ${lienMiniature}

Si tu veux télécharger l'image cible et non la miniature générée par google une solution possible :

titre=$(head --lines=1 artiste_titre.txt)
# Ajout d'un compteur si jamais tu veux faire défiler plusieurs images
count=1

imageLink=$(wget --user-agent 'Firefox/38.0' -qO - "https://www.google.fr/search?q=${titre}\&tbm=isch" |\
sed 's/</\n</g' | grep "a href=\"http://www.google.fr/imgres?imgurl=" | head --lines=${count} |\
sed 's!.*http://www.google.fr/imgres?imgurl=\([^&]*\).*!\1!')
wget -quiet --output-document="googleImage" $imageLink

Ici j'utilise sed qui est l'utilitaire des substitutions (à savoir que le "tout" (comprendre .*) de sed ne prend pas en charge les accents).

[HS]D'ailleurs avec les accents viennent les problèmes d'encodage. Pour les caractères accentués et autres caractères spécifiques le problème peut être gérer via l'utilisation de la codification unicode ou par des mécanismes d'échappement.
Pour interpréter les unicodes : echo -e (celui inclus dans bash pas le /bin/echo)
Un mécanisme d'échappement de Perl :
perl -e 'use URI::Escape; print uri_escape($ARGV[0]);' "$variableATraiter"
perl -e 'use URI::Escape; print uri_unescape($ARGV[0]);' "$variableATraiter"[/HS]

Bonne soirée

Bonjour @zephyre,

Comme indiqué précédement, même si cette réponse peut sembler être une manière d'éluder la question, @kamaris : "la meilleure méthode est celle qui te convient", celle avec laquelle tu seras à l'aise. Le fait d'être à l'aise amène de la performance et du plaisir. Une méthode qui ne t'apporte aucun plaisir est difficile à garder sur le long terme.

Comme le dit @ssdg, ça dépend en partie de la technologie ciblée puisque certains outils sont dédiés à des technologies. Il peut parfois être préférable d'utiliser un outil plus adapté même si l'on n'en a pas l'habitude.

Sachant que l'utilisation d'un nouvel outil est profitable s'il remplit mieux un besoin que tes outils précédents et soit :
- qu'il demande très peu d'apprentissage,
- que ta fréquence d'utilisation de ce nouvel outil rend l'investissement dans l'apprentissage intéressant.

Ma préférence est l'utilisation de plusieurs outils mais cela est effectivement plus complexe/pénible au moins au début.
Ceci étant tout à fait compréhensible puisque l'intégration de plusieurs outils dans un environnement de développement a justement pour but de simplifier l'usage.

Un IDE permet d'avoir plusieurs outils dans une interface homogène et pré-configurés pour fonctionner ensemble. Une partie de la complexité technique peut-être diminuée grâce à l'utilisation d'un IDE. Cependant c'est justement cela qui, d'expérience, est désagréable: les comportements automatiques que l'on ne comprend pas. L'apport de l'IDE va t'aider dans la majorité des cas mais peut te faire perdre du temps (beaucoup) parfois à cause d'un traitement automatique non souhaité.
Cela est également vrai en dehors des IDE par exemple dans les frameworks. Et ce n'est pas pour cela qu'il ne faut pas utiliser de frameworks, les briques d'abstraction permettent de s'affranchir de certaines problématiques pour avancer. Mais quand ces briques plantent il faut bien descendre pour comprendre leur fonctionnement afin de solutionner le problème.

Le précepte Unix : 1 outil 1 tâche. Dans cette approche il faut connaître plusieurs outils et leurs options, c'est donc potentiellement plus fastidieux. Les outils étant plus simples même lorsqu'ils ont des comportements automatiques, ils sont généralement plus simples à comprendre. Je vois principalement trois avantages à ce fonctionnement :
- changer une brique entraîne peu d'impact sur l'environnement global
- pouvoir combiner les outils pour répondre à de nombreux besoins
- utiliser en partie les mêmes outils que sur les environnements post-développement.

Il a toujours des avantages et des inconvénients à une méthode, or nous avons la chance que ces deux méthodes soient non exclusives.

En entreprise, j'ai principalement vu l'utilisation d'un IDE imposé au moins aux débutants. Cela permet d'avoir des postes homogènes, ce qui est plus simple pour l'entre-aide. La diminution de la complexité peut-être une bonne chose quand on débute.
Une fois que les personnes sont plus autonomes, elles peuvent choisir leurs outils si cela n'engendre pas de support particulier.

J'ai souvent vu les plus expérimentés continuer à utiliser l'IDE par habitude et donc efficacité mais en y ajoutant de plus en plus d'outils autour. Notamment pour l'aspect spécialisation des outils. Mais également remplacer l'usage d'outils intégrés par des lancements hors IDE (potentiellement de ces mêmes outils mais sans la surcouche IDE) afin d'éviter les automatismes non souhaités. Cela permettant par exemple d'être plus proche (voire à l'identique) du fonctionnement de la plateforme d'intégration continue.

PS: tu es bien motivé car vim est certainement l'un des utilitaires Unix les plus complexes à prendre en main.

Bonsoir bergeronnette,

Comme tu le sais tes questions sont extrêmement larges et complexes, elles ont donc énormément de réponses possibles.

J’ai l’impression que tu te demandes d’où sa sort.

Une réponse très vulgarisée peut être la suivante :

• tout d’abord le courant électrique qui fournit le signal numérique, absent 0 ou présent 1

• ensuite l’électronique permettant de faire notamment des portes logiques OU, ET, NON… voir entre autres l’algèbre de Boole, à ce niveau il est déjà possible de faire de la programmation « matérielle »

• les portes logiques ont ensuite été miniaturisées et améliorées notamment à travers les transistors, ces composants entre autres ont permis de faire les micro-processeurs. A ce niveau les langages de programmation, directement compris car gravés physiquement dans le processeur, sont nommés Assembleur. Il y a donc plusieurs Assembleurs selon les différents processeurs

• à partir de là beaucoup de langages compilés ont vu le jour, je ne citerais que le plus utilisé aujourd’hui C, ces langages utilisent un compilateur, pour simplifier, initialement coder en Assembleur. Le code produit par le développeur n’est donc pas directement celui exécuté par le processeur

• ensuite, pour simplifier, des langages interprétés sont apparus, par exemple toujours dans les plus utilisés le Python. Ce dernier comme beaucoup de langages interprétés d’aujourd’hui utilise un interpréteur coder en C.

1) Les commandes sont-elle construites avec un langage prédéfini ?

Comme tu l’as compris il n’y a pas en soit un langage « prédéfini » mais plusieurs niveaux d’abstraction. Pour reprendre l’exemple du Python il se base sur un interpréteur codé en C, interpréteur qui est lui même compilé en Assembleur pour être utilisable par la machine.

Si toutes fois on doit considérer des langages prédéfinis, il s’agit de ceux gravés dans les processeurs donc les Assembleurs.

Pour reprendre l’exemple de ta question mkdir est codé en C.

2) Comment ce code est connu par la machine et son OS ?

Le C étant le langage créé pour réécrire Unix et donc une grosse partie du système de base de GNU/Linux, il est connu de ce dernier. Les programmes simples compilés à partir du C n’ont besoin de rien puisqu’ils sont compréhensibles par le processeur (niveau machine). Cependant un programme utilise généralement des morceaux de code déjà existants afin de ne pas coder perpétuellement les mêmes fonctionnalités. Ces codes sont regroupés dans ce qu’on appelle des librairies. Et pour le cas de C sa librairie standard, autrement dit celle fournie avec le langages que tous développeurs C utilisent, est présente dans tous les systèmes d’exploitation que je connais.
Par ailleurs les langages interprétés sont connus par la machine seulement si un interpréteur est installé (niveau OS).

3) Quand je lis que ce langage a été créé par …, qu'est-ce que cela signifie ?

Le C a été créé par Dennis Ritchie et Ken Thompson, cela signifie qu’ils ont été les fondateurs du langages. Ceux sont eux qui ont conçu le langage C et développé en Assembleur le premier compilateur C.

Ces fondateurs d’un langage écrivent à la fois les spécifications de la langue formelle qu’ils veulent rendre compréhensible aux développeurs et à la machine et l’implémentation de ce langage via un compilateur ou un interpréteur.

A noter un fait assez fréquent, considérer parfois comme un aboutissement d’un langage, est de coder le compilateur/interpréteur dans le langage lui-même. Par exemple il existe un interpréteur Python codé en Python cela n’est possible qu’après la mise en place d’une première version de Python codé dans un langage déjà compréhensible par la machine.

Bonjour,

Il est également possible d'utiliser les expressions régulières étendues avec l'option -E, auquel cas il ne faut plus protéger les parenthèses capturantes.
En revanche d'autres caractères se retrouvent avec une signification comme les accolades qu'il faut donc protéger.

sed -i -Ee 's/(debut_path_qui_ne_change_pas)[-a-zA-Z_.\/0-9]*(\$\{year\})/\1'"${var_path_new}"'\2/g' fichier

A noter l'option -e n'est pas obligatoire mais à l'avantage d'augmenter la portabilité. De plus si plusieurs scripts sont passés à sed l'option devient indispensable.
De même délimiter les variables via ${} est une bonne pratique.

Une autre solution assez classique pour travailler avec des expressions régulières est perl qui utilise des regex encore plus riches :

perl -i -pe 's/(debut_path_qui_ne_change_pas)[-\w.\/\d]*(\$\{year\})/\1'"${var_path_new}"'\2/g' fichier

Bonjour,

Le répertoire /root/ est le home par défaut de l'administrateur. Il ne contient généralement que des fichiers de configuration qui sont pour la majorité cachés (commencant par un .).
Sous Ubuntu le compte root est désactivé au profit de l'utilisation de sudo. Le répertoire /root/ a donc encore moins de possibilité d'être modifié.

Pour y avoir accès il te faut donc les droits d'administration. L'élévation de privilège s'effectue avec la commande sudo.
Dans ton cas, tu peux donc faire un

sudo ls /root

Bonne soirée

Bonjour,

  Je suppose qu'il te faut une version plus récente de Java.
Si il n'y a pas de mise à jour disponible ou que tu souhaites utiliser la version officielle de Java,
voici la procédure :

1)Télécharger la dernière version de java sur le site d'Oracle
2)Extraire l'archive compressée dans le répertoire de ton choix
3)Définir cette version de java comme étant celle à utiliser par défaut, en root :

update-alternatives --set java /EMPLACEMENT_CHOISI/jre1.8.0_111/bin/java

Bonne journée

Bonjour @peterpan31,

  Tu trouvera des exemples utilisant Grub2 ici : tutoriel/grub2_lancer_des_images_iso
Et là korben.info/booter-iso-directement

Bonne soirée

Salut @flo^4,

  Les volumes logiques fonctionnent avec trois niveaux pv, vg et lv respectivement les volumes physiques (ici tes 2 disques durs), des partitionnements/regroupements de volume physique (ici un groupe pour tes 2 disques) et enfin les volumes logiques qui se trouvent à l'intérieur d'un vg.

Tu as logiquement réalisé ces deux premières étapes :

pvcreate /dev/sdXY
pvdisplay

vgextend vg_name /dev/sdXY
vgdisplay

Il faut agrandir le lv avant de demander à resizefs d'appliquer le changement :

lvresize -L+268G /dev/vg_name/lv_name    #(LV Path de lvdisplay)
resize2fs /dev/vg_name/lv_name

Si tu as besoin d'étendre le système de fichier ou le volume physique à tout ton disque :

resize2fs /dev/sdXY
pvresize -v /dev/sdXY

Bonne soirée.

Bonjour @coucou123,

  Tu peux utiliser la calculette bc qui dispose d'une troncature pour la division. Dans ton cas (valeur simple non issue de calcul) il faut diviser par 1.

exemple :

echo "scale=2; 4.1579/1" | bc

donne 4.15

Salut @auquiel,

  Les répertoires /proc et /sys hébergent des pseudos systèmes de fichiers générés dynamiquement au démarrage (procfs et sysfs). Ils contiennent tous deux des fichiers nécessaires à l'exécution du système qui sont écris en mémoire vive à différents moments de la vie du système. L'heure de ses répertoires change donc fréquement.

Bonne soirée.

Salut @virti24,

  D'après le message le fichier /usr/lib/sudo/sudoers.so a des "w" autres que le premier. Il faut donc enlever les droits d'écriture pour le groupe (group = g) et tous les autres (all = a) :

pkexec bash
chmod ga-w /usr/lib/sudo/sudoers.so

Sachant que si pkexec bash fonctionne cela veut dire que tu as accès en root à ton ordinateur et tu peux donc entre autre effectuer la mise à jour à l'origine du problème (en espérant que ton système ne soit pas corrompu pour d'autres fichiers/processus).

Bonne soirée

Salut @manumag,

  Les programmes au démarrage ajoutés via l'application standard de Gnome gnome-session-properties sont stockés sous forme de fichiers desktop dans le répertoire ~/.config/autostart/. Ces fichiers sont au format texte tu peux donc les éditer.

Bonne soirée

Salut @Marco Sokolov,

  Effectivement ton problème ne vient pas directement de Minecraft mais de Java. Le message indique un problème de certificats, ces derniers sont utilisés par les couches de sécurité.
Plus précisement ici il s'agit d'un algorithme de cryptage invalide mais je suppose que le vrai problème est l'absence complète de certificats. Je suis étonné que cela ne soit pas présent dans tes différentes installations de Java.

Tu peux récupérer les certificats d'une autre installation Java sur un autre ordinateur peu importe le système d'exploitation.
Il y a un exemple ici : http://www.minecraftforum.net/forums/su … on-precise

Tu peux aussi générer le certificat à partir d'un fichier .pem comme indiqué ici : http://pacmiam.tuxfamily.org/article20/ … et-openjre

Bonne journée.