🚀 go-pugleaf

"J.A. Gutierrez" <spd@daphne.cps.unizar.es> writes:

> Pascal Bourguignon <pjb@informatimago.com> wrote:
> :     tots=0
> :     ls -l | grep '80.' | while read p l o g s m d hy n ; do
> :         tots=$(( $tots + $s ))
> :     done
> :     echo $tots
> : (Y si, s�  perfectamente porque no funciona y que  se puede hacer para
>
> 	cual es el problema? Cada lenguaje tiene sus reglas; y
> 	en este caso se trata del ambito de una variable.

Pues eso.  Que las reglas de los shells para programar no me convienen
y que  rapidamente necesito un  verdadero lenguaje de  programaci�n en
lugar de esos bajatos hacks.


> sh ->
> t=0
> ls -l *80.* | (while read p l o g s foo; do t=`expr $t + $s`; done; echo $t)

Si solo  se quiere imprimir $t  vale. Pero obviamente,  se quiere usar
esta variable despues.


> 	Y si no, utiliza ksh
>
> ksh ->
> let t=0
> ls -l *80.* | while read p l o g s f; do let t=$t+$s; done; echo $t
>
>
> : obtener el resutado,  solo que ne quiero m�s  contorcionarme: no m�s de 2
> : l�neas de shell o paso a lisp).
>
> 	2 lineas? para que?
>
> 	ls -l *80.* | awk '/^-/{t=t+$5} END {print t}'

Ya. awk me vale tambien, por las cosas simples.  Pero no es mas sh.


> : scsh por ejemplo (Scheme Shell).
>
> 	Vale, de acuerdo; esa implementacion de Scheme si que esta
> 	pensada para eso. En todo caso no se si considerar eso LISP
> 	puro; mas bien parece un LISP con extensiones para convertirlo
> 	en shell.
>
>
> 	Pegas:
> 	- no viene por defecto en practicamente ningun unix.

Eso  no  importa mucho  hoy  en dia,  con  los  programas libres,  los
espacios disponibles en nuestros discos duros, y el acceso universal a
Internet, cualquier  heramienta se puede obtener en  cinco minutos con
un par de clics.

Por ejemplo, ver como perl se a extendido.


> 	- existe una gran cantidad de literatura sobre tareas
> 	  tipicas de unix en sh y muy poca para scsh.

Por eso, hablemos de alternativas.  �Un poco de pedagogia!


> 	No niego que a alguien que este mas acostumbrado a la programacion
> 	funcional y que prefiera ignorar las convenciones de unix, LISP
> 	(que nadie discute que como lenguaje sea mas robusto y mejor
> 	concebido y especificado) le resulte mas atractivo...

Pero tambien a  alguien que no este acostumbrado,  porque suelen tener
problemas con los shell que  se resuelve facilmente con cualquier otro
lenguaje.


Tan bien, si solo  se usa los shell, se esta limitando  a lo que saben
hacer  estos shells.  Por  ejemplo, con  el pipe  solo se  puede hacer
sequencias simple de  tubos.  Pero cuando se trata  de implementar eso
en lisp,  rapidamente y facilmente  se generaliza y ahora  puedo hacer
pipes multiples igual de facil. Cosas asi:


                             +----------+
file-1 --------------------->|          |------------------------> file-3
                             |  pgm2    |
             +--------+ pipe |          |  pipe  +-----------+
             |        |----->|          |------->|           |
stdin ------>| pgm1   |      +----------+        |           |
             |        |           pipe           |           |---> stdout
             |        |------------------------->|  pgm3     |
             +--------+                          |           |
                                                 |           |
file-2 ----------------------------------------->|           |
                                                 +-----------+


Lo que quiere decir es que  a usar lenguajes m�s potentes como shells,
se  podria evolucionar  m�s haya  del  simple CLI,  hacia un  interfaz
usuario m�s inteligente.

--
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie