So you’re writing a Python script and you are launching some other external command.

To achieve that, you are using the subprocess.Popen command, right.

But the subprocess is very slow, and it outputs data during it runtime, so you would like to output this data to the user as well, so that the user does not wait for the end of the subprocess before getting the information?

Example of a slow subprocess:

#!/bin/bash
for i in 1 2 3 4 5 6; do sleep 5 && echo "${i}th output" && echo "err output num ${i}" >&2; done

Well, that’s fairly easy, just redirect the subprocess’s stdout to your own stdout:

import sys
from subprocess import Popen
Popen("./slow_cmd_output.sh", stdout=sys.stdout, stderr=sys.stderr).communicate()

Although the catch here is the .communicate(). This will allow your program to wait for the end of the subprocess before executing the next line of code. So that your programm does not terminate execution before its subprocess, for instance.

Not that if you want to deamonize the script / zombify it, you can remove the .communicate() and the redirection of stdout and stderr will still work after your program’s termination.

Print vs. Echo

I just went accross an interesting article about which of « print » or « echo » we should use in PHP.

The author has benchmarked the two solutions (though the data are certainly a bit old) shows that, although there is not much difference between the two, echo seems to be more efficient.

Great, I believe you.

Echo multiple statements / arguments vs. Concatenation

But at the end of the article, the author also suggest to use multiple parameters given to one echo statement instead of concatenation because concatenation is slow… bla bla…

As I have always been using concatenation (did not even know echo could take multiple arguments) and I never had any performance issue, I decided to check that and make a benchmark: echo 100,000 times two concatenated strings and do the same thing with two parameters and two echos statements…

The benchmark was clear: concatenation IS FASTER than the two other solutions.

String caching? Making a more relevant benchmark

As it appeared a bit weird to me, having been doing Java / C# mostly recently (with their slow concatenation that recreated a new object blabla), I thought « maybe the PHP VM is caching the result of the concatenated string, thus the benchmark is not relevant ».

OK, let’s check with a counter-possible-caching benchmark then:

$t0 = microtime(true);

define("MAX", 2000000);
File_put_ConTents("echobench._log", "");
function _log($str)
{
	File_put_ConTents("echobench._log", file_get_contents("echobench._log") . $str);
}

// Generating a bunch of string to concatenate to avoid PHP VM-caching
$strs = array();
for ($i=0; $i < MAX+1; $i++) { 
	$m = mt_rand(0, 200);
	$strs[$i] = '';
	for ($j=0; $j < $m; $j++) { 
		$strs[$i] .= chr(mt_rand(0, 255));
	}
}

// Loop where string concatenation caching is possible :
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" . "World! 
";
}
$t2 = microtime(true);
_log("Concatenation, cached: " . ($t2-$t1) . "s\n");

// Loop where is is not :
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i] . $strs[$i + 1];
}
$t2 = microtime(true);
_log("Concatenation, not cached: " . ($t2-$t1) . "s\n");

// Other ways to display stuff, with and without caching possible each time:
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i];
	echo $strs[$i + 1];
}
$t2 = microtime(true);
_log("Two echos, not cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" , "
";
	echo "World" , "
";
}
$t2 = microtime(true);
_log("Two echos, cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i], $strs[$i + 1];;
}
$t2 = microtime(true);
_log("Two parameters, not cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" , "World!" , "
";
}
$t2 = microtime(true);
_log("Two parameters, cached: " . ($t2-$t1) . "s\n");

$t3 = microtime(true);

_log("Total benchmark time: " . ($t3-$t0)."\n");

I generated random strings at the beginning of the script. And I concatenate them after, in the loop. Thus, there is not even once the same concatenation happening, thus, no possible caching or whatever.

The benchmarked has been run on a 1.6GHz Atom processor, with the following command:

sudo nice -n -19 php -q echobanchmark.php > /dev/null

So the process was the most prioritized one on the OS and then there is no reason for any interference between the loops (moreover, the system was idle during the test (and there are 3 other virtual processors for doing whatever work the OS would need to do).

And do you know the result?

Here it goes:

Concatenation, cached: 7.4381861686707s
Concatenation, not cached: 9.9010219573975s
Two echos, not cached: 10.4353120327s
Two echos, cached: 14.883654117584s
Two parameters, not cached: 10.179102897644s
Two parameters, cached: 11.904446840286s
Total benchmark time: 928.97792601585

Conclusion: Concatenation is fast, very fast. It is rougly 30% faster than using the two parameters for echo (26.9268987% exactly) and roughly 30% faster than two echo statements as well (28.720999% exactly) and

The other conclusion here is that PHP does not seem to be caching strings very well. Both the two-parameters and two-statements echo loops are much slower when using a fresh new string and much faster when using something from the previously generated array. The difference between cached / non-cached loop for the concatenation loop is also not that impressive if we observe that my « not cached » loop is using strings of random length that can go until 200 chars whereas the « cached » one is a very short string (so the difference of 2 seconds is certainly also due to the difference in length of the strings).

If you have any suggestion to improve the benchmark, feel free to post a comment.

 

English readers : see at the bottom of the French version !!

Hello les amis,

Aujourd’hui, petite astuce qui pourrait faire gagner 1h à des gens qui comme moi, pensent qu’il suffit de résoudre un conflit pour… qu’il soit résolu !

Eh bien non, cela ne semble pas marcher tout à fait pareil avec le plug-in Subclipse pour Eclipse.

Si vous avez le malheur d’avoir un conflit, normalement, il vous suffit de faire clic-droit sur le fichier puis « Team » puis « Mark as resolved ».

SAUF QUE le .cproject n’apparaît bien évidemment pas dans la perspective « ressources » (par défaut) de Eclipse !! Impossible donc de le résoudre !

Or, si vous le résolvez en utilisant SVN via la console par exemple, Subclipse ne s’en « rendra pas compte » (ne me demandez pas pourquoi) et refusera encore et toujours de commiter les futurs changements.

Pour résoudre le conflit, il faut que vous ouvriez la « perspective » « Team Synchronizing », à ce moment-là, vous devriez enfin voir votre .cproject et vous pourrez alors faire Mark as resolved (en sélectionnant ensuite l’option de votre choix sur la résolution du conflit).

Voilà ! Et Subclipse arrêtera de vous harceler avec ce conflit qui n’en est plus un…

Bon dev’ !

 

————————English version (summerized) ———————–

Hi folks,

The .cproject file won’t be displayed on the « resources » perspective (view), so you can’t resolve the conflict by right-clicking and then selecting options « Team » and « Mark as resolved ».

Moreover, solving the conflict using the SVN command line interface won’t work, Subclipse will « remember » the conflict.

To get this working, you have to open the « Team Synchronizing » perspective in Eclipse. There, you should be able to find the .cproject file and so Mark it as resolved (and then select the option you want for the conflict solving way).

Here it is ! Subclipse will stop harassing you !

 

Have a nice dev’ !

Voici un micro-article (après la boulette de cette aprem… publication d’un brouillon par mégarde…) pour quand même mettre l’info à disposition sur Internet : Si vous cherchez sur Internet comment lire les MP3 sous Fedora vous allez tomber sur cette page : Lecture de fichiers multimédia sur Fedora.

Tout d’abord, il vous faudra, si ce n’est pas encore fait, installer les dépôts RPM Fusion (merci à Mezzo pour le rappel ). Ces dépôts contiennent à peu près… beaucoup de choses dont vous aurez besoin ! Notamment les pilotes graphiques pour Nvidia… etc. etc. … Bref, c’est un must-have, installons-les, pour cela, tapez les commandes suivantes dans une console (il va vous demander le mots de passe root, c’est normal vous allez installer un logiciel !) :

su -lc ‘yum install --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm‘
su -lc ‘yum install --nogpgcheck http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm‘

Si cette page est très intéressant, elle n’est cependant pas à jour. Dorénavant, Amarok sous Fedora utilise GStreamer, pour avoir les MP3 il vous faut donc installer les paquets suivants :

# yum install gstreamer-plugins-ugly gstreamer-ffmpeg

Un petit redémarrage d’Amarok peut s’imposer afin que ça fonctionne…

As usual, for international readers, the english version is below, at the end of the French version

Alors, on va encore m’accuser de publier que des billets geeks, et court pour celui-ci en plus, mais c’est tellement galère à chercher sur le net, que je ne peux m’empêcher de partager cette astuce avec vous

Passons aux choses intéressantes : Il peut être intéressant, voire indispensable (et ça vous intéressera majoritairement dans le cas où c’est indispensable, n’est-ce pas ) de pouvoir utiliser une vieille version de autoconf, notamment la fameuse 2.13, à la place votre super version hyper à jour utilisée par votre système GNU/Linux. Cependant, la question toute bête : bordel comment on fait pour dire à buildconf d’utiliser une autre version que celle par défaut du système ?

Eh bien, si vous avez passé une heure à chercher sur internet avant d’atterrir ici, vous allez être peut-être un peu déçu par la simplicité de la chose, mais bon, on n’échappe pas aux lois de Murphy ! :

export PHP_AUTOCONF=`which autoconf-2.13`

Note : ceci est l’exemple pour la compilation de PHP, pour la compilation d’un autre programme cela ressemblera très certainement à cela, je ne peux cependant pas donner de généralité !

Voilà c’est fini. Il suffit de taper cela dans votre console juste avant d’exécuter la commande « ./builconf » (ou généralement « ./buildconf –force » mais peu importe). Attention, cependant, vous devez taper cette commande et celle du buildconf dans la même console, évidemment.

J’espère que vous vous sentez soulagés Notamment si vous étiez en train d’essayer d’installer…humm… php depuis les sources ?

Merci à MaGeekGuy pour l’astuce

————————————————————————————————- Lire la suite…

Note : Ceci marche évidemment avec n’importe quel domaine, que ce soit un .fr, .com, .coucoucestmoi. Ceci marche avec n’importe quel « type » de domaine 1&1 également : fourni avec un pack hébergement ou pack domaine ou encore autre chose.

Nous allons donc voir aujourd’hui comment configurer des DNS externes (ses propres DNS par exemple) pour son domaine 1&1

La procédure est assez simplissime, aussi je me suis permis de faire un tuto screenshots :

Allez sur le site de 1&1 : en cliquant ici par exemple.

Cliquez en haut à gauche sur le lien « Espace client » :

Puis connectez-vous avec votre domaine pour login (sauf si vous connaissez votre identifiant client par coeur, bravo!) et votre mot de passe :

Maintenant, cliquez sur cette icône :

Sélectionnez le domaine dont vous souhaitez changer les DNS, puis sur « DNS » en haut :

Maintenant cliquez sur « Modifier » :

Suivez les indications dans l’odre : rentrez votre DNS externe primaire (ici nttserv.fr.nf, mon DNS) puis secondaire (spit.free-h.org le DNS secondaire de mon hébergeur).

Voilà c’est terminé, validez tout le bazar et attendez que la MàJ se fasse.

Attention, les MàJ sont non seulement plus ou moins lentes selon les extensions (le .fr par exemple doit attendre la revalidation de l’AFNIC), mais en plus votre FAI peut être lent voire très lent (comme citons Darty, Orange Nord-Pas-de-Calais (DNS de Reims de mémoire), et Numéricâble département 69 (pour ceux que je connais en tout cas) ). Darty étant le pire, jusqu’à 7 jours. Vous pouvez décider de changer les DNS de votre ordinateur si vous en avez marre d’attendre.

Dans la lignée de la précédente astuce sur les fichiers distants en voici une autre, plus courte, mais qui pourrait bien en dépanner plus d’un. En effet la fonction is_file() ou encore la fonction file_exists() sont des fonctions faites pour fonctionner sur le système de fichier local. Et elles ne fonctionneront donc pas si vous cherchez à savoir si le fichier « http://web.com/fichier.blabla » existe ou pas.

L’astuce est toute simple, elle consiste à tenter d’ouvrir le fichier, avec une fonction qui elle, prend en charge le HTTP :

function FichierDistantExiste($url) {
   if(!@fopen($url, 'r')) return false;
   else return true;
}

Ce fut bref, mais j’espère que cela vous sera utile

Attention par contre, sauf erreur de ma part certaines configurations PHP (notamment sur des mutualisés évidemment, mais pas tous hein) empêchent fopen() d’utiliser le HTTP. Dans ce cas, on serait bien tenté d’utiliser la fonction file_get_contents() sauf qu’en fait ce n’est qu’une espèce de raccourci pour les fonction fopen(), fgets() et fclose() les un après les autres. Donc si l’un est bridé l’autre devrait l’être aussi. À vous de tester, on ne sait jamais.

Cette source n’est pas de moi, cependant comme je ne suis pas sûr que tous les gens qui cherchent comment récupérer la date de dernière modification d’un fichier en utilisant le HTTP (fichier distant) arrivent facilement à trouver ce post (en anglais en plus) je vous mets la source ici.

D’ailleurs, au passage, comme je suis un gentil Troll, je vous l’ai traduite

// Récupérer la date de dernière modification d'un fichier distant (la fonction retourne un timestamp unix, cf. http://wiki.pcinfo-web.com/timestamp )
function RecupDateModifDistant( $uri )
{
// default
$unixtime = 0;
$fp = fopen( $uri, "r" );
if( !$fp ) {return;}

$MetaData = stream_get_meta_data( $fp );

foreach( $MetaData['wrapper_data'] as $response )
{
// Dans le cas d'une redirection vers une autre page / un autre fichier
if( substr( strtolower($response), 0, 10 ) == 'location: ' )
{
$newUri = substr( $response, 10 );
fclose( $fp );
return RecupDateModifDistant( $newUri );
}
// Dans le cas où on a bien l'en-tête "last-modified"
elseif( substr( strtolower($response), 0, 15 ) == 'last-modified: ' )
{
$unixtime = strtotime( substr($response, 15) );
break;
}
}
fclose( $fp );
return $unixtime;
}

Voilà, pour toute demande d’explication du code, les commentaires sont là pour ça, ils vous attendent pour vous faire des calins ! (gratuit !)

Bonsoir la compagnie,

Après avoir fait joujou une première fois avec les tâches planifiées sous cron gnu/linux, je vous avais promis de vous en dire plus sur les procédés et les possibilités du système de planification des tâches de GNU/Linux : cron.

Résumé de ce que vous savez déjà faire si vous avez lu la première partie sur les tâches planifiées cron :

• Créer une tâche planifiée simple qui lance un fichier exécutable avec l’utilisateur courant (celui qui a créé le cron) à l’aide la commande crontab
• Faire des tâches planifiées à exécution unique (planification non régulière/récurrente)
• (Utiliser un autre éditeur pour la commande crontab -e)

Ce que je vais vous apprendre en plus dans cet article :

• Gérer des dates complexes : Répétitions, récurrence des tâches planifiées (jokers, répétitions, sélections multiples)
• Définition d’un fichier personnalisé de tâches planifiées
• Définir une tâche exécutée par un utilisateur précis.
• Éxécuter une tâche planifiée dans un répertoire particulier.
• Éxécuter une tâche planifiée graphique.
• Gérer les sorties des commandes exécutées par CRON : logs, mails, etc.

Je vous donnerai également quelques filons pour l’utilisation de PHP avec CRON.

Retour sur la planification des tâches : la syntaxe des dates avancées avec CRON.

Je ne refais pas les explications sur les dates simples dans CRON, c’est le sujet de la première approche (dont vous avez les liens au début de cet article). Nous allons voir comment créer une tâche récurrente, à l’aide des jokers, répétitions et sélections multiples.

Le joker : *

Comme dans beaucoup d’applications informatique, le joker chez Cron est l’étoile « * ». Ainsi, si vous remplacez un quelconque paramètre d’une date par une étoile, cela signifie pour cron « quelque-soit la valeur de ce paramètre ».

Exemple : Quelque-soit le jour, je veux que à 7h05 tu dises bonjour, durant tout le mois de février :

05 07 * 02 * echo 'Hello World !'

Ici nous avons remplacé le numéro du jour dans le mois, ainsi que le jour de la semaine (qui est également susceptible de varier !) par le joker « * », ainsi, quelque-soit les valeurs de ces paramètres, si les autres paramètres (heure, minute, mois) sont vérifiés, CRON dira bonjour au monde.

La répétition : /

Le joker permet de spécifier, au maximum, une répétition toutes les unités de temps d’un paramètre précis. En effet, si je mets un joker pour l’heure, alors cela sera exécuté toutes les une heure, puisque cela sera « quelque-soit l’heure ». Ainsi, avec les jokers, vous pouvez répéter au mieux : tous les jours, toutes les heures, toutes les minutes, tous les lundis, tous les mois… Bref, pas terrible comme flexibilité tout de même. C’est à cela que sert la répétition, elle vous permet de dire tous les combien de variation d’un paramètre vous voulez que cela se répète. Une variation d’un paramètre, c’est +1 minutes, +1 heure, +1 jour, etc. …

L’opérateur de répétition s’utilise comme suit : valeur_param/intervalle_de_repetition

Ainsi, si je veux que toutes les 15 minutes, une action se répète, quelque-soit la date :

*/15 * * * * /usr/bin/monaction

On utilise ici également le joker, puisque l’action se répète quelque-soit la minute, l’heure, ou la date…

Les intervalles et les sélections multiples

Vous pouvez également définir plusieurs valeurs d’un paramètre pour lesquelles la tâche sera exécutée. On procède soit en donnant un intervalle de valeurs, soit une liste de valeurs.

Opérateur d’intervalle : -

Utilisation : borne1-borne2 ou borne1 et borne2 sont les bornes de l’intervalle ( [borne1 ; borne2] ) et incluses.

Exemple : La précédente action se répète toutes les 15 minutes, du 1er au 10 du mois

*/15 * 1-10 * * /usr/bin/monaction

Opérateur de valeurs multiples : ,

Utilisation : valeur1, valeur2, valeur3…

Exemple : La précédente action se répète toutes les 15 minutes mais seulement entre 02h et 03h puis entre 05h et 06h

*/15 2,5 * * * /usr/bin/monaction

Définir une fichier cron personnalisé : Cron en mode admin

Jusqu’à présent, vous avez utilisé la commande crontab afin de modifier votre fichier cron et d’ajouter ou de supprimer des tâches.

En réalité vous n’avez utilisé que le côté « utilisateur » de cron. La suite n’est ouverte qu’à un accès root, autrement dit l’administateur de la machine, car elle permet notamment de décider de sous quel utilisateur vont être exécutées les tâches, ce que nous verrons en même temps.

Si ce mode d’utilisation de cron n’est réservé qu’à l’administateur, c’est pour plusieurs raisons :

1. Il va permettre, comme je l’ai dit, de choisir l’utilisateur qui exécute la commande
2. Le répertoire dans lequel nous allons créer le fichier appartient à root
3. Seul root peut demander à cron de recharger les fichiers de configuration, or nous en aurons besoin car comme nous allons éditer de simples fichiers, la commande crontab ne sera pas là pour, à la fin de l’édition du fichier, dire à cron « Hey hey, ouhou, on a modifié le fichier là, viens y jeter un coup d’oeil » et par défaut cron ne verra donc pas vos modifs sans reload, et donc sans droits d’admin.

Créer votre fichier de tâches planifiées : le répertoire /etc/cron.d/

Vous êtes donc maintenant loggé en root, ou, si vous n’avez pas le su sur votre machine, vous exécuterez le reste des commandes avec un « sudo » devant.

Les fichiers de tâches planifiées sont placés dans le répertoire /etc/cron.d/, qui appartient à root.

Créons-y un fichier :

vim /etc/cron.d/monfichiercron

Voilà, tout le travail est fait… ou presque. Dans ce fichier, vous pouvez placer des tâches planifiées exactement de la même façon qu’avec la commande crontab à la différence prêt… qu’il faut spécifier l’utilisateur d’exécution !

Cela donne :

mm HH JJ MM joursemaine utilisateur /chemin/commande

Exemple, je suis l’utilisateur Troll, je veux que l’utilisateur Toto fasse le ménage dans son dossier personnel chaque semaine (vision geek du Range ta chambre ! maternel/paternel), on dira qu’on est un peu radical, si le dimanche il n’a pas vidé son dossier perso (il est censé le faire le samedi) tant pis : tout poubelle !
Note : A NE PAS TESTER CHEZ VOUS ! Vous risqueriez d’avoir de sérieux ennui ^^

01 00 * * sun toto rm -fR /home/toto/*

Bien sûr l’utilisateur peut aussi être root… But, be careful !

Ensuite, une fois que vous avez sauvegardé votre fichier, il faut dire à cron de le relire pour l’intégrer :

(encore une commande à faire en root, si vous avez bien lu le début de ce paragraphe !)
/etc/init.d/crond reload

Cron a bien rechargé s’il dit ça normalement :

Reloading crond: [ OK ]

Les autres fichiers préconfigurés de cron :

Cron a également des dossiers préconfigurés, dans lesquels il vous suffit de mettre un script (ou un lien symbolique, solution la plus souvent utilisée) exécutable.

Ces dossiers sont les suivants :

• /etc/crond.daily : exécution quotidienne (chaque jour à 4h02)
• /etc/crond.hourly : exécution chaque heure (chaque heure + 1 minute)
• /etc/crond.weekly : exécution hebdomadaire (le dimanche à 4h22)
• /etc/crond.monthly : exécution mensuelle (le 1er du mois à 4h42)

Comme je suis gentil, je vous donne même les commandes :

Création d’un script exécutable dans un dossier :
(en root encore et toujours)
vim /mon/chemin/de/fichier && chmod +x /mon/chemin/de/fichier

Création d’un lien symbolique dans /etc/crond.daily (par exemple) pointant vers /mon/chemin/de/fichier :

ln -s /mon/chemin/de/fichier /etc/crond.daily/monscript && chmod +x /etc/crond.daily/monscript

L’avantage du lien symbolique c’est que vous pouvez mettre votre script dans un dossier où vous le retrouvez et vous pouvez placer un lien dans plusieurs dossiers /etc/crond.XXX/ sans avoir à modifier tous les fichiers quand vous modifiez le script (principe du lien symbolique).

Éxécuter des tâches planifiées dans un répertoire particlier

Il peut s’avérer que vous ayiez besoin d’exécuter une commande qui va chercher des fichiers ou autres dans son répertoire courant et qui sera donc perdue si vous la lancez avec cron de la manière /chemin/commande

Pour cela, utilisez tout simplement la commande cd :

03 01 * * * tutu cd /home/tutu/scripts/ && ./macommande

Éxécution d’une tâche planifiée graphique

La console, y’a rien de mieux, ça plante pas, ça vous cache rien… Mais c’est pas très esthétique. Puis si vous voulez par exemple lancer Amarok pour vous reveiller en musique, Amarok va avoir besoin d’une interface graphique (sauf si vous connaissez une interface ligne de commande pour amarok, auquel cas je veux bien que vous partagiez l’info avec moi !).

Pour cela, procédez comme suit : placez DISPLAY=:0 après le jour de la semaine, ou après le nom d’utilisateur quand celui-ci est spécifié.

Si vous utilisez une commande composée, du type :

/chemin/premierecommande && /chemin/deuxiemecommande

(ce qui est notamment le cas lorsque vous exécutez dans un répertoire particulier) alors vous devez mettre le DISPLAY=:0 juste avant la commande qui aura besoin de l’affichage.

Gérer les sorties des commandes exécutées par CRON : logs, mails, etc.

Par défaut, notamment lors de la définition d’une tâche planifiée avec crontab -e, si votre commande génère une sortie vous devez – en théorie (désactivé sur certaines distrib’) – recevoir un « mail » ( dans /var/spool/votrelogin ) avec la sortie générée.

Ce n’est pas vraiment un mode très pratique pour logger et retrouver les sorties de vos tâches planifiées préférées.

Je vais donc vous montrer comment enregistrer dans un fichier log la sortie de vos tâches planifiées.

En fait, cela revient au même que pour enregistrer dans un fichier log une commande console standard. Cela revient à faire comme ceci :

Enregistrer tout dans monfichier.log (sortie normale + erreurs)
/chemin/macomandequigenereunesortie > monfichier.log 2>&1

Enregistrer seulement les erreurs dans monfichier.log :

/chemin/macomandequigenereunesortie > /dev/null 2> monfichier.log

Ne rien enregistrer :

/chemin/macomandequigenereunesortie > /dev/null 2>&1

Attention, tel que c’est présenté ici, chaque nouvelle exécution remplace le contenu de monfichier.log

Si vous voulez logger sur plus d’un seul lancement, vous devez créer le fichier monfichier.log avant (ce qui n’était pas nécessaire précédemment) et remplacer systématiquement dans les précédentes commandes, le « > » par « >> » (enfin presque, pas tous, regardez ci-dessous).

Ce qui donne :

/chemin/macomandequigenereunesortie >> monfichier.log 2>&1
/chemin/macomandequigenereunesortie > /dev/null 2>> monfichier.log
/chemin/macomandequigenereunesortie > /dev/null 2>&1

Annexes : Utilisation de PHP avec CRON

Pour lancer une tâche écrite en PHP avec cron, saisissez une tâche de la manière suivante :

mm HH JJ MM joursemaine [user] /usr/bin/php -f /chemin/de/fichier.php

Ou, ce qui est conseillé avec PHP, avec exécution dans un repértoire particulier :

mm HH JJ MM joursemaine [user] cd /chemin/de/ && /usr/bin/php -f ./fichier.php

Bien évidemment, vous pouvez logger dans un .log avec les .php comme avec n’importe quelle autre commande.

Voilà, c’est terminé : des remarques, des erreurs à signaler, des questions -> Les commentaires sont là pour ça ! J’espère avoir été clair et que cet article sera utile au plus grand nombre

Aujourd’hui je vous fais part d’une chose que bien des gens ont cherché sur Internet et que bien des webmasters ont abandonné de trouver… la méthode pour connaître la valeur du prochain ID d’un champ de type AUTO_INCREMENT dans une table SQL.

Attention cependant, cette méthode fonctionne pour une table ne comprenant qu’un seul champs de type auto_increment et pour MySQL. Je vous laisse le soin de tester (et de nous dire ce que ça donne en laissant un petit commentaire ) et d’adapter pour d’autres situations, celle situation-ci restant la plus courante.

L’astuce est d’appeler la commande SHOW TABLE STATUS.

En effet si vous tapez par exemple cette requête SQL dans PhpMyAdmin, vous verrez apparaître plein d’informations sur toutes les tables de votre base de données courante.

Si vous souhaitez réduire les lignes à une table précise :

SHOW TABLE STATUS
LIKE 'NomDeLaTable'

Vous allez alors voir qu’une colonne est nommée Auto_increment (attention à la majuscule, importante !). Cette colonne contient la prochine valeur que prendra le champs de type auto_increment de cette table. Attention : la PROCHAINE. Si vous souhaitez connaître la dernière valeur prise par l’auto_increment il faut donc soustraire 1. Je rappelle au passage que l’utilisation de la commande MAX() ou d’un SELECT avec un ORDER BY DESC LIMIT 0,1 derrière ne fonctionnera pas car vous avez la possibilité que des lignes de la table aient été supprimées.

Si vous utilisez par exemple PHP et la fonction mysql_fetch_assoc() (ou mysql_fetch_array() pour les non-éclairés ou ceux qui ont besoin des clés numériques & textuelles), vous récupérerez alors dans votre tableau associatif cette valeur dans la clé nommée ‘Auto_increment’.