Re: [OT] Salida de los comandos en forma de objeto

2007-08-15 Por tema Matías Bellone
On 8/15/07, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> El Miércoles, 15 de Agosto de 2007, Matías Bellone escribió:
> > No es una tontería y, de hecho, ya está implementado. Son las
> > funciones del kernel (o /proc en su defecto). El hecho de usar la
> > salida de free es una avivada que se hace por comodidad o para evitar
> > tener que aprender a usar toda una API (o llamadas a sistema) como
> > corresponde.
>
> Cierto, habría que echar un buen vistazo a todos los valores allí contenidos.
> Por cierto, ¿está documentado en algún sitio preferible?

Desconozco ¿probaste la documentación del kernel o de linux?

> > Y aún así, seguimos teniendo el mismo problema ¿qué pasa cuando la API
> > cambie? ¿cuando el nombre de la clase, objeto o atributo cambie? Es la
> > eterna pelea de mejoras versus backwards compatibility (i.e. mejorar
> > algo sin romper lo que ya está hecho sobre eso).
>
> Bueno bueno, pero no te pases. Por supuesto que un programa puede cambiar y
> dar otras salidas, pero una cosa es que cambie la funcionalidad (en cuyo caso
> como mucho intentar "compatibilidad hacia atrás") y otra MUY distinta es que
> por cambiar el aspecto VISUAL de la salida se fastidien programas que acceden
> a los datos.

Las "mejoras" de las que estoy hablando no son en funcionalidad
directamente. Estoy hablando de dar más datos de los que ya da, o
presentarlos de una forma más sencilla de leer o lo que sea. Creo que
cualquier modificación a una aplicación debería de ser para mejorarla,
de ahí que las llame "mejoras. Además, reitero, el utilizar la salida
de un programa para construir otro es la base de "no reinventar la
rueda". Sin embargo, esto te hace dependiente de dicho programa y la
salida de dicho programa es de lo que se dispone para poder utilizarlo
en modo scripting.

De todas formas, si lo que haces es tan crítico y/o complicado,
evidentemente no vas a querer hacerlo en scripts sino que va a ser
conveniente usar un programa hecho y derecho accediendo a la
información - probablemente - de la misma forma que lo hacen los
programas que utilizarías en scripts. Dichas librerías o fuentes de
información seguramente son mucho más estables (aunque no he visto
cambios significativos en las salidas de los programas base que uno
normalmente utilizaría en scripts).


> Por hacer un símil, los servicios web están ahí por algo. Consisten
> básicamente en un API http por el cual te comunicas vía http con un servidor,
> el entregas una petición (creo que XML) y te devuelve otro XML con los datos
> solicitados. Todo esto completamente al margen del CSS y HTML que vería un
> usuario desde un navegador.
>

Aquí la cuestión es completamente distinta ya que la presentación
debería de estar separada del contenido. HTML no está hecho para decir
cómo mostrar la información, sino que para eso existe CSS. Si, además
queremos utilizar la información en varios lados XML es la "solución"
ya que para eso fue creado.

Un programa, en cambio, es una utilidad con un fin muy determinado y
hacer scripts en bash que dependan de ello es una forma sencilla de
programación que evita el tener que aprender engorrosas librerías. ¿O
acaso puedes hacer scripting tan sencillo con una API de una
aplicación web? Definitivamente no, tienes que aprender a utilizar una
API completa... casualmente lo mismo que estoy diciendo aquí sólo que
con la API del sistema.

Saludos,
Toote
-- 
Web: http://www.enespanol.com.ar



Re: [OT] Salida de los comandos en forma de objeto

2007-08-15 Por tema Iñaki Baz Castillo
El Miércoles, 15 de Agosto de 2007, Matías Bellone escribió:
> No es una tontería y, de hecho, ya está implementado. Son las
> funciones del kernel (o /proc en su defecto). El hecho de usar la
> salida de free es una avivada que se hace por comodidad o para evitar
> tener que aprender a usar toda una API (o llamadas a sistema) como
> corresponde.

Cierto, habría que echar un buen vistazo a todos los valores allí contenidos. 
Por cierto, ¿está documentado en algún sitio preferible?


> Y aún así, seguimos teniendo el mismo problema ¿qué pasa cuando la API
> cambie? ¿cuando el nombre de la clase, objeto o atributo cambie? Es la
> eterna pelea de mejoras versus backwards compatibility (i.e. mejorar
> algo sin romper lo que ya está hecho sobre eso).

Bueno bueno, pero no te pases. Por supuesto que un programa puede cambiar y 
dar otras salidas, pero una cosa es que cambie la funcionalidad (en cuyo caso 
como mucho intentar "compatibilidad hacia atrás") y otra MUY distinta es que 
por cambiar el aspecto VISUAL de la salida se fastidien programas que acceden 
a los datos.

Por hacer un símil, los servicios web están ahí por algo. Consisten 
básicamente en un API http por el cual te comunicas vía http con un servidor, 
el entregas una petición (creo que XML) y te devuelve otro XML con los datos 
solicitados. Todo esto completamente al margen del CSS y HTML que vería un 
usuario desde un navegador.


Saludos.


-- 
Iñaki Baz Castillo



Re: [OT] Salida de los comandos en forma de objeto

2007-08-15 Por tema Matías Bellone
On 8/15/07, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> Hola, estaba yo divagando un rato...
>
> Imaginemos que un programa monitoriza la swap usada, para ello tendrá que
> llamar internamente al comando "free" que da un resultado:
>
>   # free -m
>  total   used   free sharedbuffers cached
>   Mem:  1011992 19  0140493
>   -/+ buffers/cache:358652
>   Swap:  698137560
>
> y añadir tuberías para hacer primero un "grep Swap" y luego un cut/sed/awk
> para quedarse con el segundo campo numérico.
>
> Tengamos en cuenta en este punto que la salida de "free" (y de tantos otros
> comandos) está formateada para ser visualmente "atractiva", en absoluto está
> pensada para ser procesada/parseada, luego hace falta la colección de amigos
> de Bash de antes (grep, cut...) para obtener el dato que nos interesa.
>
> ¿Y qué pasa si de repente el autor de "free" decide cambiar mínimamente el
> ASPECTO de la salida de "free"? ¿Y si cambia el orden de las columnas en base
> a un estudio de usabilidad o lo que sea? Miedo me da la cantidad de programas
> que parsean la salida de "free" y que dejarían de funcionar con la nueva
> versión de "free", total, "por un simple cambio de formato VISUAL!!!".
>
>
> En Linux veo dos problemas grandes:
> - La ensalada y anarquía en cuanto a ficheros de configuración, obligando a
> los desarrolladores de otras aplicaciones a hacer auténticas peripecias
> parseando otros ficheros paridos cada uno por su madre.
> - El problema que describo, en el que la salida visual interfiere
> completamente con la salida "computacional" en los comandos básicos.
>
>
> En fin, ¿qué opináis? ¿sería positivo esta salida de comandos en forma de
> objeto? ¿o es una tontería?

No es una tontería y, de hecho, ya está implementado. Son las
funciones del kernel (o /proc en su defecto). El hecho de usar la
salida de free es una avivada que se hace por comodidad o para evitar
tener que aprender a usar toda una API (o llamadas a sistema) como
corresponde.

Y aún así, seguimos teniendo el mismo problema ¿qué pasa cuando la API
cambie? ¿cuando el nombre de la clase, objeto o atributo cambie? Es la
eterna pelea de mejoras versus backwards compatibility (i.e. mejorar
algo sin romper lo que ya está hecho sobre eso).

Saludos,
Toote
-- 
Web: http://www.enespanol.com.ar



[OT] Salida de los comandos en forma de objeto

2007-08-15 Por tema Iñaki Baz Castillo
Hola, estaba yo divagando un rato...

En vista de las respuestas obtenidas en mi correo sobre "cómo obtener la carga 
de la CPU" he comprobado algo que todos ya sabemos: que en la mayoría de 
ocasiones si queremos obtener datos concretos de forma automatizada debemos 
ejecutar el comando correspondiente y parsear la salida de pantalla para 
recortar el campo que nos interesa y demás.

Siempre me ha gustado mucho el concepto de "separación de formato y 
contenido", cosa que se hace en la web (CSS y HTML) pero en absoluto en la 
consola Linux. Y me da un poco de miedo, pongo un ejemplo:

Imaginemos que un programa monitoriza la swap usada, para ello tendrá que 
llamar internamente al comando "free" que da un resultado:

  # free -m
 total   used   free sharedbuffers cached
  Mem:  1011992 19  0140493
  -/+ buffers/cache:358652
  Swap:  698137560

y añadir tuberías para hacer primero un "grep Swap" y luego un cut/sed/awk 
para quedarse con el segundo campo numérico.

Tengamos en cuenta en este punto que la salida de "free" (y de tantos otros 
comandos) está formateada para ser visualmente "atractiva", en absoluto está 
pensada para ser procesada/parseada, luego hace falta la colección de amigos 
de Bash de antes (grep, cut...) para obtener el dato que nos interesa.

¿Y qué pasa si de repente el autor de "free" decide cambiar mínimamente el 
ASPECTO de la salida de "free"? ¿Y si cambia el orden de las columnas en base 
a un estudio de usabilidad o lo que sea? Miedo me da la cantidad de programas 
que parsean la salida de "free" y que dejarían de funcionar con la nueva 
versión de "free", total, "por un simple cambio de formato VISUAL!!!".


A todo esto, me viene a la mente un concepto que escuché sobre una supuesta 
nueva consola de Microsoft, que ni sé si se ha hecho realidad ni me importa, 
pero la idea era interesante:
La salida de los comandos se refleja en un objeto con atributos 
correspondientes a los distintos campos que se muestran (o incluso otros). 
Pongo un ejemplo:

El comando "free" da una salida VISUAL así:

  # free -m
 total   used   free sharedbuffers cached
  Mem:  1011992 19  0140493
  -/+ buffers/cache:358652
  Swap:  698137560

Imaginemos que un programa necesita conocer la swap usada. Con la salida en 
forma de objeto (que podría ser una variable/objeto llamada "out") sería tan 
sencillo como:

  $out.swap.used

Es decir, cada comando definiría su propio API de atributos que genera, que 
serían descritos en el "man" o "--help". El programador podría entonces 
decidir cambiar drásticamente el aspecto mediocre de la salida del comando y 
no pasaría nada pues el objeto $out seguiría siendo igual.


En Linux veo dos problemas grandes:
- La ensalada y anarquía en cuanto a ficheros de configuración, obligando a 
los desarrolladores de otras aplicaciones a hacer auténticas peripecias 
parseando otros ficheros paridos cada uno por su madre.
- El problema que describo, en el que la salida visual interfiere 
completamente con la salida "computacional" en los comandos básicos.


En fin, ¿qué opináis? ¿sería positivo esta salida de comandos en forma de 
objeto? ¿o es una tontería?

Saludos.


-- 
Iñaki Baz Castillo