[Script - Ksh] su et sqlplus [Résolu]

[tck-lt]

Bonjour,

je galère sur un truc qui à mon avis doit être tout bête.

Quand je suis en root et que je tape successivement :

Code :

1
2
3
[root@XXXXX log_jour]# su - userl --command="sqlplus form/form <<FIN
> select to_char(sysdate,'dd.mm.yyyy hh24:mm:ss') from dual;
> FIN"

je n'ai aucun souci :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 10 16:29:37 2011
 
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
 
 
Connecte a :
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
 
SQL>
TO_CHAR(SYSDATE,'DD
-------------------
10.02.2011 16:02:37
 
SQL> Deconnecte de Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

En revanche quand je l'intègre dans un script (en environnement ksh), je n'arrive pas à obtenir le résultat de la requête, il bloque sur le login de connexion sqlplus, il me le redemande comment s'il s'était arrêté à la commande sqlplus. Du coup j'ai essayé un paquet de solutions mais pour le moment je n'ai pas trouvé la bonne. Il lui faut à priori des retours à la ligne dans le code, j'ai donc tenté cela sans succès :

Code :

1
2
3
su - userl --command="sqlplus form/form <<FIN\r\n
select to_char(sysdate,'dd.mm.yyyy hh24:mm:ss') from dual;\r\n
FIN"

Le problème à mon sens se situe au niveau des guillemets, qu'en pensez-vous svp ?

NB : j'ai créé un autre script contenant ma commande sqlplus en totalité (sans les retours chariots). Quand j'appelle ce script avec un

Code :

su - userl -c monscript

ça fonctionne. Ce qui m'embête c'est que ça fait un script qui appelle un autre script et vu que je dois le faire régulièrement pour d'autres tâches, ça va m'en faire une sacré liste (et donc un sacré bordel).

[Alek-C]

Pourquoi utiliser su plutôt que sudo ?

[tck-lt]

Bonne question à laquelle je n'avais pas pensé. En fait je migre des batchs qui sont sous AIX 5.3 sur de la RHEL 4 et le sudo n'existe pas sous mes AIX.
Je vais adapter.

[frp31]

le problème est tout connement un problème de quotage


gestion des ",`,'
tu peux les protéger d'interprétation avec des \ par exemple.

[tck-lt]

C'est ce que je signale dans mon post que c'est un problème de quote mais lequel, c'est-à-dire, qu'est-ce-qu'il manque ou qu'est-ce-qu'il y a en trop ? (je n'ai exposé ici qu'une des possibilités que j'ai tentées.

[tck-lt]

j'ai tenté d'utiliser sudo, l'inconvénient est que je ne me retrouve pas avec mes variables d'environnement à l'exécution de la commande, je dois zapper une option je pense. J'ai bien vu le -H mais ça c'est seulement pour fixer son Home Directory non ?

[Alek-C]

non, tu ne rates rien je crois : il faut charger ton .profile avant de faire la commande si tu as besoin de variables à l'intérieur... mais normalement, tu ne devrais pas

[tck-lt]

ok je verrai ça demain pour charger mon .profile, c'est obligatoire pour moi car c'est l'environnement bien précis d'une base Oracle (avec définition de l'ORACLE_SID, ORACLE_HOME etc...)

[Alek-C]

ouais, mais normalement, ça ne devrait pas être dans le .profile ce genre de chose : c'est une mauvaise pratique !

[tck-lt]

où est-ce-que je peux le mettre si ce n'est dans le .profile de mon user Oracle ?

[Alek-C]

Personnellement, je fais un fichier à part, situé à un emplacement accessible par tout le monde ayant besoin du fichier, ce qui permet de n'avoir qu'un seul et même fichier à charger quelque soit l'utilisateur souhaitant accéder à Oracle.

Pour te donner un exemple, chez un client, ils mettaient cela dans /var/opt/oracle/...
Il y avait un script qui permettait de charger l'environnement requis selon les besoins, mais tu peux simplifier en ne mettant que plusieurs fichiers de profile.

Les avantages sont d'une part que tu n'as qu'un fichier à maintenir et d'autre part, tu sépares bien le contenu de ton .profile qui ne concerne "que" des trucs liés au shell du contenu qui concerne les bases de données ou autre.