Définition de la variable shell à partir de l'instruction SELECT dans Informix?

Question

J'essaie de prendre le résultat d'une requête et de définir le résultat en tant que variable pour le nom d'un fichier. J'ai lu des articles et j'ai trouvé que la lecture d'une sélection puis la définition d'une variable à partir du résultat pose problème, mais je ne suis pas en train de suivre la procédure.

Si je lance une requête directe ....

echo "SET isolation dirty read; Select * from site;" | dbaccess davedb 

je reçois la réponse suivante qui est prévu.

site_nuber site_ID site_name 

1   1  ALPHA 

J'ai essayé plusieurs variantes de ce qui suit avec DECLARE, INTO ou AS mais rien ne fonctionne. Ce qui suit est l'essentiel de ce que je veux accomplir.

#!/bin/bash 
dateFormat=`date +'%Y%m%d'` 

dbaccess davedb <<! 2>/dev/null 
set isolation dirty read; 

SELECT site_name AS $NAME 
FROM site; 
! 

touch "/export/home/dave/"$NAME"_"$dateFormat.txt 

Answer 1

Il existe plusieurs façons de répondre à cette question.

Je suis très tenté de dire "et c'est pourquoi j'ai écrit SQLCMD vingt (oh, chagrin, non, il y a trente ans - 1986!) Il y a trente ans". DB-Access est très utile à toutes sortes de fins, mais ce type de script shell n'est pas son fort, et SQLCMD a été écrit pour couvrir cette lacune.

NAME=$(sqlcmd -d davedb -e 'set isolation to dirty read' \ 
       -e 'select site_name from site') 

Si l'on suppose que se emparer de SQLCMD (note, ce n'est pas le programme de johnny arrivé ces derniers temps Microsoft du même nom) n'est pas une option, alors vous aurez envie d'envisager comment modifier DB-accès en soumission. Il fait de son mieux pour se défendre!

Étant donné que vous voulez capturer le nom dans une variable shell, vous pouvez peut-être utiliser:

cat <<'EOF' | 
SET ISOLATION TO DIRTY READ; 
OUTPUT TO "/dev/stdout" WITHOUT HEADINGS SELECT site_name FROM site; 
EOF 
dbaccess davedb - 2>/dev/null | 
tr -d ' \n' 

Si vous exécutez ce à partir de la ligne de commande, vous verrez le nom du site immédiatement suivi par votre message (puisque toutes les nouvelles lignes - 5 d'entre elles - ont été supprimées par la commande tr), mais cela n'a aucune importance lorsque vous capturez la sortie dans une variable.

L'instruction OUTPUT est intégrée dans DB-Access (pas le serveur de base de données). Il écrit le résultat d'une instruction SELECT dans le fichier nommé. J'ai appelé "/dev/stdout" qui, sur la plupart des systèmes Unix modernes, est identique à la sortie standard du processus. Le qualificateur WITHOUT HEADINGS fait en sorte qu'il omette les noms de colonnes de la sortie. Cela réduit la quantité de déchets émis par le programme. Si vous n'avez pas /dev/stdout, vous pouvez spécifier un nom de fichier temporaire à la place, puis lire le fichier, mais c'est une nuisance.

Il existe un certain nombre de variantes sur la façon d'alimenter le SQL vers DB-Access. Vous pouvez éviter le cat en utilisant echo (mais il y a toujours un pipeline là), ou en utilisant un Bash here string directement à DB-Access, ou un here document comme entrée standard pour DB-Access, ou créer un somefile.sql contenant le SQL puis en passant somefile.sql (ou même simplement somefile) comme nom de fichier à la place de l'argument -.

Assemblage ceci dans votre script, vous vous retrouvez avec une variante:

dateFormat=$(date +'%Y%m%d') 
NAME=$(cat <<'EOF' | 
SET ISOLATION TO DIRTY READ; 
OUTPUT TO "/dev/stdout" WITHOUT HEADINGS SELECT site_name FROM site; 
EOF 
dbaccess davedb - 2>/dev/null | 
tr -d ' \n') 

if [ -n "$NAME" ] 
then touch "/export/home/dave/${NAME}_${dateFormat}.txt" 
fi 

Le code a été testé avec SELECT SITENAME FROM Systables WHERE tabid = 1 car SITENAME est une fonction intégrée pour Informix qui retourne le nom du serveur (et aussi nom de base de données disponible localement - la base de données omniprésente stores). Il n'est pas clair si votre table Site et colonne site_name stocke cette valeur ou quelque chose d'autre; À bien des égards, cela n'a pas d'importance.