OOo base: retour vers le futur

La version de libreoffice-base actuellement livrée avec Ubuntu 11.04 est cassée en ce sens que les barres d'outils nécessaires pour modifier un formulaire ne s'affichent pas.
Alors, une solution consiste à installer openoffice.org à la place de libreoffice.
Mais tant qu'à faire, plutôt que d'installer la version actuelle (3.3), autant installer la version précédente (3.2.1). En effet, un autre problème se pose pour ceux qui désirent accéder à PostgreSQL via le pilote sdbc: l'accès aux données se fait en lecture seule avec les versions d'openoffice.org et de libreoffice >= 3.3.
Choisissons sur cette page le fichier qui convient à son architecture (OOo_3.2.1_Linux_x86-64_install-deb_fr.tar.gz, si on est en 64 bits).
Après avoir téléchargé le fichier, ouvrons un (émulateur de) terminal, et rendons-nous à l'endroit du téléchargement pour procéder à l'extraction du tar.gz:

toto@rigel: ~$ cd Téléchargements/
toto@rigel: Téléchargements$ tar xzvf OOo_3.2.1_Linux_x86-64_install-deb_fr.tar.gz

L'extraction a créé différents dossiers. Nous devons nous y rendre pour procédons à l'installation:

toto@rigel: Téléchargements$ cd OOO320_m18_native_packed-1_fr.9502/DEBS
toto@rigel: DEBS$ sudo dpkg -i *.deb

Et pour finaliser:

toto@rigel: DEBS$ cd desktop-integration/
toto@rigel: desktop-integration$ sudo dpkg -i *.deb

Reste à régler le problème du pilote sdbc. Recherchons et téléchargeons le paquet debian openoffice.org-sdbc-postgresql_0.7.6+OOo3.2.0-4ubuntu1_amd64.deb (qui convient pour du 64 bits). Essayant d'installer ce paquet, on se heurte à des problèmes de dépendances. Plutôt que de forcer l'installation, il est préférable de procéder en douceur. Créons un dossier de travail et mettons-y  le fichier téléchargé:

toto@rigel: Téléchargements$ mkdir work
toto@rigel: Téléchargements$ mv openoffice.org-sdbc-postgresql_0.7.6+OOo3.2.0-4ubuntu1_amd64.deb work
toto@rigel: Téléchargements$ cd work
toto@rigel: work$

Un paquet debian est une archive "ar" (et non pas "tar").
Procédons à l'extraction:

toto@rigel: work$ ar -xv openoffice.org-sdbc-postgresql_0.7.6+OOo3.2.0-4ubuntu1_amd64.deb
x - debian-binary
x - control.tar.gz
x - data.tar.lzma
toto@rigel: work$

Ce qui nous intéresse c'est le tar.lzma:

toto@rigel: work$ tar -xv --lzma -f data.tar.lzma
./
./usr/
./usr/lib/
./usr/lib/openoffice/
./usr/lib/openoffice/share/
./usr/lib/openoffice/share/extension/
./usr/lib/openoffice/share/extension/install/
./usr/lib/openoffice/share/extension/install/postgresql-sdbc-0.7.6a.zip
./usr/share/
./usr/share/doc/
./usr/share/lintian/
./usr/share/lintian/overrides/
./usr/share/lintian/overrides/openoffice.org-sdbc-postgresql
./usr/share/bug/
./usr/share/bug/openoffice.org-sdbc-postgresql/
./usr/share/bug/openoffice.org-sdbc-postgresql/script
./usr/share/bug/openoffice.org-sdbc-postgresql/presubj
./usr/share/doc/openoffice.org-sdbc-postgresql
toto@rigel: work$

Déplaçons le fichier zip dans le répertoire de téléchargement:

toto@rigel: work$
toto@rigel: work$ mv usr/lib/openoffice/share/extension/install/postgresql-sdbc-0.7.6a.zip ../

Nous aurons ainsi plus de facilité pour ajouter l'extension dans openoffice via "Outils-> Gestionnaire des extensions"
Nous pouvons maintenant détruire le répertoire de travail work.

Pilote postgresql sdbc 64 bits

Dans le billet Connecter openoffice à PostgreSQL, nous avons donné un lien permettant de télécharger le pilote sdbc.

Hélas, le pilote ainsi obtenu ne fonctionne pas si on est en 64 bits.

Certaines distributions fournissent un paquet 64 bits qui délivre le pilote en question. Par exemple chez Ubuntu, il s'agit du paquet libreoffice-sdbc-postgresql. Pour d'autres distributions ce paquet n'existe pas.

Voici comment contourner le problème. Ceci a été testé et fonctionne dans le cas de Fedora 15.

Tout d'abord, rechercher et télécharger, par exemple, le paquet libreoffice-base-drivers-postgresql-3.3.1.2-1.2.3.x86_64.rpm. Il s'agit d'un paquet openSuse.

Ensuite, dans un terminal, se rendre là où le paquet est téléchargé:

$ cd ~/Téléchargement 
$ rpm2cpio libreoffice-base-drivers-postgresql-3.3.1.2-1.2.3.x86_64.rpm | cpio -ivd
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b/META-INF
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b/META-INF/manifest.xml
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b/description.xml
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b/postgresql-sdbc-impl.uno.so
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b/postgresql-sdbc.uno.so
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b/postgresql-sdbc.unorc
./usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b/postgresql.xcu
1779 blocs
$

La commande rpm2cpio convertit le paquet RPM en archive cpio, archive qui est transmise à la commande cpio pour extraction. La commande cpio a créé dans "Téléchargement" toute une série de répertoires. Nous allons en premier ramener le répertoire "postgresql-sdbc-0.7.6b" dans "Téléchargement", puis créer le fichier zip adéquat:

$ mv usr/lib64/libreoffice/share/extensions/postgresql-sdbc-0.7.6b .

$ zip -r postgresql-sdbc-0.7.6b.zip postgresql-sdbc-0.7.6b

adding: postgresql-sdbc-0.7.6b/ (stored 0%)

adding: postgresql-sdbc-0.7.6b/postgresql-sdbc.unorc (stored 0%)

adding: postgresql-sdbc-0.7.6b/description.xml (deflated 52%)

adding: postgresql-sdbc-0.7.6b/META-INF/ (stored 0%)

adding: postgresql-sdbc-0.7.6b/META-INF/manifest.xml (deflated 62%)

adding: postgresql-sdbc-0.7.6b/postgresql-sdbc-impl.uno.so (deflated 68%)

adding: postgresql-sdbc-0.7.6b/postgresql.xcu (deflated 57%)

adding: postgresql-sdbc-0.7.6b/postgresql-sdbc.uno.so (deflated 71%)

$

Pour terminer, il suffit de procéder comme indiqué dans le billet Connecter openoffice à PostgreSQL:

$ cd $(dirname $(which soffice));cd $(ls -l soffice | sed -r 's/^.*>.(.*)soffice$/\1/')
$ unopkg add ~/Téléchargement/postgresql-sdbc-0.7.6b.zip
$

Il nous est bien sûr loisible de plutôt procéder à l'ajout l'extension via le Gestionnaire des extensions (menu Outils) de Libreoffice.

Vous avez dit sourcer?

Pour mener à bien une compilation, nous avons besoin de définir toute une série de variables d'environnement. Les définitions de ces variables se trouvent par exemple dans un fichier nommé def-var:

export QTDIR=`kde4-config --qt-prefix`
export KDEDIR=`kde4-config --prefix`
export KDEDIRS=$KDEDIR
export KDE_BUILD=$KDEDIR
export DBUSDIR=$KDEDIR
export LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=$DBUSDIR/lib/pkgconfig:/usr/lib/pkgconfig
export PATH=$QTDIR/bin:$KDEDIR/bin:$PATH

Si nous exécutons def-var dans un terminal et que nous regardons ensuite ce qu'il en est au niveau des variables d'environnement existant dans le terminal, rien n'est changé.
Alors comment procéder? Taper toutes ces commandes?
Non, bien sûr: il existe une autre méthode.

Bon, reprenons en partant d'un fichier un peu plus ludique: le fichier bjr:

echo $PPID-$$
echo Saisis un nom $moi
read moi
cat << FIN
Toujours saluer le directeur:
Bonjour $moi
FIN

situé dans /home/toto/test.
Ce fichier contient toute une série de commandes.
Elles sont là, déjà écrites dans le fichier! Alors pourquoi les retaper?
Il suffit d'indiquer à bash que bjr constitue une source de commandes:

L'output de la commande echo est affiché en premier. Puis la commande "read moi" provoque l'affichage du curseur: le système est en attente de ce que nous allons taper au clavier afin de le mettre dans la variable moi:

Terminons la saisie par un appui sur ENTER:

Tapons effectivement à l'écran la première commande de bjr:

Le résultat est le même:  2849 est le pid du shell bash dans lequel nous sommes et 2838 celui de son processus parent (par exemple konsole ou gnome-terminal)
Lorsque bjr est sourcé, tout se passe comme si les commandes qu'il contient étaient tapées à l'écran. Ainsi la variable moi est maintenant définie dans le shell bash (pid 2849) avec la valeur "Ahuri".

Le mot "source" étant très long (et donc fatiguant à taper), il est le plus souvent remplacé par un point ("."):

Nous constatons que la variable moi est bel et bien définie (elle contient le mot "Ahuri") avant même l'exécution de la commande read

Et si nous exécutions bjr en tapant tous simplement son nom, comme pour n'importe quelle commande?
Problème:

C'est normal, bjr n'est pas trouvé car /home/toto/test ne figure dans la variable d'environnement PATH qui contient l'ensemble des répertoires où le système recherche les commandes.
Par curiosité, examinons le contenu de PATH:

/home/toto/test n'y figure évidemment pas, mais bien à toutes fins utiles /home/toto/bin.
Ainsi nous pourrions créer le lien symbolique qui convient.

ln -s ../test/bjr ../bin

Mais la réponse classique au problème consiste à indiquer au système où se trouve exactement la commande à exécuter en tapant:

/home/toto/test/bjr

ou plus court:

./bjr

En fait c'est la même chose:

Nous affichons d'abord les inodes des différents fichiers du dossier (y compris les fichiers cachés). En faisant une recherche sur l'inode 1717900 nous voyons que le fichier "." n'est autre que le dossier dans lequel on se trouve (/home/toto/test).
Ceci est bien connu et a déjà été expliqué dans un autre billet.

Le point (.) peut donc être mangé à plusieurs sauces.

Résumons:
. bjr : le point remplace la commande "source". bjr sera sourcé.
./bjr : le point remplace (ici) /home/toto/test. bjr sera exécuté.

Procédons à l'exécution (!):

Nouveau problème! Et oui: personne n'a le droit d'exécuter ce fichier, même pas le root.
Avant de procéder il faut d'abord donner le droit d'exécution sur bjr (avec la commande chmod +x bjr):

Intéressons nous à ce que vaut maintenant la variable moi dans le shell bash de base:

C'est encore la valeur résultant du "read" lorsque bjr a été sourcé pour la deuxième fois.

Constatations:

• Les différentes commandes du script bjr, s'exécutent au sein d'un sous-shell (pid 2946) dérivé du shell bash principal (pid 2849).
• Dans ce sous-shell, la variable moi n'est au départ pas définie (elle prend ensuite la valeur Jules).
• L'exécution de bjr ne modifie pas la valeur de la variable moi dans le shell bash principal (contrairement à ce qui se passe lorsque bjr est sourcé).

La variable moi n'est pas définie au départ dans le sous-shell où bjr tourne car ce n'est pas une variable d'environnement. Et quand bien même l'aurait-elle été (un petit export moi tapé à l'écran et hop!), cela aurait changé quoi ?

• Elle aurait alors été définie d'emblée dans le sous-shell 2946 et la ligne 2 du résultat de l'exécution de bjr aurait été:  Saisis un nom Patate
• Sa valeur serait comme avant restée inchangée au niveau shell maître

Un changement de valeur dans un sous-shell ne se répercute pas dans le shell parent.

Afin de consolider toutes ces notions, raisonnons maintenant sur un cas un peu plus compliqué, metttant en scène le fichier lbjr:

echo $PPID-$$
echo Bonjour $moi
. defvar
./bjr
echo Il répondra: appelez-moi $moi

et le fichier defvar

echo $PPID-$$
moi=Big\ Boss

(Remarquons le caractère d'échappement "\" qui enlève au blanc qui suit le mot "Big" son rôle de séparateur)

Exécutons lbjr. Mais comme nous n'avons pas le courage de le rendre exécutable, procédons en utilisant la commande bash:

Analysons le résultat:

• ligne 1: lbjr s'exécute dans un sous-shell (pid 2949)
• ligne 2: dans ce sous-shell la variable moi n'est pas définie
• ligne 3: defvar est sourcé au niveau du sous-shell et la commande echo de defvar s'exécute bien dans ce sous-shell
• ligne 4: bjr s'exécute dans un sous-sous-shell (pid 2950)
• dernière ligne: bjr est terminé, on est retombé dans le sous-shell 2949 et la variable moi est est maintenant définie dans ce sous-shell car defvar y a été sourcé.

Si defvar n'avait pas été sourcé, mais exécuté (commande ./defvar au lieu de . defvar), la variable moi serait restée non définie dans le shell pid 2949.

Nous n'avons pas eu le courage de rendre lbjr exécutable, mais bash c'est quand même très long à écrire: pourquoi ne pas utiliser sh?
Après tout sh est maintenant le plus souvent un simple lien vers bash:

Et pourtant:

Et oui : le comportement de bash change suivant la façon dont il est invoqué.
Le mieux est d'indiquer précisément l'endroit où se trouve le fichier à sourcer, ce qui évite ce genre d'erreur.

Pour en revenir avec le problème qui a motivé ce billet, la solution est bien évidemment de sourcer def-var dans le shell bash de travail. Les variables d'environnement, nouvelles où modifiées, seront ainsi présentes pour tous les processus fils