He aquí el archivo de configuración del Korn Shell:

La configuración para que en cada login se apliquen los cambios:

Y listo.

LyX 1.4.5.1 del directorio /usr/pkgsrc/editors/lyx-qt:


LyX 1.4.5.1 del directorio /usr/pkgsrc/editors/lyx-qt:

Introducción

La laptop que tengo tiene una tarjeta de red inalámbrica Intel PRO/Wireless 3945ABG así como tambien un procesador Intel Duo, que a según dicen tiene doble núcleo y que tambien es bueno para la virtualización “por hardware” del Xen.

El detalle es que con los kernels que trae por default el disco de instalación del NetBSD no puedo ambas cosas:

• GENERIC.MP <- Solamente puedo usar los dos procesadores sin conexión inalámbrica.
  
  
• GENERIC_LAPTOP <- Aquí si tengo conexión pero nada más puedo usar un sólo CPU.
  

Asíque buscándole encontré la siguiente solución:


El siguiente es un script para reducir los pasos de la compilación del kernel “combinado”.

En lugar de hacer:

• Tomamos una copia del kernel de SMP para el nuevo kernel:

• Le agregamos las bondades del kernel para laptops:

• Comentamos la siguiente directiva
  

• Obtenemos las líneas de los errores:
  

• Aislamos el número de línea solamente:
  

• Y comentamos todas esas líneas una por una a mano.
  

Solamente tenemos que hacer:

• Mezclamos ambos kernels:
  

• Corregimos los errores:
  

• Creamos el directorio de compilación:
  

• Nos situamos dentro y compilamos:
  

Y listo. Ahora Solamente:

• Renombramos el otro kernel:
  

• Y situamos nuestro nuevo kernel recien horneadito:
  

• Y reiniciamos para probarlo.

Código fuente

Este es el pedazo de “maravilla”:


Si encuentras un error por favor repórtalo. Muchas gracias.

Introducción

Este script lo hice debido a que a veces quería instalar todos los paquetes que conforman una serie de ellos y eran demasiados para hacerlos manualmente.

Por ejemplo, si buscamos todos los paquetes del reproductor de audio “XMMS”:


Veremos que existen 40 paquetes disponibles.

Explicación del script

Para ejecutar el script, es necesario darle una mini expresión regular del nombre del paquete, en el caso de la serie de paquetes que conforman al XMMS la palabra en común de todos ellos es la palabra “xmms”.


Cabe hacer mención que la expresión regular *DEBE DE ESTAR AL INICIO DEL NOMBRE DEL PAQUETE Y NO EN MEDIO O AL FINAL* ya que el script fallará en la búsqueda.

Por ejemplo, los siguientes paquetes tienen algo que ver con el XMMS pero ellos forman parte de otra serie de paquetes, por lo tanto el script no los encontrará ni mucho menos los instalará:


Debes de tomar esto encuenta a la hora de querer instalar una serie de paquetes.

Lo primero hace el script es crear un archivo de registro log con el resultado de la búsqueda en el directorio “/tmp” del sistema. En este caso “/tmp/xmms-packages.log”. La ventaja de esto es que al apagar o reiniciar la máquina el sistema automáticamente los borra y de esta forma no se acumulan los registros. La desventaja es que se crea una serie de archivos con permisos del root para que alguien pueda hacer de las suyas en el sistema. De cualquier forma, recuerda que la seguridad es sólo un estado mental.

Despues, el script lee una por una de las líneas de este archivo, obtiene la ruta de acceso, aisla el nombre del paquete para poder comprobar si el paquete ya ha sido instalada anteriormente por otro paquete como una depedencia de el.

Si el nombre del paquete no se encuentra en la base de datos de los paquetes instalados, se procede con su instalación.

De lo contrario se omite y continua con la otra línea.

Cada uno de los procesos de descarga, compilación, instalación y limpieza del proceso, quedan registrados en un log en el directorio “/tmp”.

Por ejemplo, si se instalar el paquete “/usr/pkgsrc/audio/xmms-alarm” se crea el log del proceso “/tmp/xmms-alarm.log”, de esta forma podrás estudiar la razón por la cual haya fallado el proceso en el caso remoto de un fallo.

El script no valida si el proceso falló o no. Haya fallado o haya salido todo bien la instalación de un determinado paquete, el script se sigue a la siguiente línea.

Es responsabilidad del administrador del sistema revisar cada uno de los logs por si hubo algún fallo.

Aunque esta tarea se puede resumir si al final de cada uno de los logs encuentras líneas parecidas a las siguientes:


O tambien volviendo a ejecutar el script y checas cual de todos ellos no se pudo instalar ya que no aparecerá en la base de datos de los paquetes y el script intentará instalarlo de nuevo.

Script

El script es el siguiente:


Cualquier cosa que llegase a fallar, reportalo inmediatamente.

Ejemplo

Despues de haber instalado el meta-paquete “/usr/pkgsrc/meta-pkgs/xfce4”, le indicamos al script que instale el resto de los paquetes de la serie:


A pesar de que eran muchos los paquetes, no todos ellos fueron procesados, de esta manera no solamente no sobrecargamos al procesador sino tambien reducimos el trabajo del disco duro.

Recuerda, si encuentras un error por favor repórtalo inmediatamente. Muchas gracias.

Si así es de chico ¿cómo será cuando crezca este chamaco?

Mision Impossible:



Besame Mucho:


Más videos:


http://www.youtube.com/watch?v=5IXa2pNGVj8

Este es mi ~/.kshrc:


Y esto es lo que tengo en ~/.profile:


Ejemplo de mi prompt:

Desde que me inicié en esto de Unix (como filosofía y no como la marca registrada UNIX®), el editor vi siempre ha sido para mi uno de los grandes y fascinantes enigmas .

No entendía el por qué de su naturaleza (un tanto chocante para el iniciado), sus modos, sus variantes, sus clones, las diferencias entre ellos, sus licencias, el por qué de tantos de ellos, etc., y sobre todo, la médula en la que se centra su edición y su naturaleza: el editor ex.

Para tratar de comprender mejor esta mantra me compré el libro “Learning the vi editor” junto con su versión de bolsillo de Arnold Robins, me leí de cabo a rabo (más o menos) la ayuda en línea del vim, la ayuda en línea de su otro clón: el Elvis (el vi oficial de los slackers y de donde se inspiró Keith Bostic para hacer el nvi, el "New VI", el vi *OFICIAL* de los *BSD), el man page del nvi de los BSD, el comando “:visuage” del nvi asi como tambien el comando “:exusage” y seguía sin poder comprender.

En fin, todo lo relacionado con vi/ex (y por lo ende, todo lo que sea relacionando con el editor estándar de Unix: el editor ed).


Hubo incluso un tiempo en que decidí engañarme y usar el otro mantra de Unix (que en realidad no nació en Unix sino en una PDP-10 que usaba el sistema operativo TOPS-10 y nació en Unix por la frustación de no poder asimilar el mantra de vi. Por eso me atrevo a decir que un usuario de Emacs es un usuario fracasado de vi en potencia. Si tan solo los usuarios fracasados del editor vi pudieran contarse con las... !momento! !ya se puede: vi vs emacs!), el editor Emacs y olvidarme de vi como aquél cuyo amor imposible hace que se olvide de la mujer que tanto quiso pero que nunca le pudo o hubo manera de entregarle todo el amor que sentía por ella.

Incluso imprimí todo sus manuales porque tenía las esperanzas falsas de que en este mantra finalmente iba a encontrar mi felicidad hasta que una noche cansado de hacer tantas “muecas” con las manos por presionar las teclas del “método abreviado” tan mamones que tiene este editor decidí volver derrotado una vez más para ver si en esta ocasión podía conquistar el amor de vi/ex de una vez por todas.

Todas las noches leía con vehemencia el manual del editor Sam, la versión oficial y gráfica del editor ed para el que iría ser el sucesor de Unix pero por falta de tiempo no lo fue (jubilaron a los desarrolladores): el sistema operativo Plan 9, pero no me cabía en la cabeza cómo es que alguien pudiera siquiera preferir un editor de “líneas” a un editor normal, hice miles de anotaciones, leía y leía sin comprender hasta que un día...

Suponiendo que vas a escribir un sencillo programa en C:

• Abres una ventana del emulador de terminal y tecleas:
  

• Para empezar a escribir el código fuente es necesario decirle a ed que vamos a agregar texto, para eso usamos el comado “a” (del inglés “append”, ¡d'oh!):
  

• Y empezamos a hackear:
  

• Ahora vamos a detener la inserción de texto para poder guardar el archivo:
  

• Guardamos con el comando “w” (“write”) más el nombre del archivo:
  

• Compilamos:
  

• Ahora editamos el archivo:
  

• Y le inidicamos que en la línea número 1 le vamos a agregar texto:
  

• y corregimos:
  

• Detenemos la inserción de texto:
  

• Compilamos y probamos:

Pero suponiendo que por algún motivo ya no vamos querer la salida estándar (“stdout”) para mostrar el saludo sino la salida estándar de error (“stderr”).

He aqui el meollo de vi/ex y ed:

Con un editor normal habriamos que presionar la tecla flecha abajo unas cinco veces y presionar la tecla flecha derecha unas 10 veces, dependendiendo claro si habriamos ocupado el shortcut de Ctrl+Flecha derecha, para saltarnos palabra por palabra hasta llegar al lugar del reemplazo.

Lo primero que tenemos que hacer con ed es “seleccionar” la linea que vamos a editar y eso lo conseguimos con


Segun Arnold Robins hay básicamente tres formas de poder seleccionar las líneas (digo, despues de todo ex y ed son “editores de líneas”):

1. De manera explícita através del número de línea.
   
   
2. Con símbolos que te ayuden a especificar el número de línea apartir de la dirección actual.
   
   
3. Por medio de expresiones regulas (“regexp”), que es el método mas eficaz, poderoso y confuso y es el que usamos con “/printf”).

Cuando ed abre un archivo para su edición, su “dirección” interna se sitúa en la última línea del archivo (Sam le dice a esta dirección “texto actual, current text” o “punto, dot”).

Viéndolo gráficamente:

1	#include
2	#include
3
4	main (int argc, char* argv[])
5	{
6	fprintf (stdout, "Hello, world!\n");
7	return (EXIT_SUCCESS);
8	}

Con el comando “/printf” lo que hacemos es seleccionar la línea número 6, que es básicamente:

• “/” <- Busca
  
  
• “printf”<- La expresión regular indicada.
  

1	#include
2	#include
3
4	main (int argc, char* argv[])
5	{
6	fprintf (stdout, "Hello, world!\n");
7	return (EXIT_SUCCESS);
8	}

Despues de haber seleccionado la línea que buscamos le vamos a indicar que en esa línea realice una sustitución de texto, para eso usamos el siguiente comando:


Que es básiamente:

• “s/” <- Realiza un reemplazo de
  
  
• “stdout/” <- La siguiente expresión regular por
  
  
• “stderr/” <- La siguiente expresión regular.
  

Quedando el archivo de la siguiente manera:

1	#include
2	#include
3
4	main (int argc, char* argv[])
5	{
6	fprintf (stderr, "Hello, world!\n");
7	return (EXIT_SUCCESS);
8	}

Si queremos comprobar que se haya realizado dicha sustitución o comprobar que se haya efectuado en el lugar que indicado, imprimimos el contenido de la dirección actual con el comando “p”:


Y vemos que satisfactoriamente el cambio se ha realizado.

Guardamos el archivo:


Compilamos:


Y ejecutamos:


Y ¡listo! Esta es la manera, expresado de la manera más simple, en la que ed/ex o cualquier otro editor de líneas operan.

Lo que hace muy poderoso a un editor de líneas es la posibilidad de poder usar las expresiones regulares (esas todavía me hacen falta por comprender) como por ejemplo, del libro de Arnold Robins:

Tenemos la siguiente base de datos:


Y queremos cambiar el orden de los nombres:


Sólo con teclear el siguiente poderoso comando con la siguiente poderosa expresión regular: