No usar palabras reservadas como identificador de nada

Ayer me pasó algo que me tuvo de cabeza varias horas. Estaba cargando un modelo de datos en Oracle (un 10g XE que instalé para tener en la oficina), y al momento de crear unos triggers para unos valores autonuméricos secuenciales, me arrojó un error para ciertas tablas.

CREATE SEQUENCE SEQ_tbl_password_ID INCREMENT BY 1 START WITH 1;

CREATE TABLE tbl_password(
pwd_id INTEGER NOT NULL,
usr_id INTEGER NOT NULL,
oldpassword VARCHAR2(32),
timestamp TIMESTAMP
);

ALTER TABLE tbl_password ADD PRIMARY KEY(pwd_id);

ALTER TABLE tbl_password ADD FOREIGN KEY(usr_id) REFERENCES tbl_user(usr_id);

CREATE INDEX idx_pwd_usr_id ON tbl_password(usr_id ASC);

Resultaba particularmente extraño pués todos los triggers tienen la misma estructura base. Un compañero de oficina me señaló que alguna vez tuvo un problema similar y se debía a que la estructura de la tabla tenía una palabra reservada en algún lado.

Efectivamente, si miran con atención, hay un campo de nombre "timestamp". Oracle no se hace mayores problemas al crear una tabla con campos cuyo nombre sea una palabra reservada, sin embargo por lo visto internamente SI restringe su uso.

Solución al problema: Cambiar el nombre del campo de manera que no sea una palabra reservada.

Es uno de esos problemas que uno no debiera tener, ya que normalmente nunca interesaria usar un campo con una palabra reservada como nombre, pero obviamente es un mero supuesto que hasta donde he logrado saber, no está 100% contemplado.

Cambiando permisos con chmod

Una operación bastante típica que me toca realizar, en ambiente *nix, bastante seguido es el cambio de permisos de directorios y archivos. Típicamente es asignar permisos de lectura y ejecución para todos los usuarios. No voy a explicar como usar el chmod básico, pero si me referiré al no tan conocido (al menos por aquí) sticky bit y el set-ID.

Tomemos el caso de los scripts shell para iniciar algún servicio. Particularmente puede interesarnos que todos los usuarios puedan ejecutarlos, pero que el proceso quede corriendo bajo algún usuario o grupo en particular, y además nos interesaría que el único (ir)responsable de hacer determinadas barbaridades sobre el archivo o directorio, como por ejemplo cambiarle el nombre, eliminarlo o desvincular su enlace simbólico, sea el propietario original.

Para ello usaremos el sticky bit y el set-ID.

El sticky bit (parámetro t del comando) nos asegura lo segundo, es decir que el propietario sea el amo y señor de los archivos y directorios a los cuales se aplique. Debo ser sincero al reconocer que esto es lo poco y nada que entendí del manual.

El set-ID (parámetro s del comando) nos asegura que cada vez que ejecutemos el script este quede con el usuario o grupo dueño del archivo.

Con un ejemplo, supongamos que tenemos en nuestra carpeta /etc/init.d el script para iniciar el servidor de aplicaciones JOnAS, archivo al que nombraremos originalmente jonas . Dado que es un servicio querremos que corra como usuario root , así que lo creamos usando ese usuario, o en su defecto cambiamos el usuario usando el comando chown .

Entonces desde una consola y estando conectados al sistema como root, ejecutamos la siguiente secuencia de comandos:

chmod 755 jonas
chmod u+st jonas

Y listo. Explicacion:
chmod 755 jonas : asigna permisos de ejecución y lectura para todos los usuarios, el propietario (en este caso root ) además puede excribir sobre el archivo.
chmod u+st jonas : operando sobre el usuario (por eso el parámetro u ) le fija un sticky bit y además un set-ID , de manera que al ejecutarse el script el proceso asociado queda corriendo como si hubiera sido ejecutado por el usuario root .

De sobra está mencionarles que existe una dosis de peligro al asignar permisos de esta manera, pués usuarios maliciosos desearían poder mal utilizar este poder, pero eso no es de mi responsabilidad :)

script.sh: VAR=value: is not an identifier

Hace poco tiempo me enfrenté al siguiente problema:

./jonas: JONAS_BASE=/JONAS/: is not an identifier

Esto ocurrió al intentar ejecutar un servidor de aplicaciones JOnAS recien instalado (básicamente, recien copiada la carpeta de instalación en la máquina destino) en una Slowlaris.

Después de darle unas vueltas y de tratar de corregir el error seteando desde dentro del script la variable con las clásicas:

export JONAS_BASE=/JONAS/
o
setenv JONAS_BASE=/JONAS/

no hubo caso.

La solución:

JONAS_BASE=/JONAS/
export JONAS_BASE

Es decir, primero se asigna la variable, de manera de asegurar su existencia, y luego se le setea el valor correspondiente. Ni idea porqué se da ese comportmiento, pero al menos ahora sabemos como solucionar el problema.