linux

¿Cómo puedo borrar un archivo de linux que no se deja?

Deja un comentario

Cuando en Linux no puedes borrar un archivo, el problema casi siempre no está en los permisos del fichero sino en los del directorio que lo contiene.

Qué permisos controlan el borrado

En Unix/Linux, para borrar un fichero hace falta permiso de escritura (w) y ejecución (x) sobre el directorio que lo contiene, no sobre el propio fichero. Eso significa que puedes tener un fichero 777 dentro de un directorio 555 y aún así rm dará Permission denied, porque el directorio no es escribible.

Motivos típicos de “Permission denied” al borrar

  1. Directorio sin permiso de escritura
    El usuario no tiene w sobre el directorio que contiene el fichero.
  2. Directorio sin permiso de ejecución
    Aunque parezca raro, sin x no puedes “navegar” la entrada del fichero en el directorio, por lo que rm falla.
  3. Mezcla de permisos y sudo
    Si el fichero o los directorios son propiedad de otro usuario, normalmente necesitas sudo o cambiar propietario/permisos antes de borrar.
  4. Atributos especiales (immutable, etc.)
    En algunos casos el fichero tiene atributos especiales (+i) que impiden borrarlo incluso con permisos de escritura.

Cambiar permisos del directorio antes de borrar

La solución básica es asegurarse de que el usuario tiene permisos de escritura sobre el directorio:

chmod u+w /ruta/al/directorio
rm -f /ruta/al/directorio/archivo

Si quieres borrar todo el contenido de un directorio, suele ser necesario:

chmod -R u+w /ruta/al/directorio
rm -rf /ruta/al/directorio

Bola EXTRA: Hagamos una función de terminal para borrar y chmod en una sola línea

Sabiendo lo anterior, y ante la necesidad de usar varias veces ambos comandos sobre un mismo directorio, he creado una función:

chmodrm() { chmod -R u+w "$1" && rm -rf "$1"}
  • chmod -R u+w "$1" da permiso de escritura al propietario (u) sobre el directorio y todo su contenido.
  • rm -rf "$1" borra el directorio y su contenido recursivamente solo si el chmod tiene éxito (por el &&).

Consideraciones de seguridad

  • Usa esta función solo en directorios donde realmente tengas autoridad para borrar; rm -rf es irreversible.
  • Si el directorio es propiedad de otro usuario, necesitas sudo o cambiar el propietario (chown) antes de chmod -R.
  • En entornos compartidos o de producción, considera usar rm -ri (interactivo) o loggear antes de borrar en lugar de un rm -rf ciego.

Fuentes: StackOverflow | RedHat

js, legacy, typescript

TypeScript nos da la tranquilidad en el frontend

Deja un comentario

Cuando empecé a programar para web me encontraba cómodo con PHP y Javascript, me permitían el salvaje mundo de no definir la estructura de los datos y de reutilizar variables. Mientras, estaba aprendiendo Java y «sufriendo» la definición de clases y tipos. Era joven e inexperto. No sabía que esto está muy bien cuando estás tirando código rápido tú solo. Está bien para prototipar, hacer una prueba de concepto con pocos ficheros y pocas funciones, cuando tienes todo el código en tu cabeza. Ideal para un hackaton o similar.

Pero cuando llegas al mundo real, empiezas a utilizar librerías, a compartir código con otras personas, a tener que entender como funciona código ajeno (a veces sin leer documentación, por que no la hay). Si, ahora prefiero un código que se expresa por si solo, más allá de buenos nombres de variables o funciones, está un buen tipado, entender que puedo esperar de una función y como espera esa función ser usada, construir objetos que tienen sentido.

TypeScript evoluciona JavaScript, de hecho es más «java» ya que no solo tiene orientación a objetos sino que me devuelve a ese fuerte tipado. Sin embargo, los navegadores ejecutan javascript, así que el código TypeScript que hagamos tendrá que llevar una fase de compilación para convertirse en JS. Lo bueno, que en esa compilación saltarán errores de tipado que nos ayudarán a tener un JS más limpio y estable, pillando errores como asignaciones inválidas antes de runtime, lo que reduce bugs en producción hasta un 15-20%.

La curva de aprendizaje es mayor que JS, y quizá podemos entrar haciendo JS (para conocer como funciona y sabiendo que podríamos estar haciendo chapuzas) y luego dar el salto a TS para aprender de interfaces y tipos. Las interfaces definen contratos para objetos/APIs, facilitando el uso de funciones ajenas como cajas negras (sabemos lo que tenemos que darle y tenemos garantizado lo que sale, nos da igual lo que pasa dentro).

La principal desventaja es que hay que preparar un entorno de compilación y eso puede resultar engorroso poner en marcha. Además esa compilación lleva a retrasar unos segundos cada cambio que hagamos en nuestro desarrollo para poder probarlo. Pero si vamos a trabajar con frameworks modernos, con proyectos medianos-grande… no lo dudaría ni un segundo.

Por otro lado, que placer es el autocompletado que te aporta en el IDE poder tener clara la librería que estás usando.

Proyectos legacy: de JS a TS

[Leer más en TypeScript: Migrating from JavaScript]

Lo ideal en un proyecto legacy es ir cambiando piezas poco a poco, no queremos tirarlo todo y empezar de cero. La compilación de TypeScript permite usar código JS puro, pero aquí entraremos en terreno pantanoso que tendremos que andar con cuidado.

Lo ideal en este caso será reemplazar de fuera hacia dentro, ya que el core suele estar fuertemente acoplado. Iremos migrando piezas por su valor en negocio (criticidad, mantenimiento…) a fondo e ir cambiando su nivel de «strictness» de manera local. Creamos types para lo que necesiten estos módulos (que ya se usarán en toda la aplicación) y separamos responsabilidades.

Lamentablemente (o como solución temporal), usaremos el type any con toda relación con el núcleo que no ha sido migrado (dejando anotada esta deuda), pero solo en esas conexiones.

Cuando estén migrados todas las capas exteriores podremos ponernos serios con el core de la aplicación y levantar el nivel de strict de manera global.

php

Yoda conditions, código menos legible pero menos propenso a errores

Deja un comentario

El otro día me encontré leyendo código ajeno de PHP una condición «invertida»: primero se presentaba el valor buscado y luego se comparaba con la variable:

if('aguja' == $pajar){ // la encontraste!

Me dejó completamente descolocado porque supone leer al revés, y es en honor a ese personaje de Star Wars que anteponía predicado a sujeto que se ha nombrado esta manera de hacer las condiciones.

¿Los motivos para usarla? Con operadores de igualdad normales (==) en algunos lenguajes podrías escribir por error if ( $pajar = 'aguja' ), lo que asignaría el valor en vez de comparar (y siempre daría true); sin embargo, si el literal está a la izquierda ('aguja' == $pajar), esa asignación daría un error de sintaxis y el bug saltaría automáticamente.

Fuente: Yoda conditions
​

tips

Primeros pasos para domar un código legacy

Deja un comentario

Me gusta el reto de llegar a un proyecto ajeno y domarlo. Entender como lo diseñaron y ver como mejorarlo. Pero antes de poder ampliar ese código hay que estabilizarlo para poder caminar seguros. El objetivo con el que atacamos ese código es poder tener una base de código entendible y con cobertura de tests que nos dé tranquilidad.

El enfoque es gradual y seguro, priorizando la comprensión del código, las pruebas y la refactorización incremental. Haremos primero los pasos 0, 1 y 2 y luego realizaremos los pasos 3 por bloques de funcionalidad.

Seguir leyendo Primeros pasos para domar un código legacy →
docker, git

Como Docker y buenas prácticas me permiten poner en marcha mi entorno de desarrollo en tiempo record

Deja un comentario

Mi espacio de desarrollo puede ir conmigo a cualquier parte del mundo que tenga conexión a internet (de banda ancha). Obviamente, es mejor tenerlo todo instalado, que sea arrancar y ponerse en manos a la obra. Pero ¿qué pasa si necesito levantar el entorno de desarrollo en un equipo nuevo? Ya sea porque mi equipo se haya roto, lo he perdido o simplemente esté a kilómetros de donde estoy en este momento. Aquí, tener una serie de buenas prácticas me permite levantar mi entorno de desarrollo (o el de alguien de mi equipo) en tiempo record, y marca la diferencia entre estar parado o poder recuperar el control rápidamente.

[Hoy dejaré de lado la solución de tener todo virtualizado en un servidor y tener mi IDE (editor de código) en el navegador. @TODO escribir artículo sobre entorno de desarrollo virtualizado online].

Seguir leyendo Como Docker y buenas prácticas me permiten poner en marcha mi entorno de desarrollo en tiempo record →
tips

La importancia del directorio .well-known en nuestro servidor para conectar servicios de terceros

Deja un comentario

El directorio .well-known es un estándar definido por el RFC 8615 que actúa como un directorio especial ubicado en la raíz de un sitio web, accesible como /.well-known/. Sirve para almacenar archivos de metadatos y configuraciones importantes para diversos protocolos web, como validaciones de certificados SSL, configuraciones de seguridad, autenticación (OpenID, OAuth 2.0) y otras integraciones automáticas entre servicios y aplicaciones.

Este mecanismo permite que aplicaciones, navegadores y servicios automaticen procesos de configuración, validación y descubrimiento de servicios de forma estandarizada, sin necesidad de configuración personalizada para cada caso.

Por ejemplo, aquí podemos dejar archivos como security.txt para indicar como reportar vulnerabilidades, o carpetas como /.well-known/pki-validation/ usadas para validar la propiedad de un dominio al emitir certificados SSL.

Y sin duda es un avance de limpieza frente a dejar estos ficheros en la carpeta raíz.

Usos más habituales

Los usos más comunes del directorio .well-known están ligados a la seguridad, la validación de dominio y la interoperabilidad entre aplicaciones y servicios web modernos.​

  • Validación de certificados SSL/TLS: Autoridades certificadoras (como Let’s Encrypt) solicitan archivos específicos en subcarpetas como /.well-known/acme-challenge/ o /.well-known/pki-validation/ para verificar la propiedad de un dominio antes de emitir un certificado.
  • Validación de email: SMTP Strict Transport Security puede configurar que los servodres solo acepten correos cifrados. /.well-known/mta-sts.txt
  • Archivos de políticas de seguridad: Como security.txt, donde se publica información de contacto para reportar incidentes de seguridad en el sitio, según recomendación RFC 9116.
  • Descubrimiento de servicios de identidad: Protocolos como OpenID Connect y OAuth 2.0 usan rutas como /.well-known/openid-configuration o /.well-known/oauth-authorization-server para que las aplicaciones detecten automáticamente endpoints y configuraciones relacionadas con autenticación y autorización.​
  • Integración de aplicaciones móviles: Android y Apple utilizan archivos en /.well-known/ para validar que un dominio es legítimo y permitir enlaces universales o “deep links”.​
  • Cumplimiento legal y privacidad: Algunas normativas como GDPR han motivado la publicación de información de contacto y políticas de privacidad accesibles públicamente en este directorio.​

Todos estos casos facilitan la automatización, estandarización, y seguridad de procesos web, permitiendo que diferentes servicios interactúen sin intervención manual y de manera segura.

En general, lo ideal es crear esta carpeta y ficheros reales directamente en nuestro servidor y revisar que no hay reglas (en .htaccess o similar) que redirijan el tráfico a esta ruta, impidiendo servir los ficheros.

js, tips

La mejor manera de esperar a que el DOM esté listo y poder manipularlo

Deja un comentario

Aún recuerdo mis tiempos de jQuery (si, esa librería ha sido una gran herramienta durante mucho tiempo) en que había que esperar a $(document).ready() para garantizar que el DOM y las librerías habían cargado para poder ejecutar código y que todo funcionara.

Pero cuando empezamos a poner el javascript al final del HTML (si, fuera del Header) para aliviar los tiempos de carga provocamos que en realidad no hiciera falta esperar, porque si se había cargado ese código es porque ya se había parseado todo el DOM.

Pero ¿eso quiere decir que el DOM está listo? ¿que se han cargado todos los elementos? Pues se han cargado todos los elementos renderizados en servidor, PERO actualmente hay mucho renderizado que se hace en cliente (React, Angular… )

Así que si queremos manipular el DOM, necesitamos garantizar que existe ese elemento que queremos manipular. Puede que se lance un script cuando el DOM está listo pero necesite esperar a que ese elemento esté disponible.

La solución habitual es hacer un bucle con setTimeout que hace una comprobación cada cierto tiempo y se lanza a si mismo si no encuentra el elemento para intentarlo de nuevo.

function check() {
  if (!$('#elementId').size()){
    setTimeout(check, 200);
  } else {
    // el código a ejecutar
  }
}

Y esto puede que funcione, pero no es la manera más eficiente… y con los navegadores modernos puede que falle porque, cuando la pestaña / ventana no esté en primer plano puede que ahorren recursos y no corran ese código suficientemente «rápido».

Así que toca hacer una solución moderna para navegadores modernos, que no dependa de que la pestaña esté funcionando, o de que el timeout se ejecuta a tiempo. Y la respuesta es requestAnimationFrame

Se suele usar para animaciones, garantizando 60 refrescos por segundo. Pero también se puede usar para notificar al código que está esperando.

Así que usaremos algo como:

function check() {
  if (!$('#elementId').size()){
    window.requestAnimationFrame(check);
  } else {
    // el código a ejecutar
  }
}

Y aunque en teoría podría parecer que este código se comprobaría el DOM cada 1/60 de segundo para comprobar el elemento buscado, solo se hará una vez, cuando el elemento sea renderizado.

Y así es la manera adecuada de esperar a un elemento de DOM en los navegadores modernos.

Mas info: Swizec

git

git insteadOf: Jugando con las URLs en git

Deja un comentario

Si te dedicas al desarrollo, tienes que tener algún sistema de versionado de código. Cada cambio registrado, poder hacer ramificaciones de código, integrar código de varias personas…

También puede ser que empieces a tener muchos repositorios de código, y cada uno en un servicio distinto: github, gitlab, bitbucket… o alguno en tus propios servidores.

Hay gente que lo usa para acortar urls y no tener que acordarse de / tener que teclear toda la ruta a sus repositorios.

git config --global url."https://github.com/".insteadOf "gh:"

En mi caso este mecanismo me ha resultado útil cuando las políticas de seguridad del repositorio de trabajo han cambiado de poder usar unas urls a otras (podrían también haberse dado un cambio de ruta en el servidor). Pero no era plan de cambiar todas las referencias en las dependencias, hay demasiados proyectos.

Así, es tan fácil como indicarlo algo como:

git config --global url.https://bitbucket.project-x.info/.insteadof ssh://git@project-x.info:7899/

¿Y si tienes más que referencia a la misma url? Pues toca añadir más entradas a la config de tu cliente git con –add

git config --global --add url.https://bitbucket.project-x.info/.insteadof ssh://project-x.info:7899/

Esta configuración también se puede usar por proyecto añadiendolo al .gitconfig

+ info: Graphite | Kovrinic

wordpress

WordPress: No uses camelCase para tus shortcodes

Deja un comentario

En breve: no utilices camelCase para nombres de parámetros en los shortcodes de WordPress

He estado un rato dado vueltas a un código de shortcode que estaba haciendo. Quería inyectarle un contenido para que lo usara como una propo de schema para mejorar la semántica del código. Esa prop usaba camelCase y decidí que el parámetro llevase el mismo nombre para no liarme… pero cuando capturaba el recogía el parámetro me aparacía con el valor por defecto.

function shortcode_process($atts) {
	$atts = shortcode_atts( array(
		0 => null,
		'name' => null,
		'price' => null,
		'priceCurrency' => null,
	), $atts );
}

Y es que no sabía que los atributos del shortcode de WordPress se pasan a través de la función strtolower() de PHP.

Es raro que use camelCase en PHP, suelo usar snake_case (aunque últiamente en javascript uso camelCase), pero aquí quería usar el mismo nombre que la prop, y Schema.org marca las props en camelCase. Ha sido un rato rascándome las neuronas intentando averiguar si porqué un parámetro estaba pasando correctamente y el otro se quedaba con el valor por defecto, hasta que finalmente he pensado ¿y si es por el casing?

function shortcode_process($atts) {
	$atts = shortcode_atts( array(
		0 => null,
		'name' => null,
		'price' => null,
		'pricecurrency' => null,
	), $atts );
}

Y así era, resulta que los parámetros estaban siendo ignorados porque ya no coincidían con los nombres esperados después de ser convertidos a minúsculas por la función strtolower() antes mencionada.

Así que aquí te dejo la pista para que no pierdas el tiempo que he perdido. Utiliza nombres de propiedads en minúsculas/snake_case en el array shortcode_atts().

js, tips

Chrome dev tools: Como explorar un JSON

Deja un comentario

Si te dedicas al mundo del frontend, seguramente tienes que estar consultando un API REST que te devuelve documentos en formato JSON y en ocasiones querrás comprobar que lo que recibes es lo que esperar y poder explorarlo. Vamos a a ver un par de trucos para atacar rápidamente un JSON gigante usando las Developer Tools del navegador Google Chrome (o Chromium) y facilitarte la vida.

Truco 1: Cargar en el terminal

La consola de las Developer Tools no es solo l lugar donde probar el código, también podemos hacernos.

Con las DevTools abiertas, en la pestaña Network, realizamos la petición al API REST. Entonces abriremos el documento que hemos recibido y nos iremos a la pestaña preview y veremos el JSON en todo su esplendor. Entonces, seleccionando el elemento raíz, abrimos el menú contextual (botón derecho) y elegimos «Store to global variable».

Desde ese momento tendremos una variable (en mi caso fue temp1) con la que podremos trabajar en el terminal. Podremos hacer operaciones de array o de objeto sobre sus elementos y usar el autocompletado para hacer todo el path. Si escribimos el path y damos intro recibiremos el valor de ese elemento en el árbol JSON.

Truco 2: Extraer el path a un elemento

Un caso bastante habitual es tener un elemento bastante profundo en el árbol JSON y no querer tener problemas de erratas al transcribirlo. Puedes sacar el menú contextual del elemento y

Y puedes comprobar que está correctamente escibiendo en la consola:

temp1.PATH_COPIADO

Bola Extra: Una extensión para ver JSON.

Si no quieres tener que hacer el recorrido hasta las dev tools, y quieres ver directamente el JSON al llamar a su url en el navegador de una manera manejable, te recomiendo instalar JSON Formatter.

Truco: puedes expandir y contraer ramas pulsando ctrl para que lo haga con todas las del mismo nivel.