Ceux qui ont l’habitude d’utiliser la ligne de commande sous GNU/Linux savent que l’on peut lancer ses applications (navigateur, traitement de texte, petit script perso) tout en les détachants du terminal qui les à lancé, afin de pouvoir garder la main afin de saisir d’autres commandes.
Ceci se fait à l’aide du caractère ‘&‘, par exemple:

  $ mon_application &

Cependant, il arrive que l’on ferme le terminal par inadvertance, ou lorsque le timeout de connexion tombe alors que l’on était connecté à distance sur le terminal, pour avoir comme effet d’arrêter toutes les applications lancées à partir de ce terminal, suite à la déconnexion de notre utilisateur.

Pour remédier à ce problème, il existe la commande ‘nohup‘ qui permet au processus de rester actif même après la déconnexion de l’utilisateur.

 $ nohup mon_application &

Par défaut, cette commande à pour effet de créer un fichier de sortie appelé ‘nohup.out‘ contenant la sortie standard de la commande passée en paramètre. Ceci peut être problématique dans certains cas où le programme est lancé via un script, ce qui peut dans certains cas générer des fichiers de sortie très conséquents en taille mémoire.

On peut supprimer ce comportement en redirigeant tous les flux vers /dev/null, c’est à dire vers le ‘trou noir’ d’où rien ne ressort jamais :

$ nohup mon_application &>/dev/null &

Pour en savoir plus:
https://fr.wikipedia.org/wiki/Nohup

L’article Détacher une commande à l’aide de ‘nohup’ est apparu en premier sur StandarTux.

Si vous avez l’erreur Could not create task or type of type: for. lors de l’utilisation de Ant sous eclipse, voici un moyen de resoudre ce problème.

Ant could not find the task or a class this task relies upon.

This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: – You have misspelt ‘for’. Fix: check your spelling. – The task needs an external JAR file to execute and this is not found at the right place in the classpath. Fix: check the documentation for dependencies. Fix: declare the task. – The task is an Ant optional task and the JAR file and/or libraries implementing the functionality were not found at the time you yourself built your installation of Ant from the Ant sources. Fix: Look in the ANT_HOME/lib for the ‘ant-‘ JAR corresponding to the task and make sure it contains more than merely a META-INF/MANIFEST.MF. If all it contains is the manifest, then rebuild Ant with the needed libraries present in ${ant.home}/lib/optional/ , or alternatively, download a pre-built release version from apache.org – The build file was written for a later version of Ant Fix: upgrade to at least the latest release version of Ant – The task is not an Ant core or optional task and needs to be declared using <taskdef>. – You are attempting to use a task defined using <presetdef> or <macrodef> but have spelt wrong or not defined it at the point of use

Remember that for JAR files to be visible to Ant tasks implemented in ANT_HOME/lib, the files must be in the same directory or on the classpath

Please neither file bug reports on this problem, nor email the Ant mailing lists, until all of these causes have been explored, as this is not an Ant bug.

Déjà, vérifiez que Ant est bien installé et dans quelle version :
dans une console, entrez :

 $ ant -version

ceci devrait vous renvoyer un résultat du type:

 Apache Ant version 1.6.5 compiled on June 2 2005

de même, allez consulter vos variables d’environnement pour le Home directory de Ant avec la commande :

 $ set

vous devriez trouver une ligne du type:

ANT_HOME=/usr/share/ant

Ensuite, il faut savoir que le support de la « boucle for » n’est pas incluse par défaut dans ant, mais que cette dernière est accessible par l’ajout d’une librairie complémentaire nommée ant-contrib.

Pour l’installer, aller sous votre gestionnaire de paquets et recherchez le mot ‘ant-contrib’, soit utilisez votre terminal en mode root et tapez (pour fedora) :

 # yum install ant-contrib

Une fois les nouveaux paquets telechargés, allez les associer aux ‘entries Ant’ d’eclipse. Donc sous eclipse, allez dans le menu Window->Preferences.
Ouvrez la catégorie ‘Ant’ et selectionnez le sous menu ‘Runtime’. Là, dans l’onglet ‘Classpath’, selectionner votre ‘Ant Home entries’ qui indique le chemin de Ant (peut être /usr/share/ant suivant où il est installé sous votre système).

Si vous developpez le menu, vous verrez toutes les librairies utilisées par Ant. A partir de là, appuyer sur le bouton ‘Add external jar’ et ajoutez le fichier ‘ant-contrib.jar’ à cette liste. validez.

A présent, dans le fichier build.xml du projet. Ajoutez juste ces quelques lignes au début de votre fichier :

 <taskdef resource="net/sf/antcontrib/antlib.xml">

	<classpath>

		<pathelement location="${ANT_HOME}/lib/ant-contrib.jar"/>

	</classpath>

  </taskdef>

Relancez le ‘Ant Build’ de votre projet et ça devrait marcher.

L’article ant – Could not create task or type of type: for. est apparu en premier sur StandarTux.

Donc si au boot, ou plutôt au lancement de grub, vous vous retrouvez avec ce message :

GRUB Error 15.

Vous empêchant tout démarrage du système, ne paniquez pas ! une manip très simple permet de remettre GRUB en ordre, que je décris ci-dessous.

– redémarrer avec un live cd ubuntu (ou autre distribution) : histoire de pouvoir booter et monter un système Linux
– lancez un terminal (ou console) et entrez les commandes suivantes:

NB : remplacez sdaX par le numéro de partition ou de disque disponible sur votre système. La commande ‘sudo fdisk -l’ est là pour vous aider à trouver la partition Linux sur laquelle est installée votre ubuntu. Cherchez une ligne appelée ‘Linux’ et remplacez sdaX par celle qui vous est remontée avec la commande.

 sudo fdisk -l

 sudo mount /dev/sdaX /mnt

 sudo mount --bind /dev /mnt/dev

 sudo chroot /mnt

 apt-get install grub-pc

 update-grub

 grub-install /dev/sda

à parir de là, vous pouvez sortir en effectuant ctrl+D.

 sudo unmount /mnt/dev

 sudo unmount /mnt

Redémarrez et vous devriez à présent être capable de booter correctement sur votre système Linux.

L’article Error 15 : passage difficile à Grub2 sur ubuntu 9.10 est apparu en premier sur StandarTux.

En gros, si vous réussissez à compiler votre programme java avec ant en ligne de commande dans un terminal, et que vous effectuez cette même compilation avec ant intégré sous eclipse, et que vous ne voyez rien apparaître dans la console d’eclipse, pensez à vérifier les versions de JRE et JDK utilisé par eclipse, ainsi que celle de votre ant.

Dans mon cas, le problème provenait du fait qu’eclipse utilisait un JDK 1.6 par défaut en 64bits, alors que ma version de ant était en 32bits et que mon programme tournait d’ailleur avec une JVM 32bits.

Pour verifier chez vous, entrez la commande suivante:

 $ ant -diagnostics

et pour java, la commande:

 $ java -version

Vous devriez avoir pleins d’informations intéressantes sous cette forme:%%

– Ant diagnostics report –
Apache Ant version 1.6.5 compiled on June 2 2005

–
Implementation Version (JDK1.2+ only)
–
core tasks : 1.6.5
optional tasks : not available

—
System properties
—
java.runtime.name : Java(TM) 2 Runtime Environment, Standard Edition
sun.boot.library.path : /usr/java/jdk1.5.0_18/jre/lib/amd64
java.vm.version : 1.5.0_18-b02
ant.library.dir : /usr/share/ant/lib
java.vm.vendor : Sun Microsystems Inc.
java.vendor.url : https://java.sun.com/
path.separator : :
java.vm.name : Java HotSpot(TM) 64-Bit Server VM
file.encoding.pkg : sun.io
user.country : FR
sun.java.launcher : SUN_STANDARD
sun.os.patch.level : unknown
java.vm.specification.name : Java Virtual Machine Specification
user.dir : /home/ljames
java.runtime.version : 1.5.0_18-b02
java.awt.graphicsenv : sun.awt.X11GraphicsEnvironment
java.endorsed.dirs : /usr/java/jdk1.5.0_18/jre/lib/endorsed
os.arch : amd64
java.io.tmpdir : /tmp

java.vm.specification.vendor : Sun Microsystems Inc.
os.name : Linux
ant.home : /usr/share/ant
sun.jnu.encoding : UTF-8
java.library.path : /usr/java/jdk1.5.0_18/jre/lib/amd64/server:/usr/java/jdk1.5.0_18/jre/lib/amd64:/usr/java/jdk1.5.0_18/jre/../lib/amd64
java.specification.name : Java Platform API Specification
java.class.version : 49.0
sun.management.compiler : HotSpot 64-Bit Server Compiler
os.version : 2.6.27.24-170.2.68.fc10.x86_64

java.vm.specification.version : 1.0
sun.arch.data.model : 64
java.home : /usr/java/jdk1.5.0_18/jre
java.specification.vendor : Sun Microsystems Inc.
user.language : fr
java.vm.info : mixed mode
java.version : 1.5.0_18
java.ext.dirs : /usr/java/jdk1.5.0_18/jre/lib/ext
sun.boot.class.path : /usr/java/jdk1.5.0_18/jre/lib/rt.jar:/usr/java/jdk1.5.0_18/jre/lib/i18n.jar:/usr/java/jdk1.5.0_18/jre/lib/sunrsasign.jar:/usr/java/jdk1.5.0_18/jre/lib/jsse.jar:/usr/java/jdk1.5.0_18/jre/lib/jce.jar:/usr/java/jdk1.5.0_18/jre/lib/charsets.jar:/usr/java/jdk1.5.0_18/jre/classes

java version « 1.6.0_0 » OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-18.b16.fc10-x86_64) OpenJDK 64-Bit Server VM (build 14.0-b15, mixed mode)

Pour résoudre ce problème de compatibilité, il suffit de dire à eclipse d’utiliser une version 32bits de la JVM :
Sous eclipse : menu windows->preferences
Partie Java -> compiler
Section Java Compliance: sélectionner 1.5 Compiler compliance level.

Comme il est dit en bas de fenêtre:
« When selecting 1.5 compliance, make sure to have a compatible JRE installed and activated (currently 1.6) »

Ensuite aller sous partie Java -> Installed JREs et selectionner votre jdk en version 1.6x86_64 ou votre jdk1.5_18, l’important étant d’avoir un JDK compatible.

si ça peut servir à d’autres…

L’article Faire cohabiter Ant 32bits avec Eclipse 64bits est apparu en premier sur StandarTux.

J’ai eu a installer une application développée en Java sur une version Red Hat Entreprise Linux 5.2 Server avec un JRE 1.5.0.17 et j’ai eu quelques difficultés à réaliser cette opération mais j’ai finalement réussi suite à quelques recherches (ceci doit être valable pour la majorité des distributions Linux).

Si vous avec ce type d’erreur dans une console lors de l’installation ou de l’execution d’une application java:

 $ ./MonAppli

 awk: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory

 dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

 /bin/ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory

 basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

 dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

 basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

 grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

 /home/user1/soft-6.1-911/jre/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

La cause :
Sans rentrer dans le détail, ce problème survient lors d’une incompatibilité de l’installateur du JRE (Java Run-time Environment) avec certaines librairies système.

La solution :
La commande à effectuer va consister à afficher le contenu de MonAppli.bak, l’envoyer à la commande sed qui lui va mettre en commentaire (grâce au #) la ligne export LD_ASSUME_KERNEL.
export LD_ASSUME_KERNEL mets en place une variable d’environnement qui va spécifier la version du noyau à utiliser (2.4 ou 2.6).

Il faut lancer les commandes suivantes dans une console ou un terminal dans le même repertoire où vous avez extrait l’installateur du logiciel ou de son executable (remplacer MonAppli par le nom de votre logiciel):

 $ cp MonAppli MonAppli.bak

 $ cat MonAppli.bak | sed "s/export LD_ASSUME_KERNEL/#xport LD_ASSUME_KERNEL/" > MonAppli

Pensez à rendre votre fichier executable au cas ou:

 $ chmod +x MonAppli

Et executez-le:

 $ ./MonAppli

Suite à l’installation de votre application ou de son execution, si ça fonctionne, vous pouvez supprimer les fichiers .bak.

 $ rm MonAppli.bak

J’ajoute un petit complément à ce billet car j’ai été confronté à un autre souci qui m’a finalement fait perdre pas mal de temps (sous Fedora 10)…
Si suite aux petites manipulations vu ci-dessus vous rencontrez une erreur du type ou quelque chose s’en rapprochant:

 Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

 Stack Trace:

 java.lang.UnsatisfiedLinkError: /tmp/install.dir.4072/Linux/resource/jre/lib/i386/xawt/libmawt.so: libXext.so.6: cannot open shared object file: No such file or directory

 at java.lang.ClassLoader$NativeLibrary.load(Native Method)

 at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)

 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1647)

 at java.lang.Runtime.load0(Runtime.java:769)

 at java.lang.System.load(System.java:967)

 at java.lang.ClassLoader$NativeLibrary.load(Native Method)

 at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)

 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1668)

 at java.lang.Runtime.loadLibrary0(Runtime.java:822)

 at java.lang.System.loadLibrary(System.java:992)

 at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)

 at java.security.AccessController.doPrivileged(Native Method)

 at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)

 at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)

 at java.awt.Component.<clinit>(Component.java:545)

 at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)

 at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)

 at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)

 at com.zerog.ia.installer.Main.main(DashoA8113)

 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

 at java.lang.reflect.Method.invoke(Method.java:585)

 at com.zerog.lax.LAX.launch(DashoA8113)

 at com.zerog.lax.LAX.main(DashoA8113)

 This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Commencez par faire un locate de la lib qui pose problème, ici libXext.so.6 :

 $ locate libXext.so.6

dans le cas ou celà fonctionne, vous devriez avoir sous Fedora 10 :

 /usr/lib64/libXext.so.6  /usr/lib64/libXext.so.6.4.0

Si rien, n’apparait, c’est que cette librairie n’est effectivement pas présente (pour on ne sait quelle raison car la fois precedente ça avait fonctionné…) et qu’il va falloir l’installer à la mimine et là c’est rendez-vous sur https://rpmfind.net/ :

un petit search de la librairie vous aidera souvent :
https://rpmfind.net/linux/rpm2html/search.php?query=libXext.so.6

Et ce pour un grand nombre de distributions basées sur les RPM.

L’article Installation d’une application JAVA impossible sous Red Hat est apparu en premier sur StandarTux.

echo "set bell-style none" >> ~/.inputrc

validez et redemarrez votre session. voilà, le tour est joué!

NB:
Sylvain nous à fait un billet bien plus complet, je donne juste le lien, merci à lui.
https://blog.gnusquad.org/2009/02/05/faites-taire-votre-pc-speaker/

L’article Arrête de me bipper! est apparu en premier sur StandarTux.