Tecnología · GUÍA PRÁCTICA
¿sed -i funciona en Linux y falla en macOS? Prueba los límites antes de editar
Identifica la implementación de sed y el argv exacto, previsualiza la transformación y elige una política explícita de copia o temporal.
Cuando sed -i funciona en Linux y falla en macOS, el comando visible no basta. GNU y la familia BSD definen el sufijo in-place de manera diferente, y el shell decide los tokens reales.
Conserva el origen, identifica la implementación y previsualiza stdout antes de probar una rama de copia o sustitución. Ese orden evita una edición destructiva.
Captura implementación y argumentos
Registra la ruta del ejecutable, la versión, el sistema, el shell, el comando exacto y los nombres resultantes. No llames a toda diferencia un problema de comillas: demuestra primero qué sed analizó los argumentos.
Expande variables y matrices del shell antes de cambiar nada. Un comando copiado de Linux puede llegar a sed de la familia BSD con límites de tokens distintos aunque la línea se vea igual.
Separa las reglas del sufijo
GNU sed documenta un sufijo opcional para -i. Sin sufijo sobrescribe sin copia; con sufijo renombra el original. Agrupar opciones cortas cambia el significado: -Ei y -iE no son equivalentes.
El manual de FreeBSD documenta una extensión después de -i. Una extensión vacía evita la copia y una no vacía determina su nombre. Trata la extensión como dato observable.
Previsualiza antes de editar
Ejecuta la expresión sin -i sobre una copia y dirige stdout a un temporal nuevo. Compara salida y entrada, cuenta líneas, revisa codificación y confirma el patrón esperado.
Así separas el programa sed de la sustitución. Si la vista previa falla, corrige el modo regex, escapes, delimitadores o saltos de línea antes de probar edición in-place.
Elige una estrategia acotada
En entornos controlados, detecta la implementación y usa una rama probada con sufijo explícito. Para scripts portables, valida una salida temporal antes de reemplazar.
No dependas solo de sed --version si otra implementación lo rechaza. Usa una prueba cuyo fallo se controle, un contrato de plataforma del build o un flujo estándar con temporal.
Exige prueba final y rollback
Prueba archivos sin coincidencia, con varias, rutas con espacios, salto final y copia previa. Confirma resultado, código de salida y política de backup en cada runner.
Despliega primero en pequeño. El éxito exige contenido correcto, bytes ajenos estables y solo los archivos previstos. Si falla, conserva entrada y argv en vez de reintentar de forma destructiva.
