Recetas de sed (stream editor)

Recetas de sed (stream editor)

sed es un editor de flujo: Lee líneas de la entrada estándar o de un fichero, le aplica una serie de comandos especificados en un script y vuelca por su salida estándar el resultado de ejecutar dichos scripts. Esto lo hace de una sola pasada, sin necesidad de leer el fichero varias veces. Este es un pequeño resumen de alguno de los problemas y las soluciones para las que he usado el sed. Esta entrada me servirá de recordatorio, ya que no es una herramienta de la que tengo que hacer uso habitualmente.

Esta será una entrada dinámica, que iré ampliando poco a poco. Ya os digo que sed no es uno de mis comandos habituales, pero si lo uso de vez en cuando para ciertas cosas.

Índice

• Opciones línea de comandos
• Añadir un texto al final de todas las líneas de un fichero
• Borrar espacios al comienzo de una línea

Opciones líneas de comando

Las opciones básicas para ejecutar sed son las siguientes:¹

sef [-n] script [fichero...]
sed [-n] -e script [-e script]... [-f fichero_script]... [fichero...]
sed [-n] [-e script...] -f fichero_script [-f fichero_script] [fichero]

Añadir un texto al final de todas las líneas de un fichero

Supongamos que tenemos un fichero de texto, datos.txt , que queremos añadir al final de cada línea <br\/> - el fin de línea de html. Si el contenido es:

línea 1
línea 2
línea 3

Si ejecutamos el comando:

sed -e 's/$/<br\/>/' datos.txt

El resultado será el siguiente:

línea 1<br/>
línea 2<br/>
línea 3<br/>

El script s/$/<br\/>/ sustituye (comando s) el fin de línea ($) por <br\/>

Borrar espacios al comienzo de una línea

Supongamos que tenemos un fichero texto.txt de esta guisa y queremos borrar todas las líneas al comienzo del mismo:

     Línea 1
   Línea 2
 Línea 3

Pues esto se puede hacer con sed con la siguiente orden:

sed -e 's/^ //' texto.txt

Ojo con el espacio entre ^ y /. El resultado de la operación será:

línea 1
línea 2
línea 3

Notas

1. Los corchetes indican que el parámetro o el argumento es opcional

fish shell: Notas

fish es un shell para sistemas operativos de tipo Unix: Un programa que se encarga de aceptar la entrada del usuario y ejecutar las órdenes que éste le da y que sirve de interfaz en modo texto con el sistema operativo. Al contrario que otros shell, este no deriva de la familia de Bourne Shell ni de la de C Shell, sino que implementa su propia sintaxis para hacer un intérprete de comando lo más sencillo y amigable que se pueda.

Este shell me lo descubrió un compi de trabajo. Me llamaba bastante la atención como usaba el resaltado de sintaxis para señalar cada parte de la línea de órdenes, como funciona el autocompletado de comandos y como recuerda éstos en función del contexto. Así que decidí probarlo unos días. Lo que no hice fue cambiar con chsh el shell por defecto de mi usaurio, sino decir al emulador de terminal que uso, iTerm2, que ejecutase fish en vez bash.

Al ser un programa de código abierto lo podemos compilar de las fuentes o usar uno de los paquetes precompilados para diferentes plataformas que existe: Diversas distribuciones de Linux, FreeBSD, macOS o Windows. En mi caso, puesto que uso macOS opté por la versión precompilada en formato pkg que se instalará en /usr/local/bin.

En estos meses que he usado fish, las ventajas que le veo son:

• Un sistema de autocompletado de comandos y parámetros mucho más cómodo que el de bash.
• El uso que realiza de la sintaxis de colores para distinguir los parámetros, el comando que se está ejecutando o el comando que ha fllado.
• La posibilidad de ir completando por argumentos la línea de comandos.
• En lo poco que lo he usado para hacer shell script, la ausencia de quotes o construcciones estrañas que nos encontramos en bash.

Por otra parte, su principal desventaja ees no ser parecido al Bourne Shell o al Csh, con lo cual entramos en el terreno de los shell exóticos: No lo usa tanta gente y hay menos recursos para poder aprender.

Mi idea es ir anotando en esta entrada las cosas que vaya usando de fish, así como poner traducciones de comandos que se utilizan en bash (derivado del Bourne Shell) a fish.

Algunos ejemplo de las capacidades coloreado de sintaxis en función de la parte del comando que se trate. Todo esto es configurable con temas que se pueden instalar y configurar a nuestro gusto.

⋊> ~ ls -al /usr/local/bin/fish*
 ~/D/b/002 - icewinddale echo $PATH
~/D/b/002 - icewinddale echo (pwd)
⋊> ~/D/b/002 - icewinddale open blog2.html
⋊> ~/D/b/002 - icewinddale echo "Drizz

A partir de ahora, la entrada la voy a dividir en diferentes epígrafes donde voy a ir anotando lo que voy aprendiendo sobre este shell y como se compara con otros shells. Veréis esta entrada incompleta porque voy a ir escribiendo sus apartados conforme vaya leyendo y probando las cosas.

Ejecutando comandos

Lo primero que va a llamaros la atención cuando se ejecuta un comando es que el color de lo que estamos escribiendo va a cambiar. Si lo que escribimos no se corresponde con ningún comando que el sistema pueda ejecutar, veremos en rojo el comando. fish soporta tanto recomendaciones cuando empezamos a escribir comandos como autocompletado de los mismos cuando se pulsa la tecla TAB, como ocurre con otros shells. Podemos aceptar las sugerencias que nos ofrece fish pulsando → en nuestro teclado. En caso que queramos ir saltando de parámetro en parámetro usamos ALT + →

El autocompletado con la tecla TAB también funciona para las variables de entorno.

La redirección de entrada y salida se hace en fish así. La diferencia es que aquí se usa ^ para redirigir la salida estándar de error (en bashm, por ejemplo se usa 2>h;).

awk < file.in > file.out ^ file.err

Se puede concatenar comandos usando el punto y coma. El valor devuelto por los comandos se almacen a en la variable $status. En los shells compatibles con Bourne Shell la variable es $?.

$ echo "Hi!";echo $status
Hi!
0

Aparte del clásico uso de * y ? para hacer globing para seleccionar nombres de ficheros, fish tiene otra interesante opción que es **. Cuando se usa este patrón, fish bajará por el árbol de directorio buscando aquellos ficheros y directorios que coincidan con el patrón. Por ejemplo, el siguiente comando recorre el árbol de directorios desde la ruta actual e imprime los ficheros y directorios que terminen en .deb:

ls **.deb

Para ejecutar comandos y quedarnos con el resultados la construcción que utiliza fish es (), frente a las backstick `` de bash. Por ejemplo:

# En fish imprimirá la ruta actual
$ echo (pwd)
/home/ubuntu
# El equivalente al comando anterior en bash
$ echo `pwd`
/home/ubuntu

Una diferencia importante es que esta sustitución no funciona dentro de cadenas de texto delimitadas por comillas, así mientras que en bash se puede hacer:

# En bash
$ echo "La ruta es `pwd`."
La ruta es /home/ubuntu.
# En fish
$ echo "La ruta es "(pwd)"."
La ruta es /home/ubuntu.

Variables de entorno

Las variables en fish son listas. Eso se puede ver fácilmente con la siguiente secuencia de comandos:

$ echo $PATH
/home/ubuntu/bin /home/ubuntu/.local/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin
$ echo $PATH[2]
/home/ubuntu/.local/bin
$ echo $PATH[-2]
/usr/local/games
$ echo echo $PATH[1-2]
/home/ubuntu/bin /usr/local/games

Si el índice es negativo, se empieza a contar desde el final, mientras que también se permiten rangos

set es la orden del shell que se usa para manejar las variables. Por ejemplo, si se quiere crear una variable que tenga la ruta actual del sistema. Si se usa sin parámetros, nos imprimirá todas las variables que hay en el sistema ordenadas por orden alfabético:

$ set
MD_DURATION 121
COLORFGBG '15;0'
COLORTERM truecolor
COLUMNS 87
...

Las variables pueden tener tres posibles alcances, aparte de poder ser exportadas - es decir, estár disponible para los subprocesos que se lance desde el shell o no -. Los posibles alcances de la variables son:

• locales, se crean pasando el parámetro -l. La variable sólo es válida en el bloque actual de código.
• globales, se crean usando el parámetro -g. El alcance será global: La variable estará disponible durante la ejecución del shell una vez que se ha declarado.
• universal, se crean con el parámetro -U. Estarán disponibles en todos los procesos fish que esté ejecutando el usuario en ese momento.

Ejemplos:

# Este es un ejemplo de local. Puede verse como el valor no se ve fuera del bloque
$ echo "Start";begin set -l VPATH (pwd);echo $VPATH; end;echo "VALUE:$VPATH"
Start
/Users/terron
VALUE:
# Este es global. Ahora si veremos el valor
$ echo "Start";begin set -g VPATH (pwd);echo $VPATH; end;echo "VALUE:$VPATH"
Start
/Users/terron
VALUE:/Users/terron
# Por último -U la crearía universal, estaría disponible en todos los shells
set -U VPATH (pwd)

Para exportar una variable y hacerla disponible a los subprocesos que se están ejecutando, se utiliza el parámetro -x. Para borrar una variable del entorno se utiliza -e:

# Este comandio ejecuta bash y hace que muestre las variables
# de entorno. Podemos ver la que hemos exportado, VPATH
$ set -gx VPATH (pwd) ;/bin/bash -c export|grep VPATH
declare -x VPATH="/home/drizzt"
# Para borrar
set -gx VPATH (pwd)
echo $PATH
/home/ubuntu
set -e VPATH
echo $VPATH

Copiar al portapapeles local desde una máquina remota

OS X tiene dos comandos , pbpaste y pbcopy que sirven para controlar el portapapeles desde la línea de comandos. De igual manera, en entornos Xwindow existe el comando xclip o xsel para manejar el portapepeles desde la línea de comandos. Estos comandos nos funcionan en la máquina local. Pero, ¿sería posible copiar o pegar en el portapapeles local desde una máquina remota a la que nos hemos conectado a través de ssh.

Pues si el emulador de terminal que se está usando soporta los códigos de control ANSI, concretamente los agrupados bajo el epígrafe OSC, operating system control. Se obtiene mandando la secuencia ESC]52.

El emulador de terminal debe de soportar la secuencia de código OSC 52 para que funcione. Por ejemplo, el iTerm2 la soporta pero debe de activarse en Preferences ࢐ General ࢐ Application in terminal may access clipbpard, ya que puede tener implicaciones de seguridad si nos conectamos a un ordenador en el que no confiemos.

Un ejemplo de como usar esa secuencia de control para copiar el hostname de la máquina:

$ printf "\033]52;p;$(hostname|base64)\033\\"

Hay que tener en cuenta que:

• La secuencia \033 es ESC en octal.
• Los datos deben de estar codificado en base64.
• El texto debe acabar en la secuencua ST que es ESC\.
• En teoría, la operación de paste es sustituir la secuencia de base64 por ?. Sin emnbargo esta secuencua no está implementada en iTerm2. Parece ser que bajo tmux estas secuencias funcionan correctamente, con lo cual, tendré que probar más adelante.

Referencias

1. Control sequences: Operating System Commands

Repositorio con el código fuente de Unix los últimos 44 años

Diomidis Spinellis ha realizado un inmenso trabajo de recopilación del código fuente de Unix desde su concepción y primera versión en 1972 en Bell Labs hasta el actual FreeBSD 10.x. Las versión está ordenadas en el proyecto Unix History Repository en github. Toda una delicia para aquellos que quieran estudiar el origen Unix. El autor del mismo ha publicado un artículo titulado A Repository with 44 Years of Unix Evolution describiendo el proceso de creación del mismo. Tiene un gráfico muy chulo donde se puede ver la relación de las diferentes versiones.

En este repo no está incluido Linux - que es un clon de Unix - ni los sistemas Unix que derivaron de System V. Ah, ojalá Microsoft hiciese lo mismo con Windows, al menos sus versiones antiguas :)

Multiplexar conexiones ssh

Las últimas versiones de OpenSSH tienen una funcionalidad que permite usar una única conexión ssh para multiplexar varios canales. Se abre y autentifica la primera conexión, y de manera automática, se usa ésta para establecer el resto de canales con la mísma máquina. Es el mismo mecanismo que se utiliza en el forwarding de X11 pero aplicado a todas las conexiones ssh.

Cuando se configura de esta manera el ssh, se establece una conexión master la cual abre un socket Unix y se pone a la escucha en el mismo. Cuando se quiere conectar con la misma máquina, el proceso ssh intentará usar este socket. En caso de que no se pueda, realizará la conexión de manera habitual en función de como hayamos configurado la multiplexación de conexiones.

Para configurar la multiplexación de conexiones hay que modificar el fichero $HOME/.ssh/config y usar las opciones ControlMaster, ControlPath y ControlPersist. Si queremos que sólo estén activas estas opciones para los host de la red 192.168.120.0/24, sería necesario modificar el fichero de la siguiente manera:

host 192.168.120.*
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 300

Controlmaster activa la multiplexación de conexiones y se activa en modo auto. Esto quiere decir que ssh intentará usar la compartición de conexiones y si no está disponible, usará la conexión normal. ControlPath establece la ruta donde se creará el socket Unix que crea ssh para escuchar conexiones y multiplexarlas. Como puede verse en la ruta existe ciertas plantillas que se sustituyen por sus valores: %r es el usuario remoto usado para conectar, %h es el nombre del host y %p es el puerto remoto que se está usando. ControlPersist controla el comportamiento del ssh una vez que se ha cerrado la conexión master. Si vale yes, ssh pasa a segundo plano de manera indefinida, esperando más conexiones, si vale no se cerrará la conexión y en caso de que especifique un valor de tiempo, estará en segundo plano el tiempo que se especifique y finalizará si no hay nuevas conexiones o tráfico.

En la primera captura de pantalla se ve dos conexiones ssh sin compartir el socket. En la segunda se puede ver la multiplexación de conexiones con netstat -na --inet (las opciones de este comando son sólo válidas en Linux)

ssh sin multiplexar

ssh multiplexado

Usar screen para tener ventanas divididas (regiones)

Actualmente multitud de personas utilizan entornos gráficos bajo Unix para realizar sus tareas. Sin embargo, muchos todavía usamos múltiples terminales de texto y herramientas en líneas de comando para realizar nuestro trabajo, puesto que con esta interfaz se puede ser muy productivo. Desde hace muchos años existe una utilidad que nos permitía tener ventanas bajo una interfaz basada en aplicaciones de terminal en modo texto que es GNU Screen.

Esta utilidad nos permite crear ventanas y navegar entre ellas. Dentro de cada ventana se ejecuta una shell donde vamos realizando nuestras tareas, todo en una terminal en modo texto. Además, se puede dejar la aplicación corriendo en segundo plano, pudiendo recuperar más tarde la sesión completa. Normalmente, la tecla de control (configurable) que utiliza screen para sus comandos es control-a , que voy a abreviar como C-a.

Una característica que tiene screen es el el uso de regiones, que permite mostrar más de una ventana en la terminal que se esté usando. Este funcionalidad es muy útil, por ejemplo, cuando se está conectado a un sistema remoto, se están ejecutando ciertas órdenes y queremos ver los ficheros de registro que se van generando. Si, esto se puede hacer usando varias conexiones contra el sistema remoto, pero con la ayuda de screen sólo se neceita una conexión y la utilidad.

Los comandos que nos permiten crear estas regiones son:

• C-a S Divide una ventana en dos regiones
• C-a X Elimina la región actual.
• C-a <tab>Pasa a la siguiente región.
• C-a C-cCrea una nueva ventana con un shell en la región actual.

Por ejemplo, tengamos la siguiente captura de pantalla:

Para llegar a esta configuración:

1. Ejecutamos screen
2. Dividimos la ventana actual en dos regiones: C-c S
3. Pasamos a la región nueva: C-c <tab>
4. Creamos una nueva ventana en la región con C-a C-c

---

Technorati Tags: screen,unix

Señales y gdb

En Unix, las señales son notificaciones asíncronas que recibe un proceso (o hilo dentro del mismo) cuyo origen puede ser otro proceso del sistema, el mismo proceso que las recibe o el núcleo del sistema operativo como consecuencia de una acción que ha realizado el proceso en cuestión durante la ejecución - por ejemplo un acceso a una posición de memoria protegida - . Interrumpe el flujo de ejecución normal, y el proceso que las recibe puede gestionarlas si ha instalado un manejador que se haga cargo de la señal a través del API sigaction o signal. También, usando el mismo API, pueden ser ignoradas, de tal manera que no se pasan al programa.

En un sistema Unix, toda señal está identificada por un número y tiene asociado un nombre que puede verse consultando la página de manual o el fichero de cabecera signal.h. Todas las señales tienen un comportamiento por defecto que es el que sucede cuando un proceso recibe una señal y no se ha ignorado o no se ha instalado un manejador para la misma.

Cuando un proceso está depurándose bajo el control del gdb, es éste el que recibe las señales que van al proceso, y puede decidir parar cuando las recibe, devolviéndonos al prompt del gdb , pasar o no pasar las señales e imprimir información sobre las mismas. El gdb almacena unas tablas, con cada señal que está en el sistema que debe hacer. Estas tablas se manejan con ayuda de la orden handle.

Se puede ver el contenido de toda la tabla de señales con ayuda de la orden info signals o info handle. En este caso, gdb nos volcará una tabla con todas las señales que tenga registrada el sistema, si el programa debe o no detenerse, si debe de imprimir información por la consola del gdb y si esta señal debe de pasarse al programa. Esta orden permite especificar el número de señal (siempre que esté en el rango 1 a 15) o el nombre de la misma , si queremos ver información sólo de las señales que nos interesan. El nombre de todas las señales que reconoce el gdb para la arquitectura que está depurando puede verse en la primera columna de la tabla de señales.

Por ejemplo, si se quiere ver la información sobre la señal SIGTERM:

(gdb) info signal SIGTERM

Signal        Stop    Print    Pass to program    Description

SIGTERM       Yes    Yes    Yes        Terminated

(gdb) 

En este ejemplo puede verse que esta señal

• Para la ejecución del programa y nos devuelve al prompt del depurador, Stop = Yes.
• Imprime en pantalla el momento en que se genera, Print = Yes.
• Se pasa al programa una vez que continuemos la ejecución, Pass = Yes.

Si queremos cambiar el comportamiento del gdb cuando se genera una señal, hay que hacer uso del comando handle. Como argumentos admite una lista de nombres simbólicos de señales, seguido de una serie de tokens que cambia el comportamiento de la misma. Así tenemos stop y nostop que hacen que en caso de que la señal se genere se devuelva el control al gdb, pass (ignore) y nopass (noignore) que hace que la señal no se pase al programa que se esté depurando (las formas entre parénteis son equivalentes) , y por último print y no print para que el depurador imprima la señal que se ha recibido.

Por ejemplo, si se quiere que el gdb imprima un mensaje cada vez que se generan las selañes SIGUSR1 y SIGUSR2 con destino al programa, no queremos que éstas pasen al mismo, y queremos que imprima por pantalla el momento que se reciben, se puede hacer con:

(gdb) handle SIGUSR1 SIGUSR2 nopass nostop print

Signal        Stop    Print    Pass to program    Description

SIGUSR1       No    Yes    No        User defined signal 1

SIGUSR2       No    Yes    No        User defined signal 2

Una particularidad es que en algunas arquitecturas el gdb es capaz de mostrar información que el kernel ha pasado al manejador de señales. Esta información se almacena en la seudovariable $_siginfo, cuya estructura puede verse con la orden ptype $_siginfo.

(gdb) ptype $_siginfo
type = struct {
    int si_signo;
    int si_errno;
    int si_code;
    union {
        int _pad[28];
        struct {...} _kill;
        struct {...} _timer;
        struct {...} _rt;
        struct {...} _sigchld;
        struct {...} _sigfault;
        struct {...} _sigpoll;
    } _sifields;
}

---

Technorati Tags: gdb,unix

Los problemas de readdir_r

Tradicionalmente, cuando se quiere leer un directorio en Unix, se usa las API opendir - para abrir un directorio -,readdir - para obtener una estructura dirent - y closedir - para terminar con el proceso de la estructura DIR - que nos devuelve opendir. Un código sencillo que usa estas función sería tal que así:

DIR *dir;
struct dirent *p;
if ((dir = opendir ("path_directorio"))!=NULL"){
        while ((p = readdir (dir))!=NULL){
                /*
                 Haz lo que quieras con las entradas
                 del directorio d->d_name
                */
                
        }
        closedir (dir);
}

Si nos fijamos en el código anterior, readir nos está devolviendo un puntero a una estructura que reserva el sistema y que es estática, es decir, que no podemos usar esa llamada en programas multihilos sin usar las correspondientes primitivas de sincronización que nos aseguren que sólo un hilo está está llamando a readdir en un momento determinado. Para evitar estas limitaciones, está la llamada readir_r, a la cual se le va a pasar un puntero a la estructura dirent y de esta manera nos aseguramos que sea reentrante, porque no depende de ningún bloque estático reservado por el sistema. El prototipo de la función para llamarla es tal como sigue

int readdir_r(DIR *restrict dirp, struct dirent *restrict entry, struct dirent **restrict result);

Sin embargo, buscando información en Internet di con readdir_r considered harmful y empecé a leerlo, el cual me puso sobre la pista de un tema muy curioso de la declaración de struct dirent. Esta estructura tiene un campo, d_name que va a ser rellenado por la función readline_r con el nombre de la entrada de directorio que vaya recorriendo. Pero claro, cada sistema de ficheros tienen una longitud de nombre distinta, y su miramos la especificación del Opengroup, no se especifica cual es la longitud máxima que debe de tener ese campo. Nos encontramos que en algunos sistemas, como por ejemplo Linux o MacOS X está declarado como char d_name[255], pero en otros como Solaris está declarado como d_name[1]. Así el siguiente código funcionará perfectamente en Linux o MacOS X y acabará con la pila sobreescrita en Solaris.

#include <dirent.h>
DIR *dir;
struct dirent dentry;
struct dirent *p;
if ((dir = opendir ("path"))!=NULL){
        while (readdir_r(dir,&dentry,&p)==0 && p!=NULL){
                /* usa la información de dentry */
        }
        closedir (dir);
}

Aparte, el autor de readdir_r considered harmful apunta a una condición de carrera que puede ocurrir si se usa fpathconf o pathconf con el parámetro _PC_NAME_MAX para obtener el tamaño máximo de un nombre en un directorio. Apunta a una posible solución que puede consultarse en el artículo enlazado para determinar cual debe de ser el tamaño de la estructura. Quizás la manera más rápida de obtener la longitud, supuesto que el sistema soporte la llamada dirfd que nos devuelve el descriptor de fichero asociado con el directorio abierto, sea usarla pasándole el valor de DIR * devuelto por opendir y luego llamar a fpathconf, pasando este descriptor y como segundo parámetro _PC_NAME_MAX. Además, hay que tener en cuenta el terminador de cadena y siempre reservar un poco más para estar en el lado seguro. Tal que así:

#include <dirent.h>
struct dirent *alloc_dirent (DIR *dir){
struct dirent *p = NULL;
int desc;long value;
if ((desc = dirfd (dir)!=-1){
        if ((value = fpathconf (desc,_PC_NAME_MAX)) != -1){
                /* Como mínimo 255 bytes*/
                value = max (value,255);
                p = malloc (value+sizeof (struct dirent)+1);
        }
}
return p;
}

---

Technorati Tags: c,unix

¿Cómo se si un descriptor de fichero está conectado a una tty?

Aunque casi siempre que he programado en C lo he hecho bajo Unix, nunca he tocado esa parte que corresponde al uso de las tty. El sistema tiene una llamada que te dice si un sistema la tiene, que es isatty, pero antes de existir esta llamada había una manera más pedreste de conseguirlo, que la vi en una referencia del Advanced Programing in the Unix enviroment, y es intentar obtener las propiedades del descriptor a través de tcgetattr. Teniendo en cuenta que Stevens es un gran escritor, creo que voy a hacerme con el libro, porque el estilo de Stevens es altamente didáctivo. Lástima que nos dejara hace diez años.

#include <stdio.h>
#include <stdlib.h>
#include <termios.h>

int main (int argc,char **argv){
        struct termios ts;
        if (tcgetattr (fileno (stdin),&ts)!=-1){                 printf ("stdin is  a tty\n");
        }else{
                printf ("stdin is not a tty\n");
        }
}

---

Technorati Tags: unix

Capsium: Un API de seguridad para Unix

(vía Slashdot) En la Universidad de Cambridge y con el apoyo de Google, se está investigando en una serie de modificaciones a las API de Unix para dotarlos de mayor seguridad y poder aislar la ejecución de procesos, limitando a los objetos del sistema a los que tienen acceso (sandboxing). El proyecto recibe el nombre de de Capsicum (pimiento, pimentón en castellano).

Capsicum: practical capabilities for UNIX, un artículo presentado en Usenix 2010 que explica cuales han sido los mecanismos que han decidido usar los investigadores para implementar el API y las abstracciones que han usado. El sistema operativo en el cual han decidido implementar sus ideas es FreeBSD, estando el código disponible bajo licencia BSD. Como no, estando Google implicada, el programa a nivel de usuario con el cual han probado estas API es Chromium. Parece ser que este API estará disponible de manera oficial en la versión 9 de FreeBSD.

---

Technorati Tags: Seguridad,Unix

Utilidades Unix en Win32 nativas

Muchas veces es cómodo tener ciertas utilidades Unix en Windows para realizar tareas con shells scripts (las posibilidades que ofrece la shell de texto de Windows, cmd.exe, son limitadas). Hay mucha gente que conoce Cygwin, que es una capa de emulación que implementa un API compatible con Unix encima del API Win32, usando dicha capa ,las distintas utilidades Unix para portarse a Windows sin modificarlas demasiado.

Sin embargo existe un una compilación de utilidades Unix de manera nativa en Windows, sin necesidad de emulación ninguna, en especial de la sintaxis del sistema de fichero Unix. Utilidades como grep, egrep, gawk, sort o el shell zsh son útiles para procesos de ficheros de logs rápido en Windows, que es el uso que le doy mayoritariamente.

También lleva bastante tiempo está disponible Windows Services for UNIX Version 3.5, un conjunto de herramientas portadas por Microsoft para la ejecución en Win32 (no está soportado, sin embargo en Windows Vista).