cristian madrid <[EMAIL PROTECTED]> dijo: > Hola listeros tengo un pequeño problema con un script que estoy escrbiendo > este script esta encargado de solictar datos luego concatenarlos en otro > archivo para asi poder almacenarlos uno tras otro en lineas > horizontales ,pero el problemas esta cuando deseo eliminar uno de estos > elemento ubicados en lineas horizontales por ejemplo > > (estos datos estan almacenados en un archivo.old) > 1.- dato_linea_1 > 2.- dato_linea_2 > 3.- dato_linea_3 > 4.- dato_linea_4 > 5.- dato_linea_5 > 6.- dato_linea_6 > 7.- dato_linea_7 > > supongamos que quiero eliminar los datos de la linea 3 y la linea 6 > para poder saber si los contiene hago un > grep 4 /datos/archivo.old > grep 6 /datos/archivo.old
> tengo claro que con grep puedo leer y saber si el archivo.old contiene > dato_linea_4 y dato_linea_6 y que sale facil edita manualmente el archvo > con vi y eliminar pero como esto va dentro de un script nesecito que sea > automatico , desde el script llamar algo que ubique esa linea que > contiene la informacion y luego que la borre mi duda es que comando > utilizo para poder ubicar el eliminar esas lineas de manera que mi > archivo me quede > 1.- dato_linea_1 > 2.- dato_linea_2 > 3.- dato_linea_3 > 5.- dato_linea_5 > 7.- dato_linea_5 Te sirve: grep -v ^4 archivo | grep -v ^6 > archivo.tmp; mv archivo.tmp archivo (Claro que por mi, haria algo en Perl, es mucho mas flexible) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Thu Mar 10 08:35:21 2005 From: [EMAIL PROTECTED] (Horst von Brand) Date: Thu Mar 10 08:35:24 2005 Subject: Novedades en Debian Message-ID: <[EMAIL PROTECTED]> Vean <http://lwn.net/Articles/125927> (posiblemente aun no este disponible para el grueso publico...). Luego pueden volver a la esteril tontera de "HvB es un ignorante" y demas insultos: Los actuales candidatos a DPL estan planteando /exactamente las mismas cosas que he dicho/. Esas mismas por las que se me acusa de ignorante, anti-<ALGUNA_COSA_VAGA> y demas. Realmente triste ver que el "movimiento de software libre" se base en gente tan incapaz de ver lo que tienen frente a las narices. Por lo visto es una infima minoria los que tienen real interes, la honestidad intelectual suficiente para ver sus propios errores y fallas, y estan en condiciones de aportar. El resto quien sabe porque esta aca. No, ni mirare las respuestas a esto. Los debianitas fanaticos (que IMHO son la clase de gente quienes mas dan~o causan a Debian y al codigo abierto en general) de esta lista ya ocupan un lugar privilegiado en mi .procmailrc -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Thu Mar 10 08:48:47 2005 From: [EMAIL PROTECTED] (Horst von Brand) Date: Thu Mar 10 08:48:50 2005 Subject: Estado conexiones TCP/NAT In-Reply-To: Your message of "Thu, 10 Mar 2005 01:30:16 -0300." <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> "Miguel Oyarzo O." <[EMAIL PROTECTED]> dijo: [...] > Mira estos resultados y dime que opinas: > > # cat /proc/net/ip_conntrack |wc -l (asi estoy contando las > conexiones abiertas.. se me olvido mencionarlo) > 24310 > > Basado en tus comentarios: > > # grep ip_conntrack /proc/slabinfo > ip_conntrack 25526 28450 384 2808 2845 1 > > 24310 serian las conexiones abiertas y 25526 el numero de objetos > ip_conntrack usados por el kernel y activos en la memoria. Y? > Al parecer que el objeto ip_conntrack se mantiene en memoria un tiempo... > pero cuánto? quien determina su duracion TTL? Administracion de memoria del nucleo: Se crean slabs (una coleccion de objetos del mismo tipo que cabe en una pagina o asi), y se administran de alli. Obviamente habran slabs con algunos objetos libres (sin usar). Se mantienen en memoria mientras el slab contenga objetos activos. Y un slab sin objetos activos puede mantenerse siempre que no haya presion por asignar memoria (porque es ideal reusar un objeto ya inicializado, &c). Quien determina la vida del objecto? En este caso, la duracion de la conexion... y sobre eso no hay control en el nucleo. Enseguida, los RFC requieren mantener historia sobre una conexion cerrada durante un tiempo bastante largo para evitar que se cruzen los alambres. > Opiciones? comentarios? > Esta interesante este tema... optimizar ese cache será una buena idea. Comienza por estudiar el manejo de memoria virtual (y administracion de memoria en general) en el nucleo. Es un area extremadamente entretenida, con solo unos pocos gurues que saben suficiente para atreverse a meter mano... Si, la idea de compactar slabs (moviendo objetos entre slabs semivacios para liberar alguno) se ha discutido muchas veces. No, no hay propuestas concretas viables. En buena parte porque eso significaria tener maquinaria para cambiarle la direccion a un objeto, corrigiendo /todas/ las referencias a el... y no hay como saber cuales son (y la maquinaria para seguirle el paso a eso seguramente seria inmensa, compleja, ineficiente, y fragil). Otra idea es ver de asignar nuevos objetos con alguna heuristica que deje juntos objetos de vidas largas y cortas... buena suerte! Y antes de tirarse por ese camino: De cuanta memoria estamos hablando? No resulta mas facil ponerle un par de MiB mas al tarro? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Thu Mar 10 09:00:31 2005 From: [EMAIL PROTECTED] (Enrique Place) Date: Thu Mar 10 09:00:35 2005 Subject: =?iso-8859-1?q?Re=3A_=BFVersi=F3n_estable_de_Fedora=3F?= In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> > Creo que nunca, aunque depende de lo que entiendas por estable. Yo aqui > uso la 2 sin muchos problemas. Por definicion, Fedora es una distro > experimental, si quieres algo 100% estable usa RHEL. La idea es usar la versión "más estable" del proyecto Fedora. Pensé que después de varios "core algo", venía un número de versión que representaba "estable" (del tipo Fedora 1, etc). O sea, debo usar como "estable" el último core del momento. -- Saludos, Enrique.
