Please learn a scripting language and use it.

A conversation I had last friday:

Alex: “Okay, so I have to separate table creation statements and alter table statements. But It’ll be a tedious copy-and-paste code work!”

Me: “Why don't you script that? At least use Excel to generate your queries from a list of table…” (can’t believe I said that)

Alex: “It'll make the job even harder!”

I sighed.

I’m shocked by the amount of my fellow programmer not taking time to learn a scripting language. I don’t care what you want to use, Python, Ruby, Perl, Bash or PowerShell… but learn (at least) one. Automate all repetitive tasks if feasible: you are paid to bring value by being creative, not to do machine job. And guess what, the machine is infinitely more reliable and faster at this than you are.

I write lots of scripts, and it saved my butt lots of times. I script app deployment, I script KPI gathering, I script commercial proposal generation, I script service reference modification when WCF makes shit. I get furious when a piece of software I have to use doesn’t provide an API nor a CLI.

Please learn a scripting language and stop wasting your time, wasting my time and screw up the whole project with your hazardous copy and past scenario.

Avec TMUX, on respire

J'ai installé Tmux sur mon serveur de dev au boulot. Comme son nom l'indique presque, il s'agit d'un multiplexeur de terminal, comme GNU screen mais en plus vivant. Dans une session Tmux, vous pouvez splitter votre écran, ouvrir plusieurs fenêtres. Vous pouvez naviguer dans l'historique, faire du copier coller. Mieux, vous pouvez détacher votre session pour la reprendre plus tard.

Le plus beau est que la session reste ouverte en cas de déconnexion. Vous vous reconnectez, vous faites un tmux attach et là c'est cool : vous retrouvez tout ! Fini les cris dans l'openspace parce que vous vous êtes déco pour partir en réunion alors que vous aviez un traitement de 6 heures en cours. Fini le stress que la dame de ménage débranche l'ordi pour brancher son aspirateur lorsque vous lancez un traitement pendant la nuit !

Derniers trucs :

• j'ai eu un souci sur Solaris pour lancer vi (le classique, pas le improuvède). Il se trouve que Tmux valorise la variable TERM à screen, ce qui perturbe un peu vi. Un export TERM=xterm avant de lancer vi règle le problème.
• Si vous voulez facilement avoir les bindings vi dans le copy-mode de Tmux, faites un export EDITOR=vi avant de lancer votre session. Il y a aussi une option qu'on peut lui passer après le lancement, mais elle est compliquée à mémoriser.
• Si vous n'avez pas tmux ni de quoi télécharger des binaires ou compiler des sources et que vous devez lancer un traitement long, pensez quand même au bon vieux nohup qui en cas de déconnexion de votre client, rattachera le process au PID 1 qui normalement ne peut pas se déconnecter, lui :).

Site officiel de tmux (oui, c'est moche)

printf en shell

Voici un truc sympa que j'ai découvert à mes dépends en shell.

$ printf "truc : %s\n" foo bar baz
truc : foo
truc : bar
truc : baz

Ça peut avoir un intérêt... J'ai testé sur bash et ksh.

ctags

ctags a participé à sauver ma journée.

C'est un outil qui génère un fichier tag contenant les endroits où sont définis les éléments (fonctions, classes) dans les fichiers source. Ce fichier tag est ensuite utilisable par des éditeurs de texte comme vim. Je pensais qu'il ne marchait que pour le C et le C++, mais en fait il prend en compte beaucoup de langages :


romain@lilibox:~$ ctags --list-languages
Ant
Asm
Asp
Awk
Basic
BETA
C
C++
C#
Cobol
DosBatch
Eiffel
Erlang
Flex
Fortran
HTML
Java
JavaScript
Lisp
Lua
Make
MatLab
OCaml
Pascal
Perl
PHP
Python
REXX
Ruby
Scheme
Sh
SLang
SML
SQL
Tcl
Tex
Vera
Verilog
VHDL
Vim
YACC


Vous construisez le fichier avec

ctags -R


Dans le code source avec vim, faites Ctrl+] pour aller à la définition d'une fonction[1] et Ctrl+t pour revenir à l'endroit précédent.

L'inconvénient est qu'il faut générer les tags dès qu'on retouche aux fichiers où sont définies les fonctions appelées, mais pour débugger du shell ou du C tordu, ça aide bien !

[1] et oui, cela marche mieux avec la disposition américaine des touches !

OMFG

On peut dire que j'ai appris quelque chose aujourd'hui dans le fastidieux travail de remise d'aplomb de la plateforme de qualification du client.

Le problème

Un transfert de fichier ne se faisant pas entre 2 serveurs

L'errance

Transfert de fichier ? Facile, c'est du scp (non). Du rcp (non) ? Un montage nfs (NON) ? Ben quoi alors ?

La solution

Le transfert est réalisé par dd, initié sur la plateforme de départ, pipé dans un remsh pour terminer sur la plateforme d'arrivée. Et bien, je ne savais pas que c'était possible.


dd if=$input bs=$block | remsh arrivee dd of=$output bs=$block


Détail amusant, la commande n'est pas lancée directement mais au travers d'un autre remsh en local, afin de rebondir sur un utilisateur qui avait l'équivalence sur la plateforme d'arrivée et les droits sur le répertoire de destination.

Un ajustement des .rhosts de tout le monde et ça doit être résolu. Pas de remarque sur la problématique de sécurité apportée par la commande remsh et le système des rhosts.

C'est dans notre code...

Avoir du fun avec cat

J'ai appris un truc récemment sur cat. Il ne sert pas seulement à concaténer et lire des fichiers. On peut aussi écrire des lignes de façon interactive, ce qui est très pratique pour ajouter des lignes dans un fichier de configuration par exemple.


# Ecriture
romain@lilibox:~$ cat > test.log
some
text

# Lecture
romain@lilibox:~$ cat test.log
some
text


A la mode ?

Il y a quelques temps j'ai commencé à faire un Langage Dédié pour faire des tests de validation sur des processus Dollar Universe (c'est un outil d'ordonnancement).

Dans un shell (ksh), les étapes de test se présente ainsi :


test_session 47ZMPUGRFM contient "47ZMPRFM_D 47ZMPRFMIN 47ZMPRFMAL 47ZMPRFMSA 47ZMPRFMCO 47ZMPRFM_F"
test_uproc 47ZMPRFM_D necessite_ressources 47Z_PUGRF_EC
test_uproc 47ZMPRFMIN contient ARCinitPurgeReferentielFixe.ksh
test_uproc 47ZMPRFMAL contient ARClanceAlimTableAuxiliaireFixe.ksh


Ce qui est sympa c'est que le contenu des tests devient facile à parser. Il est alors envisageable de générer du texte automatiquement pour remplir un cahier de test grace à un script idoine (en Python, évidemment !)

Le bug du ls

Difficile vendredi avec un dépannage imprévu en production.

Une erreur sur un ls : arg list too long... Comment ?

Il semblerait qu'il y ait une légère limitation à ls notre HP-UX. Prenez un répertoire dont le chemin est stocké dans une variable $REPERTOIRE et mettez-y 28000 fichiers représentant 1 To de données...


ls -l $REPERTOIRE/*.txt

ne marche pas


cd $REPERTOIRE
ls -l *.txt
cd -


Marche...

A qui j'envoie la notification de bug ?

Weak coder review

Sometimes it's such a pain in the ass to figure out how your colleagues are weak developers. Worse, they believe they are too smart to ask for help.

Here is the review of today's refactoring session on some ksh scripts.


#!/bin/ksh

##########################
## Variable definition
##########################

logInfo "Variable definition"

SH_DIR=something
BASE_DIR=something/else
SCRIPT_DIR=other/stupid/path

#############################
##Functions
#############################
function sourceLogInitScript {
. $SH_DIR/.logInit
}

################
# Main
################

sourceLogInitScript

#Other stupid code lines and comments


Unfortunately, logInfo is defined in .logInit as are variables BASE_DIR and SCRIPT_DIR. I guess it is too boring to have a look at a script where 50% of the functionality you are scripting is written. Of course, logInfo not found error is displayed at execution, but why giving a fucking damn at errors when you are testing your stuff??? Silly idea, right ?

I avoid mentioning the comments that seem to be there to make the script look bigger and sooo hard to understand...