Difference: TWikiBarConversa001 (1 vs. 35)

Revision 3525 Dec 2017 - Main.PauloSantana

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 26 to 26
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Deleted:
<
<
| GPS tracking | Aksesoris Mobil | Railing Tangga | Jual Bunga Mawar Murah | Agen Domino99
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.
Line: 52 to 51
  Desarrollado por Bill Joy de la Berkley University es el Shell mas utilizado en ambientes *BSD e Xenix. La estrutura de sus comandos es bastante similar al del lenguage C. Su gran pecado fue ignorar la compatibilidad con el sh, partiendo por un camino propio.
Changed:
<
<
Además de estos Shells existen otros, pero contigo voy a hablar solamente sobre los tres primeros, tratandolos genéricamente por Shell y señalando las peculiaridades de cada uno que eventualmente tengan. About Mycose problem > http://www.mycose.org/buccale/
>
>
Además de estos Shells existen otros, pero contigo voy a hablar solamente sobre los tres primeros, tratandolos genéricamente por Shell y señalando las peculiaridades de cada uno que eventualmente tengan.
 

Explicando el funcionamento de Shell

Line: 489 to 488
 $ exit # pídele la cuenta al mozo frown
Changed:
<
<
Cualquer duda o falta de compañia para tomar una cerveza o incluso para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar también para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
>
>
Cualquer duda o falta de compañia para tomar una cerveza o incluso para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar también para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@gmail.com para informarse.
 
Changed:
<
<
Gracias y hasta la próxima
>
>
Gracias y hasta la próxima
  -- HumbertoPina - 01 Sep 2006
Changed:
<
<
Atap Fiberglass
>
>
-- PauloSantana - 25 Dec 2017
 
META TOPICMOVED by="JarbasJunior" date="1157129452" from="TWikiBar.ConversaBar001" to="TWikiBar.TWikiBarConversa001"

Revision 3407 Jul 2017 - JulioNeves

Line: 1 to 1
 

Conversación de Bar - Parte I

Deleted:
<
<
SEO Melbourne | melbourne web developer
 

Diálogo escuchado entre un Linuxer y un empujador de mouse:

Revision 3317 Jun 2016 - IjohButo

Line: 1 to 1
 

Conversación de Bar - Parte I

SEO Melbourne | melbourne web developer

Line: 28 to 28
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Changed:
<
<
| GPS tracking | Aksesoris Mobil
>
>
| GPS tracking | Aksesoris Mobil | Railing Tangga | Jual Bunga Mawar Murah | Agen Domino99
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.

Revision 3225 Dec 2015 - SoniaMartin

Line: 1 to 1
 

Conversación de Bar - Parte I

SEO Melbourne | melbourne web developer

Line: 54 to 54
  Desarrollado por Bill Joy de la Berkley University es el Shell mas utilizado en ambientes *BSD e Xenix. La estrutura de sus comandos es bastante similar al del lenguage C. Su gran pecado fue ignorar la compatibilidad con el sh, partiendo por un camino propio.
Changed:
<
<
Además de estos Shells existen otros, pero contigo voy a hablar solamente sobre los tres primeros, tratandolos genéricamente por Shell y señalando las peculiaridades de cada uno que eventualmente tengan.
>
>
Además de estos Shells existen otros, pero contigo voy a hablar solamente sobre los tres primeros, tratandolos genéricamente por Shell y señalando las peculiaridades de cada uno que eventualmente tengan. About Mycose problem > http://www.mycose.org/buccale/
 

Explicando el funcionamento de Shell

Revision 3115 Sep 2015 - IjohButo

Line: 1 to 1
 

Conversación de Bar - Parte I

SEO Melbourne | melbourne web developer

Line: 28 to 28
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Changed:
<
<
| GPS tracking | parfum | Aksesoris Mobil
>
>
| GPS tracking | Aksesoris Mobil
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.
Line: 497 to 497
  -- HumbertoPina - 01 Sep 2006
Changed:
<
<
Parfum - Atap Fiberglass
>
>
Atap Fiberglass
 
META TOPICMOVED by="JarbasJunior" date="1157129452" from="TWikiBar.ConversaBar001" to="TWikiBar.TWikiBarConversa001"

Revision 3020 May 2015 - KunAguers

Line: 1 to 1
 

Conversación de Bar - Parte I

SEO Melbourne | melbourne web developer

Line: 497 to 497
  -- HumbertoPina - 01 Sep 2006
Added:
>
>
Parfum - Atap Fiberglass
 
META TOPICMOVED by="JarbasJunior" date="1157129452" from="TWikiBar.ConversaBar001" to="TWikiBar.TWikiBarConversa001"

Revision 2909 Mar 2015 - ButoIjoh

Line: 1 to 1
 

Conversación de Bar - Parte I

Added:
>
>
SEO Melbourne | melbourne web developer
 
Line: 27 to 28
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Changed:
<
<
Sewa Mobil Jakarta | GPS tracking | parfum
>
>
| GPS tracking | parfum | Aksesoris Mobil
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.

Revision 2803 Apr 2014 - KunAguers

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 27 to 27
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Changed:
<
<
Sewa Mobil Jakarta | GPS tracking | parfum
>
>
Sewa Mobil Jakarta | GPS tracking | parfum
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.

Revision 2720 Feb 2014 - KunAguers

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 27 to 27
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Changed:
<
<
Sewa Mobil Jakarta | GPS tracking | parfum
>
>
Sewa Mobil Jakarta | GPS tracking | parfum
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.

Revision 2614 Nov 2013 - KunAguers

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 27 to 27
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Changed:
<
<
Sewa Mobil Jakarta | GPS tracking | parfum | Rental Mobil Jakarta
>
>
Sewa Mobil Jakarta | GPS tracking | parfum
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.

Revision 2511 Nov 2013 - AnnaMaria

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 27 to 27
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Changed:
<
<
Sewa Mobil Jakarta | GPS tracking | parfum
>
>
Sewa Mobil Jakarta | GPS tracking | parfum | Rental Mobil Jakarta
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.

Revision 2411 Nov 2013 - KunAguers

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 27 to 27
 Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Added:
>
>
Sewa Mobil Jakarta | GPS tracking | parfum
 
Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.

Revision 2307 Nov 2013 - Main.AntonioTerceiro

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 17 to 17
 

El Ambiente Linux

Para que entiendas lo que es y como funciona el Shell, primero te mostraré como funciona el ambiente en capas de Linux. Da una mirada atenta en el gráfico que sigue:

Deleted:
<
<
Sewa Mobil Jakarta | GPS tracking | parfum | Rental Mobil Jakarta
 
Visión del shell en relación al Kernel de Linux
Line: 495 to 494
 Gracias y hasta la próxima

-- HumbertoPina - 01 Sep 2006

Deleted:
<
<
 
META TOPICMOVED by="JarbasJunior" date="1157129452" from="TWikiBar.ConversaBar001" to="TWikiBar.TWikiBarConversa001"

Revision 2207 Nov 2013 - AnnaMaria

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 17 to 17
 

El Ambiente Linux

Para que entiendas lo que es y como funciona el Shell, primero te mostraré como funciona el ambiente en capas de Linux. Da una mirada atenta en el gráfico que sigue:

Changed:
<
<
Sewa Mobil Jakarta | GPS tracking | parfum
>
>
Sewa Mobil Jakarta | GPS tracking | parfum | Rental Mobil Jakarta
 
Visión del shell en relación al Kernel de Linux

Revision 2130 Sep 2013 - JacIntheford

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 17 to 17
 

El Ambiente Linux

Para que entiendas lo que es y como funciona el Shell, primero te mostraré como funciona el ambiente en capas de Linux. Da una mirada atenta en el gráfico que sigue:

Changed:
<
<
klinik hipnoterapi surabaya | GPS tracking | parfum
>
>
Sewa Mobil Jakarta | GPS tracking | parfum
 
Visión del shell en relación al Kernel de Linux

Revision 2002 Sep 2013 - JacIntheford

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 17 to 17
 

El Ambiente Linux

Para que entiendas lo que es y como funciona el Shell, primero te mostraré como funciona el ambiente en capas de Linux. Da una mirada atenta en el gráfico que sigue:

Changed:
<
<
hipnoterapi surabaya | perlengkapan bayi | parfum
>
>
klinik hipnoterapi surabaya | GPS tracking | parfum
 
Visión del shell en relación al Kernel de Linux

Revision 1914 Jun 2013 - JacIntheford

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 17 to 17
 

El Ambiente Linux

Para que entiendas lo que es y como funciona el Shell, primero te mostraré como funciona el ambiente en capas de Linux. Da una mirada atenta en el gráfico que sigue:

Added:
>
>
hipnoterapi surabaya | perlengkapan bayi | parfum
 
Visión del shell en relación al Kernel de Linux

Revision 1828 Apr 2012 - JulioNeves

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 18 to 18
  Para que entiendas lo que es y como funciona el Shell, primero te mostraré como funciona el ambiente en capas de Linux. Da una mirada atenta en el gráfico que sigue:
Changed:
<
<
Visión del shell en relación al Kernel de Linux
>
>
Visión del shell en relación al Kernel de Linux
  En este gráfico se ve que la capa de hardware es la mas profunda estando formada por los componentes físicos de tu computador. Envolviendo a ésta, viene la capa del kernel que es el corazón de Linux, su núcleo, y es quien hace que el hardware funcione, efectuando su manejo y control. Los programas y comandos que envuelven el kernel, lo utilizan para realizar las tareas especificas para las cuales fueron desarrolladas. Encerrando todo eso viene el Shell que tiene este nombre porque en ingles, Shell significa concha, envoltura, o sea que, queda entre los usuarios y el sistema operativo, de forma que todo lo que interacciona con el sistema operativo, tiene que pasar por su filtro.

Revision 1713 Mar 2012 - Main.ManuelRodriguez

Line: 1 to 1
 

Conversación de Bar - Parte I

Revision 1614 Feb 2012 - MarioSilva

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 494 to 494
 Gracias y hasta la próxima

-- HumbertoPina - 01 Sep 2006

Added:
>
>
 
META TOPICMOVED by="JarbasJunior" date="1157129452" from="TWikiBar.ConversaBar001" to="TWikiBar.TWikiBarConversa001"

Revision 1527 Aug 2008 - JulioNeves

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 317 to 317
 
  • El binary es otra instrucción del ftp, que sirve para indicar que la transferencia de archivoremoto será hecha en modo binario, o sea, el contenido del archivo no será interpretado para saber se está en ASCII, EBCDIC, ...
  • El get archivoremoto le dice al ftp que saque ese archivo del hostremoto y lo traiga a nuestro host local. Si fuera para mandar el archivo, usariamos el comando put.
Changed:
<
<
%ATENCIÓN_INI%
>
>
Pinguim com placa de atenção (em espanhol)
 Un error muy frecuente en el uso de labels (como el fimftp del ejemplo anterior) es causado por la presencia de espacios en blanco antes o después del mismo. Estate muy atento en relación a esto, por que este tipo de errores causan muchos dolores de cabeza a los programadores, hasta que son detectados. Acuérdate: un label que se precie, tiene que tener una linea enterita solamente para él.
Changed:
<
<
%_ATENCIÓN_FIM%
>
>
 
Changed:
<
<
    - Está bIen, está bien! Ya sé que salí de viaje y entré por los comandos del ftp, escapando de nuestro asunto, que es el Shell, pero como siempre es bueno aprender algo mas y es raro que las personas estén dispuestas para enseñar...
>
>
    - Está bien, está bien! Ya sé que salí de viaje y entré por los comandos del ftp, escapando de nuestro asunto, que es el Shell, pero como siempre es bueno aprender algo mas y es raro que las personas estén dispuestas para enseñar...
 

Redireccionamento de Comandos

Revision 1429 Jan 2008 - CollonsTorre

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 10 to 10
      - El Bash es el hijo mas nuevo de la familia Shell.
Changed:
<
<
    - Espera ahí! Quieres dejarme loco? Tenía una duda y ahora me dejas con dos!
>
>
    - Espera ahí! Quieres volverme loco? Tenía una duda y ahora me dejas con dos!
 
Changed:
<
<
    - No, loco ya eras antes de aparecer por aqui. Desde que decidiste usar aquél sistema operativo con el cual tienes que reiniciar tu máquina unas diez veces por dia y no tienes dominio ninguno sobre lo que está pasando en el computador. Pero deja eso de lado, te voy a explicar lo que es el Shell y los componentes de su familia y al final de la explicación me dirás: "Mi Dios del Shell! Porque no opté antes por Linux?".
>
>
    - No, loco ya lo eras antes de aparecer por aqui. Desde que decidiste usar aquél sistema operativo con el cual tienes que reiniciar tu máquina unas diez veces por dia y no tienes dominio ninguno sobre lo que está pasando en el computador. Pero deja eso de lado, te voy a explicar lo que es el Shell y los componentes de su familia y al final de la explicación me dirás: "Mi Dios del Shell! Porque no opté antes por Linux?".
 

El Ambiente Linux

Line: 24 to 24
 

El Ambiente Shell

Changed:
<
<
Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como es que funciona, de forma de sacar el mayor provecho a las innúmerables facilidades que él nos ofrece.
>
>
Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como funciona este, y la forma de sacar el mayor provecho de las innúmerables facilidades que él nos ofrece.
  El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).

Pinguim com placa de dica
Changed:
<
<
Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagine cuanto podemos aumentar la seguridad con este simples truco.
>
>
Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagina cuanto podemos aumentar la seguridad con este simples truco.
 

Te acuerdas que te mencioné de la familia Shell? Exactamente, vamos a comenzar a entender esto: el Shell, que se vale de la imagen de una concha envolviendo el sistema operativo propiamente dicho, es el nombre genérico para tratar los hijos de esta idea que, con el correr de los años de existencia del sistema operativo Unix fueron apareciendo. Actualmente existen diversos “sabores” de Shell, entre ellos destaco el sh (Bourne Shell), el ksh (Korn Shell), bash (Bourne Again Shell) y el csh (C Shell).

Line: 38 to 38
 

Bourne Shell (sh)

Changed:
<
<
Desarrollado por Stephen Bourne de la Bell Labs (de AT&T donde también fue desarrollado el Unix), este fue durante muchos años el Shell padrón del sistema operativo Unix. Es también llamado de Standard Shell por haber sido durante varios años, el único y hasta hoy es el mas utilizado ya que fue transportado para todos los ambientes Unix y distros Linux.
>
>
Desarrollado por Stephen Bourne de la Bell Labs (de AT&T donde también fue desarrollado el Unix), este fue durante muchos años el Shell patrón del sistema operativo Unix. Es también llamado de Standard Shell por haber sido durante varios años, el único y hasta hoy es el mas utilizado ya que fue transportado para todos los ambientes Unix y distros Linux.
 

Korn Shell (ksh)

Changed:
<
<
Desarrollado por David Korn, también de la Bell Labs, es un superconjunto del sh, o sea, posee todas las facilidades del sh y a ellas se agregaron muchas otras. La compatibilidade total con el sh viene trayendo muchos usuarios y programadores de Shell para este ambiente.
>
>
Desarrollado por David Korn, también de la Bell Labs, es un superconjunto del sh, o sea, posee todas las facilidades del sh y a ellas se agregaron muchas otras. La compatibilidade total con el sh esta atrayendo a muchos usuarios y programadores de Shell para este ambiente.
 

Boune Again Shell (bash)

Line: 50 to 50
 

C Shell (csh)

Changed:
<
<
Desarrollado por Bill Joy de la Berkley University es el Shell mas utilizado en ambientes *BSD e Xenix. La estrutura de sus comandos es bastante similar al de la lenguage C. Su gran pecado fue ignorar la compatibilidad con el sh, partiendo por un camino propio.
>
>
Desarrollado por Bill Joy de la Berkley University es el Shell mas utilizado en ambientes *BSD e Xenix. La estrutura de sus comandos es bastante similar al del lenguage C. Su gran pecado fue ignorar la compatibilidad con el sh, partiendo por un camino propio.
  Además de estos Shells existen otros, pero contigo voy a hablar solamente sobre los tres primeros, tratandolos genéricamente por Shell y señalando las peculiaridades de cada uno que eventualmente tengan.

Explicando el funcionamento de Shell

Changed:
<
<
El Shell es el primer programa que tu ganas al "loguearte" en Linux. Es él quien va a resolver una cantidad de cosas de forma de no recargar el kernel con tareas repetitivas, aliviandolo para tratar asuntos mas importantes. Como cada usuario posee su propio Shell interponiendose entre él y el Linux, es el Shell quien interpreta los comandos que son tecleados y examina sus sintaxis, pasándolos desmenuzados para su ejecución.
>
>
El Shell es el primer programa al que accedes al "loguearte" en Linux. Es él quien va a resolver una cantidad de cosas para no cargar al kernel con tareas repetitivas, aliviandolo para tratar asuntos mas importantes. Como cada usuario posee su propio Shell interponiendose entre él y el Linux, es el Shell quien interpreta los comandos que son tecleados y examina sus sintaxis, pasándolos desmenuzados para su ejecución.
 
Changed:
<
<
    - Alto ahí, no apure caballo flaco! Ese negocio de interpretar comandos no tiene nada que ver con intérprete, no es cierto?
>
>
    - Alto ahí, no corra tanto! Ese trabajo de interpretar comandos no tiene nada que ver con intérprete, no es cierto?
      - Tiene que ver si, la verdad el Shell es un interpretador (o intérprete realmente) que trae consigo un poderoso lenguaje con comandos de alto nivel, que permite la construcción de loops (lazos), tomas de decisión y de almacenamiento de valores en variables, como te voy mostrar ahora.
Changed:
<
<
Voy a explicarte las principales tareas que el Shell cumple, por su orden de ejecución. Prestame mucha atención en este orden porque él es fundamental para comprender el resto de nuestra conversación.
>
>
Voy a explicarte las principales tareas que el Shell cumple, por su orden de ejecución. Prestale mucha atención a este orden porque es fundamental para comprender el resto de nuestra conversación.
 

Exámen de la Línea de Comandos

Line: 84 to 84
 $ valor=1000
Changed:
<
<
En este caso, por no haber espacios en blanco (ya da para percibir que el espacio en blanco es un de los caracteres reservados) el Shell identificó una asignación y colocó 1000 en la variable valor.
>
>
En este caso, por no haber espacios en blanco (y así identificamos que el espacio en blanco es un de los caracteres reservados) el Shell identificó una asignación y colocó 1000 en la variable valor.
 
Pinguim com placa de dica Nunca Haga:
Line: 94 to 94
 bash: valor: not found
Changed:
<
<
Aqui el Bash achó la palabra valor aislada por blancos y juzgó que tu habrias mandado ejecutar un programa llamado valor, para el cual estarias pasando dos parámetros: = e 1000.
>
>
Aqui el Bash tomo la palabra valor aislada por espacios en blanco y juzgó que tu habías mandado ejecutar un programa llamado valor, al cual estarías pasando dos parámetros: = e 1000.
 

Comando
Changed:
<
<
Cuando una línea es digitada en el prompt de Linux, ella es dividida en pedazos separados por espacios en blanco: el primer pedazo es el nombre del programa que tendrá su existencia investigada; identifica en seguida, en este orden: opciones/parámetros, redireccionamentos y variables.
>
>
Cuando se escribe una línea en el prompt de Linux, esta es dividida en pedazos separados por espacios en blanco: el primer pedazo es el nombre del programa y su existencia sera comprobada; identifica en seguida, en este orden: opciones/parámetros, redireccionamentos y variables.
 
Changed:
<
<
Cuando el programa identificado existe, el Shell verifica los permisos de los archivos involucrados (inclusive el propio programa), dando un señal de error en caso de que tu no estés autorizado a ejecutar esta tarea.
>
>
Si el programa identificado existe, el Shell verifica los permisos de los archivos involucrados (inclusive el propio programa), dando un señal de error en caso de que tu no estés autorizado a ejecutar esta tarea.
 
Resolución de Redireccionamentos
Changed:
<
<
Después de identificar los componentes de la línea que teclaste, el Shell parte para la resolución de redireccionamentos. El Shell tiene incorporado a su elenco de ventajas lo que llamamos de redireccionamento, que puede ser de entrada (stdin), de salida (stdout) o de errores (stderr), de acuerdo a como te explicaré a seguir.
>
>
Después de identificar los componentes de la línea que tecleaste, el Shell parte para la resolución de redireccionamentos. El Shell tiene incorporado a su elenco de ventajas lo que llamamos el redireccionamento, que puede ser de entrada (stdin), de salida (stdout) o de errores (stderr), de acuerdo a como te explicaré a continuación.
 
Substitución de variables
Changed:
<
<
En este puntonto, el Shell verifica si las eventuales variables (parámetros comenzados por $), encontradas en el campo del comando, están definidas y las substituye por sus valores actuales.
>
>
En este punto, el Shell verifica si las eventuales variables (parámetros comenzados por $), encontradas en el campo del comando, están definidas y las substituye por sus valores actuales.
 
Substitución de Meta caracteres
Changed:
<
<
Si algún metacaracter (*, ? ou []) es hallado en la línea de comando, es aqui que será substituído por sus posibles valores. Suponiendo que el único archivo en su directorio corriente que comienza por la letra n sea un directorio llamado nombregrandeparacaramba, si tu haces:
>
>
Si algún metacaracter (*, ? ou []) es hallado en la línea de comando, es aquí que será substituido por sus posibles valores. Suponiendo que el único archivo que comienza por la letra n en su actual directorio sea un directorio llamado nombregrandeparacaramba, si tu haces:
 
$ cd n*
Changed:
<
<
Como hasta aqui quien está trabajando su línea es el Shell y el comando (programa) cd todavia no fue ejecutado, el Shell transforma el n* en nombregrandeparacaramba y el comando cd será ejecutado con éxito.
>
>
Como hasta aquí quien está trabajando su línea es el Shell y el comando (programa) cd todavía no fue ejecutado, el Shell transforma el n* en nombregrandeparacaramba y el comando cd será ejecutado con éxito.
 
Pasa línea de Comando para el kernel
Changed:
<
<
Completadas las anteriores tareas, el Shell monta la línea de comandos, ya con todas las substituciones hechas, llama el kernel para ejecutarla en un nuevo Shell (Shell hijo), ganando un número de proceso (PID o Process IDentification) y permanece inactivo, durmiendo una siestita, durante la ejecución del programa. Una vez finalizado este proceso (junto con el Shell hijo), recibe nuevamente el control y, exhibiendo un prompt, muestra que está listo para ejecutar otros comandos.
>
>
Completadas las anteriores tareas, el Shell monta la línea de comandos, ya con todas las substituciones hechas, llama el kernel para ejecutarla en un nuevo Shell (Shell hijo), recibiendo un número de proceso (PID o Process IDentification) y permanece inactivo, durmiendo una siestecita, durante la ejecución del programa. Una vez finalizado este proceso (junto con el Shell hijo), recibe nuevamente el control y, exhibiendo un prompt, muestra que está listo para ejecutar otros comandos.
 

Descifrando la Piedra de Roseta

Changed:
<
<
Para sacarse aquella sensación que tienes cuando ves un script Shell, que se parece mas a una sopa de letras o a un jeroglífico te mostraré los principales caracteres especiales para que puedas sali por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena dar una "googlada" para descubrir quién es este gaucho).
>
>
Para sacarte aquella sensación que tienes cuando ves un script Shell, que mas parece una sopa de letras o un jeroglífico, te mostraré los principales caracteres especiales para que puedas salir por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena dar una "googlada" para descubrir quién es este tipo).
 

caracteres que cambian el significado

Changed:
<
<
Es eso mismo, cuando deseamos que el Shell no interprete un caracter especial, debemos "esconderlo" de él. Eso puede ser hecho de tres formas distintas:
>
>
Por eso mismo, cuando deseamos que el Shell no interprete un carácter especial, debemos "esconderlo" de él. Eso puede hacerse de tres formas distintas:
 
Apóstrofe o plic (')
Changed:
<
<
Cuando el Shell ve una cadena de caracteres entre apóstrofes ('), él saca los apóstrofes de la cadena y no interpreta su contenido.
>
>
Cuando el Shell ve una cadena de caracteres entre apostrofes ('), él saca los apostrofes de la cadena y no interpreta su contenido.
 
$ ls linux*
Line: 146 to 146
 bash: linux* no such file or directory
Changed:
<
<
En el primer caso el Shell "abrió" el asterisco y descubrió el archivo linuxmagazine para listar. En el segundo, los apóstrofes evitaron la interpretación del Shell y dió la respuesta que no existe el archivo linux*.
>
>
En el primer caso el Shell "abrió" el asterisco y descubrió el archivo linuxmagazine para listar. En el segundo, los apostrofes evitaron la interpretación del Shell y dio la respuesta que no existe el archivo linux*.
 
Contrabarra o Barra Invertida (\)
Changed:
<
<
Idéntico a los apóstrofes excepto que la barra invertida evita la interpretación del caracter que la sigue solamente.
>
>
Idéntico a los apostrofes excepto que la barra invertida evita la interpretación del carácter que la sigue solamente.
  Suponga que accidentalmente has creado un archivo llamado * (asterisco) – que algunos sabores de Unix permiten - y deseas eliminarlo. Si tu hicieras:
Line: 158 to 158
 $ rm *
Changed:
<
<
Tendrias un grande problema, ya que el rm borraria todos los archivos del directorio corriente. La mejor forma de hacerlo es:
>
>
Tendrías un gran problema, ya que el rm borraría todos los archivos del directorio corriente. La mejor forma de hacerlo es:
 
$ rm \*
Changed:
<
<
De esta forma, el Shell no interpretaria el asterisco, y por consiguiente no haria su abertura
>
>
De esta forma, el Shell no interpretaría el asterisco, y por consiguiente no haría su abertura
 
Changed:
<
<
Haga la siguiente experiencia científica:
>
>
Haz la siguiente experiencia científica:
 
$ cd /etc
Line: 175 to 175
 $ echo *
Changed:
<
<
Viste la diferencia? Entonces no precisa explicar mas.
>
>
Viste la diferencia? Entonces no se precisa explicar mas.
 
Aspas (")
Changed:
<
<
Exactamente igual a apóstrofe excepto que, si la cadena entre aspas contiene un signo de pesos ($), un acento invertido (`), o una barra invertida (\), estos caracteres seran interpretados por el Shell.
>
>
Exactamente igual a apostrofe excepto que, si la cadena entre aspas contiene un signo de pesos ($), un acento invertido (`), o una barra invertida (\), estos caracteres serán interpretados por el Shell.
 
Changed:
<
<
No precisa preocuparte ahora con eso, todavia no te di ejemplos del uso de las aspas porque todavia no conoces el signo de pesos ($) ni el acento grave (`). De aqui en adelante veremos con mucho detalle el uso de estos caracteres especiales, lo mas importante es entender el significado de cada uno.
>
>
No debes preocuparte ahora con todo eso, todavía no te di ejemplos del uso de las aspas porque todavía no conoces el signo de pesos ($) ni el acento grave (`). De aquí en adelante veremos con mucho detalle el uso de estos caracteres especiales, lo mas importante es entender el significado de cada uno.
 

caracteres de redireccionamento

Changed:
<
<
La mayoria de los comandos tiene una entrada, una salida y puede generar errores. Esta entrada es llamada Entrada Padrón o stdin y su default es el teclado del terminal. Análogamente, la salida del comando es llamada Salida Padrón o stdout y su default es la pantalla del terminal. Para la pantalla también son enviadas por default los mensajes de error oriundas del comando que em este caso es la llamada Salida de Error Padrón o stderr. Veremos ahora como alterar este estado de cosas.
>
>
La mayoría de los comandos tiene una entrada, una salida y puede generar errores. Esta entrada es llamada Entrada Patrón o stdin y su default es el teclado del terminal. Análogamente, la salida del comando es llamada Salida Patrón o stdout y su default es la pantalla del terminal. Hacia la pantalla también son enviados por default los mensajes de error oriundos del comando, y que en este caso es la llamada Salida de Error Patrón o stderr. Veremos ahora como alterar este estado de cosas.
 
Changed:
<
<
Vamos a hacer un programa tartamudo. Para eso haga:
>
>
Vamos a hacer un programa tartamudo. Para eso haz:
 
$ cat
Changed:
<
<
El cat es una instrucción que lista el contenido del archivo especificado para la Salida Padrón (stdout). En caso que la entrada no esté definida, el espera los datos de la stdin. Mira, como yo no especifiqué la entrada, el está esperándola por el teclado (Entrada Padrón) y como también no cité la salida, lo que yo digitar irá para la pantalla (Salida Padrón) haciendo de esta forma, como habia propuesto un programa tartamudo. Pruebe, el teclado no muerde!
>
>
El cat es una instrucción que lista el contenido del archivo especificado para la Salida Patrón (stdout). En el caso que la entrada no esté definida, el espera los datos de la stdin. Mira, como yo no especifiqué la entrada, el está esperándola por el teclado (Entrada Patrón) y como tampoco no cité la salida, lo que yo escriba irá hacia la pantalla (Salida Patrón) haciendo de esta forma, como había propuesto un programa tartamudo. Prueba, prueba, el teclado no muerde!
 
Changed:
<
<
Redireccionamento de la Salida Padrón
>
>
Redireccionamento de la Salida Patrón
 
Changed:
<
<
Para especificar una salida de programa usamos el > (mayor que) o el >> (mayor, mayor) seguido del nombre del archivo para el cual se desea mandar la salida.
>
>
Para especificar una salida de programa usamos el > (mayor que) o el >> (mayor, mayor) seguido del nombre del archivo al que se desea mandar la salida.
 
Changed:
<
<
Vamos transformar el programa tartamudo en un editor de textos (que pretensión eh!). smile
>
>
Vamos a transformar el programa tartamudo en un editor de textos (que pretensión eh!). smile
 
$ cat > Arch
Changed:
<
<
El cat continua sin tener una entrada especificada, por lo tanto está aguardando que los datos sean digitados, sin embargo su salida está siendo desviada para el archivo Arch. De esta forma, todo lo que esta siendo digitado está yendo para dentro de Arch, de forma que hicimos el editor de textos mas corto y pobre del planeta.
>
>
El cat continua sin tener una entrada especificada, por lo tanto está aguardando que los datos sean escritos, sin embargo su salida está siendo desviada hacia el archivo Arch. De esta forma, todo lo que esta siendo escrito está yendo hacia Arch, de forma que hicimos el editor de textos mas corto y pobre del planeta.
 
Changed:
<
<
Si hacer nuevamente:
>
>
Si ejecutas nuevamente:
 
$ cat > Arch
Changed:
<
<
Los datos contenidos en Arch se perderán, ya que antes del redireccionamento el Shell creará un Arch vacio. Para colocar mas informaciones en el final del archivo deberia haber hecho:
>
>
Los datos contenidos en Arch se perderán, ya que antes del redireccionamento el Shell creará un Arch vacio. Para colocar mas informaciones en el final del archivo deberias haber hecho:
 
$ cat >> Arch

Pinguim com placa de atenção (em espanhol)
Changed:
<
<
Como ya te habia dicho, el Shell resuelve la linea y despues manda el comando para la ejecución. Asi, si tu redireccionas la salida de un archivo para el mismo, primero el Shell "vacia" este archivo y después manda el comando para ejecución, de esta forma acabas de perder el contenido de tu querido archivo.
>
>
Como ya te habia dicho, el Shell resuelve la linea y despues manda el comando para su ejecución. Asi, si tu redireccionas la salida de un archivo hacia el mismo, primero el Shell "vacia" este archivo y después manda el comando para su ejecución, y de esta forma acabas de perder el contenido de tu querido archivo.
 
Changed:
<
<
Con esto notamos que el >> (mayor mayor) sirve para incluir texto em el final del archivo.
>
>
Con esto notamos que el >> (mayor mayor) sirve para incluir texto al final del archivo.
 
Changed:
<
<
Redireccionamento de la Salida de Error Padrón
>
>
Redireccionamento de la Salida de Error Patrón
 
Changed:
<
<
Así como el default del Shell es recibir los datos del teclado y mandar las salidas para la pantalla, los errores también serán enviados para la pantalla si tu no especificaste para donde deverán ser enviados. Para redireccionar los errores use 2> SalidaDeError. Vea que entre el número 2 y el símbolo de mayor (>) no existe espacio en blanco.
>
>
Así como el default del Shell es recibir los datos del teclado y mandar las salidas hacia la pantalla, los errores también serán enviados hacia la pantalla si tu no especificas hacia donde deverán ser enviados. Para redireccionar los errores usa 2> SalidaDeError. Fijate que entre el número 2 y el símbolo de mayor (>) no existe espacio en blanco.
 
Pinguim com placa de atenção (em espanhol)
Changed:
<
<
Preste atención! No confunda >> con 2>. El primero anexa datos al final de un archivo, en cuanto el segundo redirecciona la Salida de Error Padrón (stderr) para un archivo que está siendo designado. Esto es importante!
>
>
Presta atención! No confundas >> con 2>. El primero anexa datos al final de un archivo, en cuanto el segundo redirecciona la Salida de Error Patrón (stderr) hacia el archivo que ha sido designado. Esto es importante!
 
Changed:
<
<
Supongase que durante la ejecución de un script tu puedes, o no (dependiendo del rumbo tomado por la ejecución del programa), haber creado un archivo llamado /tmp/seraqueexiste$$. Para no dejar basura en su disco, al final del script tu colocarias una línea:
>
>
Suponte que durante la ejecución de un script tu puedes, o no (dependiendo del rumbo tomado por la ejecución del programa), haber creado un archivo llamado /tmp/seraqueexiste$$. Para no dejar basura en tu disco, al final del script deberías colocar esta línea:
 
$ rm /tmp/seraqueexiste$$
Changed:
<
<
En caso que el archivo no existiese seria enviado para la pantalla un mensaje de error. Para que eso no ocurra se debe hacer:
>
>
En caso de no existir el archivo, seria enviado hacia la pantalla un mensaje de error. Para que eso no ocurra se debe hacer:
 
$ rm /tmp/seraqueexiste$$ 2> /dev/null
Line: 250 to 250
 
Pinguim com placa de dica Consejo # 1
Changed:
<
<
El $$ contiene el PID, o sea, el número de su proceso. Como Linux es multiusuario, es de buenos modales anexar siempre el $$ a los nombre de los archivos que serán usados por varias personas para que no haya problemas de propriedad, o sea, en caso que nombrases tu archivo simplemente como seraqueexiste, el primero que lo usase (creándolo entonces) seria su dueño y todos los otros obtendrian un error cuando intentasem grabar algo em él.
>
>
El $$ contiene el PID, o sea, el número de su proceso. Como Linux es multiusuario, es de buenos modales anexar siempre el $$ a los nombre de los archivos que serán usados por varias personas para que no haya problemas de propriedad, o sea, en caso que nombrases tu archivo simplemente como seraqueexiste, el primero que lo usase (creándolo entonces) seria su dueño y todos los otros obtendrian un error cuando intentasen grabar algo en él.
 
Changed:
<
<
Para que hagas un test em la Salida de Error Padrón directo en el prompt del Shell, te voy a dar otro ejemplo. Haga:
>
>
Para que hagas un test de la Salida de Error Patrón te voy a dar otro ejemplo, escribe directamente en el prompt del Shell:
 
$ ls noexiste
Line: 264 to 264
 bash: noexiste no such file or directory
Changed:
<
<
En este ejemplo, vimos que cuando hicimos un ls en noexiste, tuvimos un mensaje de error. Después, redireccionamos la Salida de Error Padrón para archivodeerros y executamos el mismo comando, recebiendo solamente el prompt en la pantalla. Cuando listamos el contenido del archivo para el cual fue redireccionada la Salida de Error Padrão, vimos que el mensaje de error habia sido almacenado em él. Haz este test.
>
>
En este ejemplo, vimos que cuando hicimos un ls en noexiste, obtuvimos un mensaje de error. Después, redireccionamos la Salida de Error Patrón hacia archivodeerros y executamos el mismo comando, recibiendo solamente el prompt en la pantalla. Cuando listamos el contenido del archivo para el cual fue redireccionada la Salida de Error Patron, vimos que el mensaje de error habia sido almacenado en él. Haz este test.
 
Pinguim com placa de dica Dica # 2

    - Quién es ese tal de /dev/null?

Changed:
<
<
    - En Unix existe un archivo fantasma. Llamase /dev/null. Todo lo que es mandado para este archivo desaparece. Se parece a un Agujero Negro. En el caso del ejemplo, como no me interesaba guardar el posible mensaje de error proveniente del comando rm, lo redireccioné para este archivo.
>
>
    - En Unix existe un archivo fantasma. Llamase /dev/null. Todo lo que es enviado a este archivo desaparece. Se parece a un Agujero Negro. En el caso del ejemplo, como no me interesaba guardar el posible mensaje de error proveniente del comando rm, lo redireccioné para este archivo.
 
Changed:
<
<
Es interesante notar que estas caracteres de redireccionamento son acumulativos, o sea, si en el ejemplo anterior hicieramos:
>
>
Es interesante notar que estos caracteres de redireccionamento son acumulativos, o sea, si en el ejemplo anterior hicieramos:
 
$ ls noexiste 2>> archivodeerrores
Changed:
<
<
el mensaje de error proveniente del ls seria anexado al final de archivodeerrores.
>
>
el mensaje de error proveniente del ls seria añadido al final de archivodeerrores.
 
Changed:
<
<
Redireccionamento de la Entrada Padrón
>
>
Redireccionamento de la Entrada Patrón
 
Changed:
<
<
Para hacer el redireccionamento de la Entrada Padrón usamos el < (menor que).
>
>
Para hacer el redireccionamento de la Entrada Patrón usamos el < (menor que).
      - Y para que sirve eso? - me vas a preguntar.

    - Déjame darte un ejemplo que vas a entender rapidito.

Changed:
<
<
Supone que quieres mandar un mail para tu jefe. Para el Jefe queremos lo mejor, no es así? entonces, al contrario de salir redirigiendo el mail directamente en el prompt de la pantalla de forma de que será imposible la corrección de una frase anterior donde, sin querer, escribió un "nosotros va", tu editas un archivo con el contenido del mensaje y después de unas quince verificaciones sin constatar errores, decides enviarlo y para eso haces:
>
>
Supone que quieres mandar un mail a tu jefe. Para el Jefe queremos lo mejor, no es así? entonces, en lugar de escribir el mail dirigiéndolo directamente al prompt de la pantalla de forma de que será imposible la corrección de una frase anterior donde, sin querer, escribiste un "nosotros va", tu editas un archivo con el contenido del mensaje y después de unas quince verificaciones sin constatar errores, decides enviarlo y para eso haces:
 
$ mail jefe < archivoconmailparaeljefe
Changed:
<
<
Tu jefe receberá entonces el contenido del archivoconmailparaeljefe.
>
>
Tu jefe reciberá entonces el contenido del archivoconmailparaeljefe.
  Otro tipo de redireccionamento muy loco que el Shell te permite es el llamado here document. Es representado por << (menor menor) y sirve para indicar al Shell que el alcance de un comando comenza en la línea siguiente y termina cuando encuentra una línea cuyo contenido sea unicamente la etiqueta que sigue al símbolo <<.
Changed:
<
<
Vea el fragmento del script a seguir, con una rutina de ftp:
>
>
Observa a continuación el fragmento de un script, con una rutina de ftp:
 
ftp -ivn hostremoto << fimftp
Line: 311 to 311
 

En este pedacito de programa tenemos una cantidad de detalles interesantes:

Changed:
<
<
  • Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no preguntar si tu tienes seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su contraseña, pues estos serán informados por la instrucción específica (user);
  • Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
    - Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar el label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
    Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos también sean interpretados dentro del alcance del here document, lo que también contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, nos están faltando herramientas.
  • El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la contraseña, que habian sido leídos em una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Seña.
>
>
  • Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no preguntar si tienes la seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su contraseña, pues estos estarán indicados por la instrucción específica (user);
  • Cuando usé el << fimftp, estaba diciendo lo siguiente para el intérprete:
    - Mira aqui Shell, no hagas nada a partir de aqui hasta encontrar la etiqueta fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entiendies nada de ftp.
    Si solo fuera eso, seria simple, pero el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos también sean interpretados dentro del alcance del here document, lo que también contradice lo que acabe de decir. Enseguida explico como funciona esto. No es este el momento todavía, nos faltan herramientas.
  • El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la contraseña, que habian sido leídos en una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Seña.
 
  • El binary es otra instrucción del ftp, que sirve para indicar que la transferencia de archivoremoto será hecha en modo binario, o sea, el contenido del archivo no será interpretado para saber se está en ASCII, EBCDIC, ...
Changed:
<
<
  • El get archivoremoto dice al ftp para sacar ese archivo del hostremoto y traerlo para nuestro host local. Si fuera para mandar o archivo, usariamos el comando put.
>
>
  • El get archivoremoto le dice al ftp que saque ese archivo del hostremoto y lo traiga a nuestro host local. Si fuera para mandar el archivo, usariamos el comando put.
  %ATENCIÓN_INI%
Changed:
<
<
Un error muy frecuente en el uso de labels (como el fimftp del ejemplo anterior) es causado por la presencia de espacios en blanco antes o después del mismo. Quede muy atento en relación a esto, por que este tipo de errores causa muchos dolores de cabeza a los programadores, hasta que sean detectados. Acuérdate: un label que se precie, tiene que tener una linea enterita solamente para él.
>
>
Un error muy frecuente en el uso de labels (como el fimftp del ejemplo anterior) es causado por la presencia de espacios en blanco antes o después del mismo. Estate muy atento en relación a esto, por que este tipo de errores causan muchos dolores de cabeza a los programadores, hasta que son detectados. Acuérdate: un label que se precie, tiene que tener una linea enterita solamente para él.
 %_ATENCIÓN_FIM%
Changed:
<
<
    - Está bIen, está bien! Ya sé que salí de viaje y entré por los comandos del ftp, escapando de nuestro asunto, que es Shell, pero como siempre es bueno aprender algo mas y es raro que las personas estén disponibles para enseñar...
>
>
    - Está bIen, está bien! Ya sé que salí de viaje y entré por los comandos del ftp, escapando de nuestro asunto, que es el Shell, pero como siempre es bueno aprender algo mas y es raro que las personas estén dispuestas para enseñar...
 

Redireccionamento de Comandos

Changed:
<
<
Los redireccionamentos que hablamos hasta aqui siempre se referían a archivos, o sea mandaban para archivo, recibían de archivo, simulaban archivo local, ... Lo que veremos a partir de ahora, redirecciona la salida de un comando para la entrada de otro. Esto es utilísimo y facilita la vida un montón. Su nome es pipe (que en inglés significa tubo, ya que él manda la salida de un comando directamente como por un caño para la entrada del otro) y su representación es una barra vertical (|).
>
>
Los redireccionamentos que hablamos hasta aqui siempre se referían a archivos, o sea mandaban hacia archivo, recibían de archivo, simulaban archivo local, ... Lo que veremos a partir de ahora, redirecciona la salida de un comando hacia la entrada de otro. Esto es utilísimo y facilita la vida un montón. Su nome es pipe (que en inglés significa tubo, ya que él envía la salida de un comando directamente como por un caño hacia la entrada del otro) y su representación es una barra vertical (|).
 
$ ls | wc -l     21
Changed:
<
<
El comando ls pasó la lista de archivos para el comando wc, que cuando está com la opción –l cuenta la cantidad de lineas que recebió. De esta forma, podemos afirmar categóricamente que en mi diretorio existían 21 arquivos.
>
>
El comando ls pasó la lista de archivos para el comando wc, que cuando está con la opción –l cuenta la cantidad de lineas que recibió. De esta forma, podemos afirmar categóricamente que en mi diretorio existían 21 archivos.
 
$ cat /etc/passwd |sort | lp
Changed:
<
<
Esta linea de comandos manda la lista del archivo /etc/passwd para la entrada del comando sort. Éste la clasifica y la manda para el lp que es el gerente mandamás del spool de impresión.
>
>
Esta linea de comandos manda la lista del archivo /etc/passwd hacia la entrada del comando sort. Éste la clasifica y la manda para el lp que es el gerente mandamás del spool de impresión.
 

Caracteres de Ambiente

Changed:
<
<
Cuando quieras priorizar una expresión colócala entre paréntesis no es así? Puede ser, por causa de la aritmética es normal que pensemos así. Sin embargo, en Shell lo que prioriza realmente son los acentos graves (`) y no los paréntesis. Voy a dar ejemplos de uso de los acentos graves para que entiendas mejor.
>
>
Cuando quieres priorizar una expresión la colocas entre paréntesis, no es así? Puede ser, a causa de la aritmética es normal que pensemos así. Sin embargo, en Shell lo que prioriza realmente son los acentos graves (`) y no los paréntesis. Te voy a dar ejemplos del uso de los acentos graves para que lo entiendas mejor.
 
Changed:
<
<
Quiero saber cuántos usuarios están "logados" en el computador que administro. Puedo hacer:
>
>
Si quiero saber cuántos usuarios están "logados" en el computador que administro. Puedo hacer:
 
$ who | wc -l     8
Changed:
<
<
El comando who pasa la lista de usuarios conectados al comando wc –l que cuenta cuantas lineas recebió y lista la respuesta en la pantalla. Ahora bien, en lugar de tener un ocho suelto en la pantalla, lo que quiero es que esté colocado en el medio de una frase.
>
>
El comando who pasa la lista de usuarios conectados al comando wc –l que cuenta cuantas lineas recibió y lista la respuesta en la pantalla. Ahora bien, en lugar de tener un ocho suelto en la pantalla, lo que quiero es que esté colocado en medio de una frase.
 
Changed:
<
<
Entonces, para mandar frases para la pantalla uso el comando echo, entonces vamos a ver como queda:
>
>
Entonces, para mandar frases hacia la pantalla usamos el comando echo, veamos entonces como queda:
 
$ echo "Existen who | wc -l usuarios conectados"
Line: 374 to 374
 Existen 8 usuarios conectados
Changed:
<
<
Como dije antes, las aspas protejem todo lo que está dentro de sus límites, de la interpretación del Shell. Como para el Shell basta un espacio en blanco como separador, esa cantidad de espacios será cambiada por un único espacio, después de haber retirado las aspas (económico, eh?).
>
>
Como dije antes, las aspas protejen todo lo que está dentro de sus límites, de la interpretación del Shell. Como para el Shell basta un espacio en blanco como separador, esa cantidad de espacios será cambiada por un único espacio, después de haber retirado las aspas (económico, eh?).
  Antes de hablar sobre el uso de los paréntesis déjame explicar rapidamente acerca del uso del punto y coma (;). Cuando estés en el Shell, siempre debes dar un comando en cada linea. Para agrupar comandos en una misma línea tenemos que separarlos por punto y coma. De esta forma:
Line: 387 to 387
  En este ejemplo, listé el nombre del directorio corriente con el comando pwd, me cambié para el directorio /etc, nuevamente listé el nombre del directorio y finalmente volví para el directorio donde estaba anteriormente (cd -), listando su nombre. Note que coloqué el punto y coma (;) de todas las formas posibles para mostrar que no importa si existen espacios en blanco antes o después de este caracter.
Changed:
<
<
Finalmente vamos ver el caso de los paréntesis. Vea el caso siguiente, bien parecido con el ejemplo anterior:
>
>
Finalmente veamos el caso de los paréntesis. Observa el caso siguiente, muy parecido al ejemplo anterior:
 
$ (pwd ; cd /etc ; pwd;)
Line: 399 to 399
      - Qué es eso, por amor del Shell!? Yo estaba en /home/midir, me cambié para el /etc, verifiqué que estaba en ese directorio con el pwd seguiente y cuando el agrupamiento de comandos terminó, vi que continuaba en el /home/midir, como si nunca hubiera salido de alli!
Changed:
<
<
    - Ah! Será que es cosa de mago?
>
>
    - Ah! Será que es cosa de magos?
 
Changed:
<
<
    - No me confundas, amigo!! No es nada de eso! Lo interesante del uso de paréntesis es que él llama a un nuevo Shell para ejecutar los comandos que están en su interior. De esta forma, realmente fuimos para el directorio /etc, sin embargo cuando todos los comandos dentro de los paréntesis fueron ejecutados, el nuevo Shell que estaba en el directorio /etc murió y volvimos al Shell anterior cuyo directorio corriente era /home/midir. Haz otras pruebas usando cd, y ls para que dejes este concepto bien firme.
>
>
    - No me confundas, amigo!! No es nada de eso! Lo interesante del uso de paréntesis es que se llama a un nuevo Shell para ejecutar los comandos que están en su interior. De esta forma, realmente fuimos para el directorio /etc, sin embargo cuando todos los comandos dentro de los paréntesis fueron ejecutados, el nuevo Shell que estaba en el directorio /etc murió y volvimos al Shell anterior cuyo directorio corriente era /home/midir. Haz otras pruebas usando cd, y ls para que dejes este concepto bien cimentado.
 
Changed:
<
<
Ahora que ya conocemos estos conceptos ve este ejemplo que sigue:
>
>
Ahora que ya conocemos estos conceptos observemos este ejemplo que sigue:
 
$ mail apoyo << FIM
Line: 420 to 420
  Finalmente ahora tenemos el conocimiento necesario para mostrar lo que habiamos conversado sobre here document. Los comandos entre acentos graves (`) tendrán prioridad y por tanto el Shell los ejecutará antes de la instrucción mail. Cuando el apoyo reciba el e-mail, verá que los comandos date y ls fueron ejecutados inmediatamente antes del comando mail, recibiendo entonces una fotografía del ambiente en el momento en que la correspondencia fue enviada.
Changed:
<
<
El prompt primario default del Shell, como vimos, es el símbolo de pesos ($), sin embargo el Shell usa el concepto de prompt secundario, o de continuación de comando, que es enviado para la pantalla cuando hay un quiebre de linea y la instrucción no terminó. Ese prompt, es representado por un símbolo de mayor (>), que vemos precediendo a partir de la 2ª linea del ejemplo.
>
>
El prompt primario default del Shell, como vimos, es el símbolo de pesos ($), sin embargo el Shell usa el concepto de prompt secundario, o de continuación de comando, que es enviado para la pantalla cuando hay un quiebro de linea y la instrucción no terminó. Ese prompt, es representado por un símbolo de mayor (>), que vemos precediendo a partir de la 2ª linea del ejemplo.
 
Changed:
<
<
Para finalizar y revolver todo, debo decir que existe una construcción mas moderna que viene siendo utilizada como forma de priorizar la ejecución de comandos, tal cual los acentos graves (`). Son las construcciones del tipo $(cmd), donde cmd es un (o varios) comando(s) que será(n) ejecutado(s) con prioridad en su contexto.
>
>
Para finalizar y mezclarlo todo, debo decir que existe una construcción mas moderna que viene siendo utilizada como forma de priorizar la ejecución de comandos, como hacen los acentos graves (`). Son las construcciones del tipo $(cmd), donde cmd es un (o varios) comando(s) que será(n) ejecutado(s) con prioridad en su contexto.
  De esta forma, el uso de acentos graves(`) o construcciones del tipo $(cmd) sirven para el mismo fin, sin embargo para quien trabaja con sistemas operativos de diversos fabricantes (multiplataforma), aconsejo el uso de los acentos invertidos, ya que el $(cmd) no fue trasladado para todos los sabores de Shell. Aqui dentro del Bar, usaré las dos formas, indistintamente.
Line: 441 to 441
 ls
Changed:
<
<
En este ejemplo, hice una asignación (=) y ejecuté una instrucción. Lo que quería era que la variable $Archs, recebiese la salida del comando ls. Como las instrucciones de un script son interpretadas de arriba hacia abajo y de izquierda a derecha, la asignación fue hecha antes de la ejecución del ls. Para hacer lo que deseamos es necesario que le dé prioridad a la ejecución de este comando en perjuicio de la asignación y esto puede ser realizado de cualquiera de las maneras siguientes:
>
>
En este ejemplo, hice una asignación (=) y ejecuté una instrucción. Lo que quería era que la variable $Archs, recibiese la salida del comando ls. Como las instrucciones de un script son interpretadas de arriba hacia abajo y de izquierda a derecha, la asignación fue hecha antes de la ejecución del ls. Para hacer lo que deseamos es necesario que le dé prioridad a la ejecución de este comando en perjuicio de la asignación y esto puede ser realizado de cualquiera de las maneras siguientes:
 
$ Archs=`ls`
Line: 453 to 453
 $ Archs=$(ls)
Changed:
<
<
Para cerrar este asunto con broche de oro, vamos a ver un último ejemplo. Digamos que quiera colocar dentro de la variable $Archs la lista detallada (ls -l) de todos los archivos comenzados por arch y seguidos de un único caracter (?). Para eso deberia hacer:
>
>
Para cerrar este asunto con broche de oro, vamos a ver un último ejemplo. Digamos que quiero colocar dentro de la variable $Archs la lista detallada (ls -l) de todos los archivos comenzados por arch y seguidos de un único caracter (?). Para eso deberia hacer:
 
$ Archs=$(ls -l arch?)
Line: 474 to 474
      - Caramba! salió todo junto!
Changed:
<
<
    - Eso mismo, como ya te dije, si tu dejas que el Shell “vea” los espacios en blanco, siempre que haya diversos espacios juntos, ellos serán cambiados por uno solo. Para que la lista salga bien bonita, es necesario proteger la variable de la interpretación de Shell, así:
>
>
    - Eso mismo, como ya te dije, si tu dejas que el Shell “vea” los espacios en blanco, siempre que haya diversos espacios juntos, estos serán cambiados por uno solo. Para que la lista salga bien bonita, es necesario proteger la variable de la interpretación de Shell, así:
 
$ echo "$Archs"
Line: 483 to 483
 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 archl
Changed:
<
<
    - Y ahora amigo, anda practicando esos ejemplos, porque, cuando nos encontremos nuevamente, te voy a explicar una serie de instrucciones típicas de programación Shell. Chau! Ahh! Solamente una cosita mas que me estaba olvidando de decirte. En Shell, el símbolo (#) es usado cuando deseamos hacer un comentario.
>
>
    - Y ahora amigo, ve practicando esos ejemplos, porque, cuando nos encontremos nuevamente, te voy a explicar una serie de instrucciones típicas de programación Shell. Chau! Ahh! Solamente una cosita mas que me estaba olvidando de decirte. En Shell, el símbolo (#) es usado cuando deseamos hacer un comentario.
 
$ exit # pídele la cuenta al mozo frown
Changed:
<
<
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar también para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
>
>
Cualquer duda o falta de compañia para tomar una cerveza o incluso para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar también para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
  Gracias y hasta la próxima

Revision 1313 Feb 2007 - JulioNeves

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 491 to 491
  Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar también para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
Changed:
<
<
Gracias y hasta la próxima!
>
>
Gracias y hasta la próxima
  -- HumbertoPina - 01 Sep 2006

Revision 1207 Jan 2007 - JulioNeves

Line: 1 to 1
 

Conversación de Bar - Parte I

Line: 129 to 129
 

Descifrando la Piedra de Roseta

Changed:
<
<
Para sacarse aquella sensación que tienes cuando ves un script Shell, que se parece mas a una sopa de letras o a un jeroglífico te mostraré los principales caracteres especiales para que puedas sali por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena dar una googlada para descubrir quién es este gaucho).
>
>
Para sacarse aquella sensación que tienes cuando ves un script Shell, que se parece mas a una sopa de letras o a un jeroglífico te mostraré los principales caracteres especiales para que puedas sali por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena dar una "googlada" para descubrir quién es este gaucho).
 

caracteres que cambian el significado

Revision 1115 Dec 2006 - DaltonM

Line: 1 to 1
Changed:
<
<

Conversas de Bar - Parte I

>
>

Conversación de Bar - Parte I

 
Line: 12 to 12
      - Espera ahí! Quieres dejarme loco? Tenía una duda y ahora me dejas con dos!
Changed:
<
<
    - No, loco ya eras antes de aparecer por aqui. Desde que decidiste usar aquél sistema operacional con el cual tienes que dar reinicio en tu máquina unas diez veces por dia y no tienes dominio ninguno sobre lo que está pasando en el computador. Pero deja eso para atrás, te voy a explicar lo que es el Shell y los componentes de su familia y al final de la explicación me dirás: "Mi Dios del Shell! Porque no opté antes por Linux?".
>
>
    - No, loco ya eras antes de aparecer por aqui. Desde que decidiste usar aquél sistema operativo con el cual tienes que reiniciar tu máquina unas diez veces por dia y no tienes dominio ninguno sobre lo que está pasando en el computador. Pero deja eso de lado, te voy a explicar lo que es el Shell y los componentes de su familia y al final de la explicación me dirás: "Mi Dios del Shell! Porque no opté antes por Linux?".
 

El Ambiente Linux

Line: 20 to 20
 
Visión del shell en relación al Kernel de Linux
Changed:
<
<
En este gráfico da para ver que la capa de hardware es la mas profunda estando formada por los componentes físicos de tu computador. Envolviendo a ésta, viene la capa del kernel que es el corazón de Linux, su núcleo, y es quien hace que el hardware funcione, efectuando su manejo y control. Los programas y comandos que envuelven el kernel, lo utilizan para realizar las tareas especificas para las cuales fueron desarrolladas. Encerrando todo eso viene el Shell que tiene este nombre porque en ingles, Shell significa concha, envoltura, o sea que, queda entre los usuarios y el sistema operativo, de forma que todo lo que interacciona con el sistema operativo, tiene que pasar por su filtro.
>
>
En este gráfico se ve que la capa de hardware es la mas profunda estando formada por los componentes físicos de tu computador. Envolviendo a ésta, viene la capa del kernel que es el corazón de Linux, su núcleo, y es quien hace que el hardware funcione, efectuando su manejo y control. Los programas y comandos que envuelven el kernel, lo utilizan para realizar las tareas especificas para las cuales fueron desarrolladas. Encerrando todo eso viene el Shell que tiene este nombre porque en ingles, Shell significa concha, envoltura, o sea que, queda entre los usuarios y el sistema operativo, de forma que todo lo que interacciona con el sistema operativo, tiene que pasar por su filtro.
 

El Ambiente Shell

Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como es que funciona, de forma de sacar el mayor provecho a las innúmerables facilidades que él nos ofrece.

Changed:
<
<
El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de outros, existe un arquivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, tambiém pasa informaciones para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recebir cuando se "logue" (Ajjjjj!!!).
>
>
El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de otros, existe un archivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, también pasa información para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recibir cuando se "loguee" (Ajjjjj!!!).
 
Pinguim com placa de dica
Changed:
<
<
Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recebir al "logarse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al accesar al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagine cuanto podemos aumentar la seguridad con este simples truco.
>
>
Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recibir al "loguearse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al acceder al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagine cuanto podemos aumentar la seguridad con este simples truco.
 
Changed:
<
<
Te acuerdas que te mencioné de la familia Shell? Exactamente, vamos a comenzar a entender esto: el Shell, que se vale de la imagen de una concha envolviendo el sistema operacional propiamente dicho, es el nombre genérico para tratar los hijos de esta idea que, con el correr de los años de existencia del sistema operacional Unix fueron apareciendo. Actualmente existen diversos “sabores” de Shell, entre ellos destaco el sh (Bourne Shell), el ksh (Korn Shell), bash (Bourne Again Shell) y el csh (C Shell).
>
>
Te acuerdas que te mencioné de la familia Shell? Exactamente, vamos a comenzar a entender esto: el Shell, que se vale de la imagen de una concha envolviendo el sistema operativo propiamente dicho, es el nombre genérico para tratar los hijos de esta idea que, con el correr de los años de existencia del sistema operativo Unix fueron apareciendo. Actualmente existen diversos “sabores” de Shell, entre ellos destaco el sh (Bourne Shell), el ksh (Korn Shell), bash (Bourne Again Shell) y el csh (C Shell).
 

Una visión rápida em los Principales Sabores de Shell

Bourne Shell (sh)

Changed:
<
<
Desarrollado por Stephen Bourne de la Bell Labs (de AT&T donde tambiém fue desarrollado el Unix), este fue durante muchos años el Shell padrón del sistema operacional Unix. Es tambiém llamado de Standard Shell por haber sido durante varios años, el único y hasta hoy es el mas utilizado ya que fue transportado para todos los ambientes Unix y distros Linux.
>
>
Desarrollado por Stephen Bourne de la Bell Labs (de AT&T donde también fue desarrollado el Unix), este fue durante muchos años el Shell padrón del sistema operativo Unix. Es también llamado de Standard Shell por haber sido durante varios años, el único y hasta hoy es el mas utilizado ya que fue transportado para todos los ambientes Unix y distros Linux.
 

Korn Shell (ksh)

Changed:
<
<
Desarrollado por David Korn, tambiém de la Bell Labs, es un superconjunto del sh, o sea, posee todas las facilidades del sh y a ellas se agregaron muchas otras. La compatibilidade total con el sh viene trayendo muchos usuarios y programadores de Shell para este ambiente.
>
>
Desarrollado por David Korn, también de la Bell Labs, es un superconjunto del sh, o sea, posee todas las facilidades del sh y a ellas se agregaron muchas otras. La compatibilidade total con el sh viene trayendo muchos usuarios y programadores de Shell para este ambiente.
 

Boune Again Shell (bash)

Changed:
<
<
Este es el Shell mas moderno y cuyo número de adeptos crece mas en todo el mundo, sea por ser el Shell default de Linux, su sistema operacional natural, o sea por su gran diversidad de comandos, que incorpora inclusive diversas instrucciones características del C Shell.
>
>
Este es el Shell mas moderno y cuyo número de adeptos crece mas en todo el mundo, sea por ser el Shell default de Linux, su sistema operativo natural, o sea por su gran diversidad de comandos, que incorpora inclusive diversas instrucciones características del C Shell.
 

C Shell (csh)

Changed:
<
<
Desarrollado por Bill Joy de la Berkley University es el Shell mas utilizado en ambientes *BSD e Xenix. La estrutura de sus comandos es bastante similar al de la lenguage C. Su grande pecado fue ignorar la compatibilidad con el sh, partiendo por un camino propio.
>
>
Desarrollado por Bill Joy de la Berkley University es el Shell mas utilizado en ambientes *BSD e Xenix. La estrutura de sus comandos es bastante similar al de la lenguage C. Su gran pecado fue ignorar la compatibilidad con el sh, partiendo por un camino propio.
  Además de estos Shells existen otros, pero contigo voy a hablar solamente sobre los tres primeros, tratandolos genéricamente por Shell y señalando las peculiaridades de cada uno que eventualmente tengan.

Explicando el funcionamento de Shell

Changed:
<
<
El Shell es el primer programa que tu ganas al "logarte" en Linux. Es él quien va a resolver una cantidad de cosas de forma de no recargar el kernel con tareas repetitivas, aliviandolo para tratar asuntos mas importantes. Como cada usuario posee su propio Shell interponiendose entre él y el Linux, es el Shell quien interpreta los comandos que son teclados y examina sus sintaxes, pasándolos desmenuzados para su ejecución.
>
>
El Shell es el primer programa que tu ganas al "loguearte" en Linux. Es él quien va a resolver una cantidad de cosas de forma de no recargar el kernel con tareas repetitivas, aliviandolo para tratar asuntos mas importantes. Como cada usuario posee su propio Shell interponiendose entre él y el Linux, es el Shell quien interpreta los comandos que son tecleados y examina sus sintaxis, pasándolos desmenuzados para su ejecución.
      - Alto ahí, no apure caballo flaco! Ese negocio de interpretar comandos no tiene nada que ver con intérprete, no es cierto?
Changed:
<
<
    - Tiene que ver si, la verdad el Shell es un interpretador (o será intérprete realmente) que trae consigo un poderoso lenguaje con comandos de alto nivel, que permite la construcción de loops (lazos), tomas de decisión y de almacenamiento de valores en variables, como te voy mostrar ahora.
>
>
    - Tiene que ver si, la verdad el Shell es un interpretador (o intérprete realmente) que trae consigo un poderoso lenguaje con comandos de alto nivel, que permite la construcción de loops (lazos), tomas de decisión y de almacenamiento de valores en variables, como te voy mostrar ahora.
 
Changed:
<
<
Voy a explicarte las principales tareas que el Shell cumple, por su orden de ejecución. Prestame mucha atención en este orden porque él es fundamental para compredener el resto de nuestra conversa.
>
>
Voy a explicarte las principales tareas que el Shell cumple, por su orden de ejecución. Prestame mucha atención en este orden porque él es fundamental para comprender el resto de nuestra conversación.
 

Exámen de la Línea de Comandos

Changed:
<
<
En este exámen el Shell identifica los caracteres especiales (reservados) que tienen significado para la interpretación de la línea,inmediatamente después verifica si la línea pasada es una atribución o un comando.
>
>
En este exámen el Shell identifica los caracteres especiales (reservados) que tienen significado para la interpretación de la línea,inmediatamente después verifica si la línea pasada es una asignación o un comando.
 
Changed:
<
<
Atribución
>
>
Asignación
 
Changed:
<
<
Si el Shell encuentra dos campos separados por un símbolo de igual (=) sin espacios en blanco entre ellos, identifica esta secuencia como una atribución.
>
>
Si el Shell encuentra dos campos separados por un símbolo de igual (=) sin espacios en blanco entre ellos, identifica esta secuencia como una asignación.
  Exemplos
Line: 84 to 84
 $ valor=1000
Changed:
<
<
En este caso, por no haber espacios en blanco (ya da para percibir que el espacio en blanco es un de los caracteres reservados) el Shell identificó una atribución y colocó 1000 en la variable valor.
>
>
En este caso, por no haber espacios en blanco (ya da para percibir que el espacio en blanco es un de los caracteres reservados) el Shell identificó una asignación y colocó 1000 en la variable valor.
 
Pinguim com placa de dica Nunca Haga:
Line: 185 to 185
 

caracteres de redireccionamento

Changed:
<
<
La mayoria de los comandos tiene una entrada, una salida y puede generar errores. Esta entrada es llamada Entrada Padrón o stdin y su default es el teclado del terminal. Análogamente, la salida del comando es llamada Salida Padrón o stdout y su default es la pantalla del terminal. Para la pantalla tambiém son enviadas por default los mensajes de error oriundas del comando que em este caso es la llamada Salida de Error Padrón o stderr. Veremos ahora como alterar este estado de cosas.
>
>
La mayoria de los comandos tiene una entrada, una salida y puede generar errores. Esta entrada es llamada Entrada Padrón o stdin y su default es el teclado del terminal. Análogamente, la salida del comando es llamada Salida Padrón o stdout y su default es la pantalla del terminal. Para la pantalla también son enviadas por default los mensajes de error oriundas del comando que em este caso es la llamada Salida de Error Padrón o stderr. Veremos ahora como alterar este estado de cosas.
  Vamos a hacer un programa tartamudo. Para eso haga:
Line: 193 to 193
 $ cat
Changed:
<
<
El cat es una instrucción que lista el contenido del archivo especificado para la Salida Padrón (stdout). En caso que la entrada no esté definida, el espera los datos de la stdin. Mira, como yo no especifiqué la entrada, el está esperándola por el teclado (Entrada Padrón) y como tambiém no cité la salida, lo que yo digitar irá para la pantalla (Salida Padrón) haciendo de esta forma, como habia propuesto un programa tartamudo. Pruebe, el teclado no muerde!
>
>
El cat es una instrucción que lista el contenido del archivo especificado para la Salida Padrón (stdout). En caso que la entrada no esté definida, el espera los datos de la stdin. Mira, como yo no especifiqué la entrada, el está esperándola por el teclado (Entrada Padrón) y como también no cité la salida, lo que yo digitar irá para la pantalla (Salida Padrón) haciendo de esta forma, como habia propuesto un programa tartamudo. Pruebe, el teclado no muerde!
 
Redireccionamento de la Salida Padrón
Line: 227 to 227
 
Redireccionamento de la Salida de Error Padrón
Changed:
<
<
Así como el default del Shell es recibir los datos del teclado y mandar las salidas para la pantalla, los errores tambiém serán enviados para la pantalla si tu no especificaste para donde deverán ser enviados. Para redireccionar los errores use 2> SalidaDeError. Vea que entre el número 2 y el símbolo de mayor (>) no existe espacio en blanco.
>
>
Así como el default del Shell es recibir los datos del teclado y mandar las salidas para la pantalla, los errores también serán enviados para la pantalla si tu no especificaste para donde deverán ser enviados. Para redireccionar los errores use 2> SalidaDeError. Vea que entre el número 2 y el símbolo de mayor (>) no existe espacio en blanco.
 
Pinguim com placa de atenção (em espanhol) Preste atención! No confunda >> con 2>. El primero anexa datos al final de un archivo, en cuanto el segundo redirecciona la Salida de Error Padrón (stderr) para un archivo que está siendo designado. Esto es importante!
Line: 311 to 311
 

En este pedacito de programa tenemos una cantidad de detalles interesantes:

Changed:
<
<
  • Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no perguntar si tu tienes seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su seña, pues estos serán informados por la instrucción específica (user);
  • Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
    - Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar el label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
    Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos tambiém sean interpretados dentro del alcance del here document, lo que tambiém contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, nos están faltando herramientas.
  • El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la seña, que habian sido leídos em una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Seña.
>
>
  • Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no preguntar si tu tienes seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su contraseña, pues estos serán informados por la instrucción específica (user);
  • Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
    - Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar el label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
    Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos también sean interpretados dentro del alcance del here document, lo que también contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, nos están faltando herramientas.
  • El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la contraseña, que habian sido leídos em una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Seña.
 
  • El binary es otra instrucción del ftp, que sirve para indicar que la transferencia de archivoremoto será hecha en modo binario, o sea, el contenido del archivo no será interpretado para saber se está en ASCII, EBCDIC, ...
  • El get archivoremoto dice al ftp para sacar ese archivo del hostremoto y traerlo para nuestro host local. Si fuera para mandar o archivo, usariamos el comando put.
Line: 325 to 325
 

Redireccionamento de Comandos

Changed:
<
<
Los redireccionamentos que hablamos hasta aqui siempre se referían a archivos, o sea mandaban para archivo, recibían de archivo, simulabam archivo local, ... Lo que veremos a partir de ahora, redirecciona la salida de un comando para la entrada de otro. Esto es utilísimo y facilita la vida un montón. Su nome es pipe (que en inglés significa tubo, ya que él manda la salida de un comando directamente como por un caño para la entrada del otro) y su representación es una barra vertical (|).
>
>
Los redireccionamentos que hablamos hasta aqui siempre se referían a archivos, o sea mandaban para archivo, recibían de archivo, simulaban archivo local, ... Lo que veremos a partir de ahora, redirecciona la salida de un comando para la entrada de otro. Esto es utilísimo y facilita la vida un montón. Su nome es pipe (que en inglés significa tubo, ya que él manda la salida de un comando directamente como por un caño para la entrada del otro) y su representación es una barra vertical (|).
 
$ ls | wc -l
Line: 351 to 351
     8
Changed:
<
<
El comando who pasa la lista de usuarios conectados para el comando wc –l que cuenta cuantas lineas recebió y lista la respuesta en la pantalla. Ahora bien, en lugar de tener un ocho suelto en la pantalla, lo que quiero es que esté colocado en el medio de una frase.
>
>
El comando who pasa la lista de usuarios conectados al comando wc –l que cuenta cuantas lineas recebió y lista la respuesta en la pantalla. Ahora bien, en lugar de tener un ocho suelto en la pantalla, lo que quiero es que esté colocado en el medio de una frase.
  Entonces, para mandar frases para la pantalla uso el comando echo, entonces vamos a ver como queda:
Line: 385 to 385
 /home/midir
Changed:
<
<
En este ejemplo, listé el nombre del directório corriente con el comando pwd, me cambié para el directório /etc, nuevamente listé el nombre del directório y finalmente volví para el directório donde estaba anteriormente (cd -), listando su nombre. Note que coloqué el punto y coma (;) de todas las formas posibles para mostrar que no importa si existen espacios en blanco antes o después de este caracter.
>
>
En este ejemplo, listé el nombre del directorio corriente con el comando pwd, me cambié para el directorio /etc, nuevamente listé el nombre del directorio y finalmente volví para el directorio donde estaba anteriormente (cd -), listando su nombre. Note que coloqué el punto y coma (;) de todas las formas posibles para mostrar que no importa si existen espacios en blanco antes o después de este caracter.
 
Changed:
<
<
Finalmente vamos ver el caso de los paréntesis. Vea el caso a seguir, bien parecido con el ejemplo anterior:
>
>
Finalmente vamos ver el caso de los paréntesis. Vea el caso siguiente, bien parecido con el ejemplo anterior:
 
$ (pwd ; cd /etc ; pwd;)
Line: 397 to 397
 /home/midir
Changed:
<
<
    - Qué es eso, por amor del Shell!? Yo estaba en /home/midir, me cambié para el /etc, verifiqué que estaba en ese directório con el pwd seguiente y cuando el agrupamiento de comandos terminó, vi que continuaba en el /home/midir, como si nunca hubiera salido de alli!
>
>
    - Qué es eso, por amor del Shell!? Yo estaba en /home/midir, me cambié para el /etc, verifiqué que estaba en ese directorio con el pwd seguiente y cuando el agrupamiento de comandos terminó, vi que continuaba en el /home/midir, como si nunca hubiera salido de alli!
      - Ah! Será que es cosa de mago?
Changed:
<
<
    - No me confundas, amigo!! No es nada de eso! Lo interesante del uso de paréntesis es que él llama a un nuevo Shell para ejecutar los comandos que están en su interior. De esta forma, realmente fuimos para el directório /etc, sin embargo cuando todos los comandos dentro de los paréntesis fueron ejecutados, el nuevo Shell que estaba en el directório /etc murió y volvimos al Shell anterior cuyo directório corriente era /home/midir. Haz otras pruebas usando cd, y ls para que dejes este concepto bien firme.
>
>
    - No me confundas, amigo!! No es nada de eso! Lo interesante del uso de paréntesis es que él llama a un nuevo Shell para ejecutar los comandos que están en su interior. De esta forma, realmente fuimos para el directorio /etc, sin embargo cuando todos los comandos dentro de los paréntesis fueron ejecutados, el nuevo Shell que estaba en el directorio /etc murió y volvimos al Shell anterior cuyo directorio corriente era /home/midir. Haz otras pruebas usando cd, y ls para que dejes este concepto bien firme.
  Ahora que ya conocemos estos conceptos ve este ejemplo que sigue:
Line: 441 to 441
 ls
Changed:
<
<
En este ejemplo, hice una atribución (=) y ejecuté una instrucción. Lo que quería era que la variable $Archs, recebiese la salida del comando ls. Como las instrucciones de un script son interpretadas de arriba para abajo y de la izquierda para la derecha, la atribución fue hecha antes de la ejecución del ls. Para hacer lo que deseamos es necesario que le dé prioridad a la ejecución de este comando en perjuicio de la atribución y esto puede ser hecho de cualquer una de las maneras a seguir:
>
>
En este ejemplo, hice una asignación (=) y ejecuté una instrucción. Lo que quería era que la variable $Archs, recebiese la salida del comando ls. Como las instrucciones de un script son interpretadas de arriba hacia abajo y de izquierda a derecha, la asignación fue hecha antes de la ejecución del ls. Para hacer lo que deseamos es necesario que le dé prioridad a la ejecución de este comando en perjuicio de la asignación y esto puede ser realizado de cualquiera de las maneras siguientes:
 
$ Archs=`ls`
Line: 489 to 489
 $ exit # pídele la cuenta al mozo frown
Changed:
<
<
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar tambiém para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
>
>
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar también para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
  Gracias y hasta la próxima!

Revision 1016 Nov 2006 - JulioNeves

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 20 to 20
 
Visión del shell en relación al Kernel de Linux
Changed:
<
<
En este gráfico da para ver que la capa de hardware es la mas profunda estando formada por los componentes físicos de tu computador. Envolviendo ésta, viene la capa del kernel que es el corazón de Linux, su núcleo, y es quien hace que el hardware funcione, efectuando su manejo y control. Los programas y comandos que envuelven el kernel, lo utilizam para realizar las tareas especificas para las cuales fueron desarrolladas. Encerrando todo eso viene el Shell que tiene este nombre porque en ingles, Shell significa concha, envoltura, o sea que, queda entre los usuarios y el sistema operacional, de forma que todo lo que interacciona con el sistema operacional, tiene que pasar por su filtro.
>
>
En este gráfico da para ver que la capa de hardware es la mas profunda estando formada por los componentes físicos de tu computador. Envolviendo a ésta, viene la capa del kernel que es el corazón de Linux, su núcleo, y es quien hace que el hardware funcione, efectuando su manejo y control. Los programas y comandos que envuelven el kernel, lo utilizan para realizar las tareas especificas para las cuales fueron desarrolladas. Encerrando todo eso viene el Shell que tiene este nombre porque en ingles, Shell significa concha, envoltura, o sea que, queda entre los usuarios y el sistema operativo, de forma que todo lo que interacciona con el sistema operativo, tiene que pasar por su filtro.
 

El Ambiente Shell

Changed:
<
<
Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicativo, es necesario el filtro del Shell, vamos entonces a entender como es que funciona, de forma de sacar el mayor provecho a las innúmeras facilidades que él nos ofrece.
>
>
Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicacion, es necesario el filtro del Shell, vamos entonces a entender como es que funciona, de forma de sacar el mayor provecho a las innúmerables facilidades que él nos ofrece.
  El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de outros, existe un arquivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, tambiém pasa informaciones para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recebir cuando se "logue" (Ajjjjj!!!).

Revision 901 Oct 2006 - JulioNeves

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 219 to 219
 $ cat >> Arch
Changed:
<
<
Pinguim com placa de atenção
>
>
Pinguim com placa de atenção (em espanhol)
 Como ya te habia dicho, el Shell resuelve la linea y despues manda el comando para la ejecución. Asi, si tu redireccionas la salida de un archivo para el mismo, primero el Shell "vacia" este archivo y después manda el comando para ejecución, de esta forma acabas de perder el contenido de tu querido archivo.
Changed:
<
<
>
>
  Con esto notamos que el >> (mayor mayor) sirve para incluir texto em el final del archivo.
Line: 229 to 229
  Así como el default del Shell es recibir los datos del teclado y mandar las salidas para la pantalla, los errores tambiém serán enviados para la pantalla si tu no especificaste para donde deverán ser enviados. Para redireccionar los errores use 2> SalidaDeError. Vea que entre el número 2 y el símbolo de mayor (>) no existe espacio en blanco.
Changed:
<
<
Pinguim com placa de atenção
>
>
Pinguim com placa de atenção (em espanhol)
 Preste atención! No confunda >> con 2>. El primero anexa datos al final de un archivo, en cuanto el segundo redirecciona la Salida de Error Padrón (stderr) para un archivo que está siendo designado. Esto es importante!
Changed:
<
<
>
>
  Supongase que durante la ejecución de un script tu puedes, o no (dependiendo del rumbo tomado por la ejecución del programa), haber creado un archivo llamado /tmp/seraqueexiste$$. Para no dejar basura en su disco, al final del script tu colocarias una línea:

Revision 801 Oct 2006 - JulioNeves

Line: 1 to 1
 

Conversas de Bar - Parte I

Revision 708 Sep 2006 - Main.HumbertoPina

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 181 to 181
  Exactamente igual a apóstrofe excepto que, si la cadena entre aspas contiene un signo de pesos ($), un acento invertido (`), o una barra invertida (\), estos caracteres seran interpretados por el Shell.
Changed:
<
<
No precisa preocuparte ahora con eso, todavia no te di ejemplos del uso de las aspas porque todavia no conoces el signo de pesos ($) ni el acento invertido (`). De aqui en adelante veremos con mucho detalle el uso de estos caracteres especiales, lo mas importante es entender el significado de cada uno.
>
>
No precisa preocuparte ahora con eso, todavia no te di ejemplos del uso de las aspas porque todavia no conoces el signo de pesos ($) ni el acento grave (`). De aqui en adelante veremos con mucho detalle el uso de estos caracteres especiales, lo mas importante es entender el significado de cada uno.
 

caracteres de redireccionamento

Line: 342 to 342
 

Caracteres de Ambiente

Changed:
<
<
Cuando quieras priorizar una expresión colócala entre paréntesis no es así? Puede ser, por causa de la aritmética es normal que pensemos así. Sin embargo, en Shell lo que prioriza realmente son los acentos invertidos (`) y no los paréntesis. Voy a dar ejemplos de uso de los acentos invertidos para que entiendas mejor.
>
>
Cuando quieras priorizar una expresión colócala entre paréntesis no es así? Puede ser, por causa de la aritmética es normal que pensemos así. Sin embargo, en Shell lo que prioriza realmente son los acentos graves (`) y no los paréntesis. Voy a dar ejemplos de uso de los acentos graves para que entiendas mejor.
  Quiero saber cuántos usuarios están "logados" en el computador que administro. Puedo hacer:
Line: 360 to 360
 Existen who | wc -l usuarios conectados
Changed:
<
<
Epa! Que pasó?, no funcionó! Exactamente, no funcionó y no fue por causa de las aspas que coloqué, sino porque tendria que haber ejecutado el who | wc -l antes del echo. Para resolver este problema, tengo que priorizar esta segunda parte del comando com el uso de los acentos invertidos, haciéndolo de la siguiente forma:
>
>
Epa! Que pasó?, no funcionó! Exactamente, no funcionó y no fue por causa de las aspas que coloqué, sino porque tendria que haber ejecutado el who | wc -l antes del echo. Para resolver este problema, tengo que priorizar esta segunda parte del comando com el uso de los acentos graves, haciéndolo de la siguiente forma:
 
$ echo "Existen `who | wc -l` usuarios conectados"
Line: 418 to 418
 > FIM
Changed:
<
<
Finalmente ahora tenemos el conocimiento necesario para mostrar lo que habiamos conversado sobre here document. Los comandos entre acentos invertidos (`) tendrán prioridad y por tanto el Shell los ejecutará antes de la instrucción mail. Cuando el apoyo reciba el e-mail, verá que los comandos date y ls fueron ejecutados inmediatamente antes del comando mail, recibiendo entonces una fotografía del ambiente en el momento en que la correspondencia fue enviada.
>
>
Finalmente ahora tenemos el conocimiento necesario para mostrar lo que habiamos conversado sobre here document. Los comandos entre acentos graves (`) tendrán prioridad y por tanto el Shell los ejecutará antes de la instrucción mail. Cuando el apoyo reciba el e-mail, verá que los comandos date y ls fueron ejecutados inmediatamente antes del comando mail, recibiendo entonces una fotografía del ambiente en el momento en que la correspondencia fue enviada.
  El prompt primario default del Shell, como vimos, es el símbolo de pesos ($), sin embargo el Shell usa el concepto de prompt secundario, o de continuación de comando, que es enviado para la pantalla cuando hay un quiebre de linea y la instrucción no terminó. Ese prompt, es representado por un símbolo de mayor (>), que vemos precediendo a partir de la 2ª linea del ejemplo.
Changed:
<
<
Para finalizar y revolver todo, debo decir que existe una construcción mas moderna que viene siendo utilizada como forma de priorizar la ejecución de comandos, tal cual los acentos invertidos (`). Son las construcciones del tipo $(cmd), donde cmd es un (o varios) comando(s) que será(n) ejecutado(s) con prioridad en su contexto.
>
>
Para finalizar y revolver todo, debo decir que existe una construcción mas moderna que viene siendo utilizada como forma de priorizar la ejecución de comandos, tal cual los acentos graves (`). Son las construcciones del tipo $(cmd), donde cmd es un (o varios) comando(s) que será(n) ejecutado(s) con prioridad en su contexto.
 
Changed:
<
<
De esta forma, el uso de acentos invertidos (`) o construcciones del tipo $(cmd) sirven para el mismo fin, sin embargo para quien trabaja con sistemas operativos de diversos fabricantes (multiplataforma), aconsejo el uso de los acentos invertidos, ya que el $(cmd) no fue trasladado para todos los sabores de Shell. Aqui dentro del Bar, usaré las dos formas, indistintamente.
>
>
De esta forma, el uso de acentos graves(`) o construcciones del tipo $(cmd) sirven para el mismo fin, sin embargo para quien trabaja con sistemas operativos de diversos fabricantes (multiplataforma), aconsejo el uso de los acentos invertidos, ya que el $(cmd) no fue trasladado para todos los sabores de Shell. Aqui dentro del Bar, usaré las dos formas, indistintamente.
  Veamos nuevamente el ejemplo dado para los acentos invertidos, ahora con una nueva visión:
Line: 447 to 447
 $ Archs=`ls`
Changed:
<
<
ou:
>
>
o:
 
$ Archs=$(ls)
Line: 459 to 459
 $ Archs=$(ls -l arch?)
Changed:
<
<
ou:
>
>
o:
 
$ Achs=`ls -l arch?`

Revision 604 Sep 2006 - Main.HumbertoPina

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 131 to 131
  Para sacarse aquella sensación que tienes cuando ves un script Shell, que se parece mas a una sopa de letras o a un jeroglífico te mostraré los principales caracteres especiales para que puedas sali por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena dar una googlada para descubrir quién es este gaucho).
Changed:
<
<

caracteres para retirar el sentido

>
>

caracteres que cambian el significado

 
Changed:
<
<
Es eso mismo, cuando no deseamos que el Shell interprete un caracter especial, debemos "esconderlo" de él. Eso puede ser hecho de tres formas distintas:
>
>
Es eso mismo, cuando deseamos que el Shell no interprete un caracter especial, debemos "esconderlo" de él. Eso puede ser hecho de tres formas distintas:
 
Apóstrofe o plic (')
Line: 290 to 290
      - Déjame darte un ejemplo que vas a entender rapidito.
Changed:
<
<
Suponga que quieres mandar un mail para tu jefe. Para el Jefe queremos lo mejor, no es así? entonces, al contrario de salir redirigiendo el mail directamente en el prompt de la pantalla de forma de que será imposible la corrección de una frase anterior donde, sin querer, escribió un "nosotros va", tu editas un archivo con el contenido del mensaje y después de unas quince verificaciones sin constatar errores, decides enviarlo y para eso haces:
>
>
Supone que quieres mandar un mail para tu jefe. Para el Jefe queremos lo mejor, no es así? entonces, al contrario de salir redirigiendo el mail directamente en el prompt de la pantalla de forma de que será imposible la corrección de una frase anterior donde, sin querer, escribió un "nosotros va", tu editas un archivo con el contenido del mensaje y después de unas quince verificaciones sin constatar errores, decides enviarlo y para eso haces:
 
$ mail jefe < archivoconmailparaeljefe
Line: 312 to 312
  En este pedacito de programa tenemos una cantidad de detalles interesantes:
  • Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no perguntar si tu tienes seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su seña, pues estos serán informados por la instrucción específica (user);
Changed:
<
<
  • Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
    - Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar oel label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
    Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos tambiém sean interpretados dentro del alcance del here document, lo que tambiém contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, están faltando herramientas.
>
>
  • Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
    - Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar el label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
    Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos tambiém sean interpretados dentro del alcance del here document, lo que tambiém contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, nos están faltando herramientas.
 
  • El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la seña, que habian sido leídos em una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Seña.
  • El binary es otra instrucción del ftp, que sirve para indicar que la transferencia de archivoremoto será hecha en modo binario, o sea, el contenido del archivo no será interpretado para saber se está en ASCII, EBCDIC, ...
  • El get archivoremoto dice al ftp para sacar ese archivo del hostremoto y traerlo para nuestro host local. Si fuera para mandar o archivo, usariamos el comando put.
Line: 489 to 489
 $ exit # pídele la cuenta al mozo frown
Changed:
<
<
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar tambiém para mandar mi aviso publicitario: decile a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
>
>
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar tambiém para mandar mi aviso publicitario: puedes decirle a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
  Gracias y hasta la próxima!

Revision 502 Sep 2006 - Main.HumbertoPina

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 233 to 233
 Preste atención! No confunda >> con 2>. El primero anexa datos al final de un archivo, en cuanto el segundo redirecciona la Salida de Error Padrón (stderr) para un archivo que está siendo designado. Esto es importante!
Changed:
<
<
Suponga que durante la ejecución de un script tu puedes, o no (dependiendo del rumbo tomado por la ejecución del programa), haber creado un archivo llamado /tmp/seraqueexiste$$. Para no dejar basura en su disco, al final del script tu colocarias una línea:
>
>
Supongase que durante la ejecución de un script tu puedes, o no (dependiendo del rumbo tomado por la ejecución del programa), haber creado un archivo llamado /tmp/seraqueexiste$$. Para no dejar basura en su disco, al final del script tu colocarias una línea:
 
$ rm /tmp/seraqueexiste$$
Line: 250 to 250
 
Pinguim com placa de dica Consejo # 1
Changed:
<
<
El $$ contiene el PID, o sea, el número de su proceso. Como Linux es multiusuario, es de buen gusto anexar siempre el $$ a los nombre de los archivos que serán usados por varias personas para que no haya problemas de propriedad, o sea, en caso que nombrases tu archivo simplemente como seraqueexiste, el primero que lo usase (creándolo entonces) seria su dueño y todos los otros obtendrian un error cuando intentasem grabar algo em él.
>
>
El $$ contiene el PID, o sea, el número de su proceso. Como Linux es multiusuario, es de buenos modales anexar siempre el $$ a los nombre de los archivos que serán usados por varias personas para que no haya problemas de propriedad, o sea, en caso que nombrases tu archivo simplemente como seraqueexiste, el primero que lo usase (creándolo entonces) seria su dueño y todos los otros obtendrian un error cuando intentasem grabar algo em él.
 

Para que hagas un test em la Salida de Error Padrón directo en el prompt del Shell, te voy a dar otro ejemplo. Haga:

Line: 274 to 274
     - En Unix existe un archivo fantasma. Llamase /dev/null. Todo lo que es mandado para este archivo desaparece. Se parece a un Agujero Negro. En el caso del ejemplo, como no me interesaba guardar el posible mensaje de error proveniente del comando rm, lo redireccioné para este archivo.
Changed:
<
<
Es interesante notar que estas caracteres de redireccionamento son acumulativos, o sea, si em el ejemplo anterior hicieramos:
>
>
Es interesante notar que estas caracteres de redireccionamento son acumulativos, o sea, si en el ejemplo anterior hicieramos:
 
$ ls noexiste 2>> archivodeerrores
Line: 483 to 483
 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 archl
Changed:
<
<
    - Y ahora, amigo, anda practicando esos ejemplos, porque, cuando nos encontremos nuevamente, te voy a explicar una serie de instrucciones típicas de programación Shell. Chau! Ahh! Solamente una cosita mas que me estaba olvidando de decirte. En Shell, el símbolo (#) es usado cuando deseamos hacer un comentario.
>
>
    - Y ahora amigo, anda practicando esos ejemplos, porque, cuando nos encontremos nuevamente, te voy a explicar una serie de instrucciones típicas de programación Shell. Chau! Ahh! Solamente una cosita mas que me estaba olvidando de decirte. En Shell, el símbolo (#) es usado cuando deseamos hacer un comentario.
 
Changed:
<
<
$ exit # pidele la cuenta al mozo frown
>
>
$ exit # pídele la cuenta al mozo frown
 
Changed:
<
<
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar tambiém para mandar mi publicidad: digale a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
>
>
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar tambiém para mandar mi aviso publicitario: decile a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
  Gracias y hasta la próxima!

Revision 401 Sep 2006 - Main.HumbertoPina

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 129 to 129
 

Descifrando la Piedra de Roseta

Changed:
<
<
Para sacarse aquella sensación que tienes cuando ves un script Shell, que se parece mas a una sopa de letras o a un jeroglífico te mostraré los principales caracteres especiales para que puedas sali por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena buscar googlada para descubrir quién es este gaucho).
>
>
Para sacarse aquella sensación que tienes cuando ves un script Shell, que se parece mas a una sopa de letras o a un jeroglífico te mostraré los principales caracteres especiales para que puedas sali por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena dar una googlada para descubrir quién es este gaucho).
 

caracteres para retirar el sentido

Line: 202 to 202
 Vamos transformar el programa tartamudo en un editor de textos (que pretensión eh!). smile

Changed:
<
<
$ cat > Arq
>
>
$ cat > Arch
 
Changed:
<
<
El cat continua sin tener una entrada especificada, por lo tanto está aguardando que los datos sean digitados, sin embargo su salida está siendo desviada para el archivo Arq. De esta forma, todo lo que esta siendo digitado está yendo para dentro de Arq, de forma que hicimos el editor de textos mas corto y pobre del planeta.
>
>
El cat continua sin tener una entrada especificada, por lo tanto está aguardando que los datos sean digitados, sin embargo su salida está siendo desviada para el archivo Arch. De esta forma, todo lo que esta siendo digitado está yendo para dentro de Arch, de forma que hicimos el editor de textos mas corto y pobre del planeta.
  Si hacer nuevamente:

Changed:
<
<
$ cat > Arq
>
>
$ cat > Arch
 
Changed:
<
<
Los datos contenidos en Arq se perderán, ya que antes del redireccionamento el Shell creará un Arq vacio. Para colocar mas informaciones en el final del archivo deberia haber hecho:
>
>
Los datos contenidos en Arch se perderán, ya que antes del redireccionamento el Shell creará un Arch vacio. Para colocar mas informaciones en el final del archivo deberia haber hecho:
 
Changed:
<
<
$ cat >> Arq
>
>
$ cat >> Arch
 

Pinguim com placa de atenção
Line: 250 to 250
 
Pinguim com placa de dica Consejo # 1
Changed:
<
<
El $$ contiene el PID, o sea, el número de su proceso. Como Linux es multiusuario, es de buen gusto anexar siempre el $$ a los nombre de los archivos que serán usados por varias personas para no haber problemas de propriedad, o sea, en caso que nombrases tu archivo simplemente como seraqueexiste, el primero que lo usase (creandolo entonces) seria su dueño y todos los otros obtendrian un error cuando intentasem grabar algo em él.
>
>
El $$ contiene el PID, o sea, el número de su proceso. Como Linux es multiusuario, es de buen gusto anexar siempre el $$ a los nombre de los archivos que serán usados por varias personas para que no haya problemas de propriedad, o sea, en caso que nombrases tu archivo simplemente como seraqueexiste, el primero que lo usase (creándolo entonces) seria su dueño y todos los otros obtendrian un error cuando intentasem grabar algo em él.
 

Para que hagas un test em la Salida de Error Padrón directo en el prompt del Shell, te voy a dar otro ejemplo. Haga:

Line: 277 to 277
 Es interesante notar que estas caracteres de redireccionamento son acumulativos, o sea, si em el ejemplo anterior hicieramos:

Changed:
<
<
$ ls naoexiste 2>> archivodeerrores
>
>
$ ls noexiste 2>> archivodeerrores
 

el mensaje de error proveniente del ls seria anexado al final de archivodeerrores.

Line: 288 to 288
      - Y para que sirve eso? - me vas a preguntar.
Changed:
<
<
    - Dejame darte un ejemplo que vas a entender rapidito.
>
>
    - Déjame darte un ejemplo que vas a entender rapidito.
 
Changed:
<
<
Suponga que quieres mandar un mail para te jefe. Para el Jefe queremos lo mejor, no es así? entonces, al contrario de salir redirigindo el mail directo en el prompt de la pantalla de forma de que sea imposible la corrección de una frase anterior donde, sin querer, escribió un "nosotros va", tu editas un archivo con el contenido del mensaje y después de unas quince verificaciones sin constatar ningún error, decide enviarlo y para eso hace:
>
>
Suponga que quieres mandar un mail para tu jefe. Para el Jefe queremos lo mejor, no es así? entonces, al contrario de salir redirigiendo el mail directamente en el prompt de la pantalla de forma de que será imposible la corrección de una frase anterior donde, sin querer, escribió un "nosotros va", tu editas un archivo con el contenido del mensaje y después de unas quince verificaciones sin constatar errores, decides enviarlo y para eso haces:
 
$ mail jefe < archivoconmailparaeljefe
Line: 311 to 311
 

En este pedacito de programa tenemos una cantidad de detalles interesantes:

Changed:
<
<
1 Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no perguntar si tu tienes seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su seña, pues estos serán informados por la instrucción específica (user); 1 Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
- Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar oel label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos tambiém sean interpretados dentro del alcance del here document, lo que tambiém contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, están faltando herramientas. 1 El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la seña que habian sido leídos em una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Senha. 1 El binary es otra instrucción del ftp, que sirve para indicar que la transferencia de archivoremoto será hecha en modo binario, o sea, el contenido del archivo no será interpretado para saber se está en ASCII, EBCDIC, ... 1 El get archivoremoto dice al ftp para sacar ese archivo de hostremoto y traerlo para nuestro host local. Si fura para mandar o archivo, usariamos el comando put.
>
>
  • Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no perguntar si tu tienes seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su seña, pues estos serán informados por la instrucción específica (user);
  • Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
    - Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar oel label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
    Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos tambiém sean interpretados dentro del alcance del here document, lo que tambiém contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, están faltando herramientas.
  • El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la seña, que habian sido leídos em una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Seña.
  • El binary es otra instrucción del ftp, que sirve para indicar que la transferencia de archivoremoto será hecha en modo binario, o sea, el contenido del archivo no será interpretado para saber se está en ASCII, EBCDIC, ...
  • El get archivoremoto dice al ftp para sacar ese archivo del hostremoto y traerlo para nuestro host local. Si fuera para mandar o archivo, usariamos el comando put.
  %ATENCIÓN_INI%
Changed:
<
<
Un error muy frecuente en el uso de labels (como el fimftp del ejemplo anterior) es causado por la presencia de espacios en blanco antes o después del mismo. Quede muy atento en relación a esto, por que este tipo de errores causa muchos dolores de cabeza a los programadores, hasta que sea detectado. Acuérdese: un label que se precie tiene que tener una linea entera solamente para él.
>
>
Un error muy frecuente en el uso de labels (como el fimftp del ejemplo anterior) es causado por la presencia de espacios en blanco antes o después del mismo. Quede muy atento en relación a esto, por que este tipo de errores causa muchos dolores de cabeza a los programadores, hasta que sean detectados. Acuérdate: un label que se precie, tiene que tener una linea enterita solamente para él.
 %_ATENCIÓN_FIM%
Changed:
<
<
    - Está bIen, está bien! Ya sé que salí de viaje y entré por los comandos del ftp, escapando de nuestro asunto, que es Shell, pero como siempre es bueno aprender algo mas y es raro que las personas esten disponibles para enseñar...
>
>
    - Está bIen, está bien! Ya sé que salí de viaje y entré por los comandos del ftp, escapando de nuestro asunto, que es Shell, pero como siempre es bueno aprender algo mas y es raro que las personas estén disponibles para enseñar...
 

Redireccionamento de Comandos

Changed:
<
<
Los redireccionamentos que hablamos hasta aqui siempre se referían a archivos, o sea mandaban para archivo, recibian de archivo, simulabam archivo local, ... Lo que veremos a partir de ahora redirecciona la salida de un comando para la entrada de otro. Esto es utilísimo y facilita la vida un montón. Su nome es pipe (que en inglés significa tubo, ya que él manda la salida de un comando para la entrada de otro) y su representación es una barra vertical (|).
>
>
Los redireccionamentos que hablamos hasta aqui siempre se referían a archivos, o sea mandaban para archivo, recibían de archivo, simulabam archivo local, ... Lo que veremos a partir de ahora, redirecciona la salida de un comando para la entrada de otro. Esto es utilísimo y facilita la vida un montón. Su nome es pipe (que en inglés significa tubo, ya que él manda la salida de un comando directamente como por un caño para la entrada del otro) y su representación es una barra vertical (|).
 
$ ls | wc -l     21
Changed:
<
<
El comando ls pasó la lista de archivos para el comando wc, que cuando está com la opción –l cuenta la cantidad de lineas que recebió. De esta forma, podemos afirmar categóricamente que en mi diretorio existian 21 arquivos.
>
>
El comando ls pasó la lista de archivos para el comando wc, que cuando está com la opción –l cuenta la cantidad de lineas que recebió. De esta forma, podemos afirmar categóricamente que en mi diretorio existían 21 arquivos.
 
$ cat /etc/passwd |sort | lp
Changed:
<
<
Esta línea de comandos manda la lista del archivo /etc/passwd para la entrada del comando sort. Este la clasifica y la manda para el lp que es el gerente del spool de impresión.
>
>
Esta linea de comandos manda la lista del archivo /etc/passwd para la entrada del comando sort. Éste la clasifica y la manda para el lp que es el gerente mandamás del spool de impresión.
 

Caracteres de Ambiente

Changed:
<
<
Cuando quieras priorizar una expresión colocala entre paréntesis no es así? Puede ser, por causa de la aritmética es normal que pensemos así. Sin embargo, en Shell lo que prioriza realmente son los acentos invertidos (`) y no los paréntesis. Voy a dar ejemplos de uso de los acentos invertidos para que entiendas mejor.
>
>
Cuando quieras priorizar una expresión colócala entre paréntesis no es así? Puede ser, por causa de la aritmética es normal que pensemos así. Sin embargo, en Shell lo que prioriza realmente son los acentos invertidos (`) y no los paréntesis. Voy a dar ejemplos de uso de los acentos invertidos para que entiendas mejor.
  Quiero saber cuántos usuarios están "logados" en el computador que administro. Puedo hacer:
Line: 351 to 351
     8
Changed:
<
<
El comando who pasa la lista de usuarios conectados para el comando wc –l que cuenta cuantas lineas recebió y lista la respuesta en la pantalla. Ahora bien, en lugar de tener un ocho suelto en la pantalla, lo que quiero es que está en el medio de una frase.
>
>
El comando who pasa la lista de usuarios conectados para el comando wc –l que cuenta cuantas lineas recebió y lista la respuesta en la pantalla. Ahora bien, en lugar de tener un ocho suelto en la pantalla, lo que quiero es que esté colocado en el medio de una frase.
  Entonces, para mandar frases para la pantalla uso el comando echo, entonces vamos a ver como queda:
Line: 374 to 374
 Existen 8 usuarios conectados
Changed:
<
<
Como dije antes, las aspas protejem todo lo que está dentro de sus límites, de la interpretación del Shell. Como para el Shell basta un espacio en blanco como separador, esa cantidad de espacios será cambiada por un único espacio, después de haber retirado las aspas.
>
>
Como dije antes, las aspas protejem todo lo que está dentro de sus límites, de la interpretación del Shell. Como para el Shell basta un espacio en blanco como separador, esa cantidad de espacios será cambiada por un único espacio, después de haber retirado las aspas (económico, eh?).
 
Changed:
<
<
Antes de hablar sobre el uso de los paréntesis dejame explicar rapidamente acerca del uso del punto y coma (;). Cuando esté en el Shell, tu siempre debes dar un comando en cada linea. Para agrupar comandos en una misma línea tenemos que separarlos por punto y coma. De esta forma:
>
>
Antes de hablar sobre el uso de los paréntesis déjame explicar rapidamente acerca del uso del punto y coma (;). Cuando estés en el Shell, siempre debes dar un comando en cada linea. Para agrupar comandos en una misma línea tenemos que separarlos por punto y coma. De esta forma:
 
$ pwd ; cd /etc; pwd; cd -; pwd
Changed:
<
<
/home/meudir
>
>
/home/midir
 /etc/
Changed:
<
<
/home/meudir
>
>
/home/midir
 

En este ejemplo, listé el nombre del directório corriente con el comando pwd, me cambié para el directório /etc, nuevamente listé el nombre del directório y finalmente volví para el directório donde estaba anteriormente (cd -), listando su nombre. Note que coloqué el punto y coma (;) de todas las formas posibles para mostrar que no importa si existen espacios en blanco antes o después de este caracter.

Line: 401 to 401
      - Ah! Será que es cosa de mago?
Changed:
<
<
    - No me confundas, amigo? No es nada de eso! Lo interesante del uso de paréntesis es que él llama a un nuevo Shell para ejecutar los comandos que están en su interior. De esta forma, realmente fuimos para el directório /etc, sin embargo cuando todos los comandos adentro de los paréntesis fueron ejecutados, el nuevo Shell que estaba en el directório /etc murió y volvimos a Shell anterior cuyo directório corriente era /home/midir. Haz otras pruebas usando cd, y ls para que dejes este concepto bien firme.
>
>
    - No me confundas, amigo!! No es nada de eso! Lo interesante del uso de paréntesis es que él llama a un nuevo Shell para ejecutar los comandos que están en su interior. De esta forma, realmente fuimos para el directório /etc, sin embargo cuando todos los comandos dentro de los paréntesis fueron ejecutados, el nuevo Shell que estaba en el directório /etc murió y volvimos al Shell anterior cuyo directório corriente era /home/midir. Haz otras pruebas usando cd, y ls para que dejes este concepto bien firme.
 
Changed:
<
<
Ahora que ya conocemos estes conceptos vea este ejemplo que sigue:
>
>
Ahora que ya conocemos estos conceptos ve este ejemplo que sigue:
 
$ mail apoyo << FIM > Hola apoyo, hoy a las ‘date "+%H:%M"‘
Changed:
<
<
> ocorrió nuevamente aquel problema
>
>
> ocurrió nuevamente aquel problema
 > que ya habia informado por > teléfono. De acuerdo con su pedido > ahí va una lista de los archivos
Line: 418 to 418
 > FIM
Changed:
<
<
Finalmente ahora tenemos el conocimiento para mostrar lo que habiamos conversado sobre here document. Los comandos entre acentos invertidos (`) tendrán prioridad y por tanto el Shell los ejecutará antes de la instrucción mail. Cuando el apoyo reciba el e-mail, verá que los comandos date y ls fueron ejecutados inmediatamente antes del comando mail, recibiendo entonces una fotografía del ambiente en el momento en que la correspondencia fue enviada.
>
>
Finalmente ahora tenemos el conocimiento necesario para mostrar lo que habiamos conversado sobre here document. Los comandos entre acentos invertidos (`) tendrán prioridad y por tanto el Shell los ejecutará antes de la instrucción mail. Cuando el apoyo reciba el e-mail, verá que los comandos date y ls fueron ejecutados inmediatamente antes del comando mail, recibiendo entonces una fotografía del ambiente en el momento en que la correspondencia fue enviada.
  El prompt primario default del Shell, como vimos, es el símbolo de pesos ($), sin embargo el Shell usa el concepto de prompt secundario, o de continuación de comando, que es enviado para la pantalla cuando hay un quiebre de linea y la instrucción no terminó. Ese prompt, es representado por un símbolo de mayor (>), que vemos precediendo a partir de la 2ª linea del ejemplo.

Para finalizar y revolver todo, debo decir que existe una construcción mas moderna que viene siendo utilizada como forma de priorizar la ejecución de comandos, tal cual los acentos invertidos (`). Son las construcciones del tipo $(cmd), donde cmd es un (o varios) comando(s) que será(n) ejecutado(s) con prioridad en su contexto.

Changed:
<
<
De esta forma, el uso de acentos invertidos (`) o construcciones del tipo $(cmd) sirven para el mismo fin, sin embargo para quien trabaja con sistemas operacionales de diversos fabricantes (multiplataforma), aconsejo el uso de los acentos invertidos, ya que el $(cmd) no fue trasladado para todos los sabores de Shell. Aqui dentro del Bar, usaré las dos formas, indistintamente.
>
>
De esta forma, el uso de acentos invertidos (`) o construcciones del tipo $(cmd) sirven para el mismo fin, sin embargo para quien trabaja con sistemas operativos de diversos fabricantes (multiplataforma), aconsejo el uso de los acentos invertidos, ya que el $(cmd) no fue trasladado para todos los sabores de Shell. Aqui dentro del Bar, usaré las dos formas, indistintamente.
  Veamos nuevamente el ejemplo dado para los acentos invertidos, ahora con una nueva visión:
Line: 453 to 453
 $ Archs=$(ls)
Changed:
<
<
Para cerrar este asunto con broche de oro, vamos a ver un último ejemplo. Digamos que quiera colocar dentro de la variable $Archs la lista larga (ls -l) de todos los archivos comenzados por arch y seguidos de un único caracter (?). Yo deberia hacer:
>
>
Para cerrar este asunto con broche de oro, vamos a ver un último ejemplo. Digamos que quiera colocar dentro de la variable $Archs la lista detallada (ls -l) de todos los archivos comenzados por arch y seguidos de un único caracter (?). Para eso deberia hacer:
 
$ Archs=$(ls -l arch?)
Line: 462 to 462
 ou:

Changed:
<
<
$ Arqs=`ls -l arch?`
>
>
$ Achs=`ls -l arch?`
 

Sin embargo, ve esto:

Revision 301 Sep 2006 - JarbasJunior

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 496 to 496
 

-- HumbertoPina - 01 Sep 2006

Added:
>
>
META TOPICMOVED by="JarbasJunior" date="1157129452" from="TWikiBar.ConversaBar001" to="TWikiBar.TWikiBarConversa001"

Revision 201 Sep 2006 - Main.HumbertoPina

Line: 1 to 1
 

Conversas de Bar - Parte I

Line: 319 to 319
  %ATENCIÓN_INI% Un error muy frecuente en el uso de labels (como el fimftp del ejemplo anterior) es causado por la presencia de espacios en blanco antes o después del mismo. Quede muy atento en relación a esto, por que este tipo de errores causa muchos dolores de cabeza a los programadores, hasta que sea detectado. Acuérdese: un label que se precie tiene que tener una linea entera solamente para él.
Changed:
<
<
%_INI% Un_FIM%
>
>
%_ATENCIÓN_FIM%
 
Changed:
<
<
    - Está bem, está bem! Eu sei que dei uma viajada e entrei pelos comandos do ftp, fugindo ao nosso assunto que é Shell, mas como é sempre bom aprender e é raro as pessoas estarem disponíveis para ensinar...
>
>
    - Está bIen, está bien! Ya sé que salí de viaje y entré por los comandos del ftp, escapando de nuestro asunto, que es Shell, pero como siempre es bueno aprender algo mas y es raro que las personas esten disponibles para enseñar...
 
Changed:
<
<

Redirecionamento de Comandos

>
>

Redireccionamento de Comandos

 
Changed:
<
<
Os redirecionamentos que falamos até aqui sempre se referiam a arquivos, isto é mandavam para arquivo, recebiam de arquivo, simulavam arquivo local, ... O que veremos a partir de agora redireciona a saída de um comando para a entrada de outro. É utilíssimo e quebra os maiores galhos. Seu nome é pipe (que em inglês significa tubo, já que ele encana a saída de um comando para a entrada de outro) e sua representação é uma barra vertical (|).
>
>
Los redireccionamentos que hablamos hasta aqui siempre se referían a archivos, o sea mandaban para archivo, recibian de archivo, simulabam archivo local, ... Lo que veremos a partir de ahora redirecciona la salida de un comando para la entrada de otro. Esto es utilísimo y facilita la vida un montón. Su nome es pipe (que en inglés significa tubo, ya que él manda la salida de un comando para la entrada de otro) y su representación es una barra vertical (|).
 
$ ls | wc -l     21
Changed:
<
<
O comando ls passou a lista de arquivos para o comando wc, que quando está com a opção –l conta a quantidade de línea que recebeu. Desta forma, podemos afirmar categoricamente que no meu diretório existiam 21 arquivos.
>
>
El comando ls pasó la lista de archivos para el comando wc, que cuando está com la opción –l cuenta la cantidad de lineas que recebió. De esta forma, podemos afirmar categóricamente que en mi diretorio existian 21 arquivos.
 
$ cat /etc/passwd |sort | lp
Changed:
<
<
Esta línea de comandos manda a listagem do arquivo /etc/passwd para a entrada do comando sort. Este a classifica e manda-a para o lp que é o gerenciador do spool de impressão.
>
>
Esta línea de comandos manda la lista del archivo /etc/passwd para la entrada del comando sort. Este la clasifica y la manda para el lp que es el gerente del spool de impresión.
 
Changed:
<
<

caracters de Ambiente

>
>

Caracteres de Ambiente

 
Changed:
<
<
Quando quer priorizar uma expressão você coloca-a entre parênteses não é? Pois é, por causa da aritmética é normal pensarmos deste jeito. Mas em Shell o que prioriza mesmo são as crases (`) e não os parênteses. Vou dar exemplos de uso das crases para você entender melhor.
>
>
Cuando quieras priorizar una expresión colocala entre paréntesis no es así? Puede ser, por causa de la aritmética es normal que pensemos así. Sin embargo, en Shell lo que prioriza realmente son los acentos invertidos (`) y no los paréntesis. Voy a dar ejemplos de uso de los acentos invertidos para que entiendas mejor.
 
Changed:
<
<
Eu quero saber quantos usuários estão "logados" no computador que eu administro. Eu posso fazer:
>
>
Quiero saber cuántos usuarios están "logados" en el computador que administro. Puedo hacer:
 
$ who | wc -l     8
Changed:
<
<
O comando who passa a lista de usuários conectados para o comando wc –l que conta quantas líneas recebeu e lista a resposta na pantalla. Pois bem, mas ao invés de ter um oito solto na pantalla, o que eu quero é que ele esteja no meio de uma frase.
>
>
El comando who pasa la lista de usuarios conectados para el comando wc –l que cuenta cuantas lineas recebió y lista la respuesta en la pantalla. Ahora bien, en lugar de tener un ocho suelto en la pantalla, lo que quiero es que está en el medio de una frase.
 
Changed:
<
<
Ora para mandar frases para a pantalla eu uso o comando echo, então vamos ver como é que fica:
>
>
Entonces, para mandar frases para la pantalla uso el comando echo, entonces vamos a ver como queda:
 
Changed:
<
<
$ echo "Existem who | wc -l usuários conectados" Existem who | wc -l usuários conectados
>
>
$ echo "Existen who | wc -l usuarios conectados" Existen who | wc -l usuarios conectados
 
Changed:
<
<
Hi! Olha só, não funcionou! É mesmo, não funcionou e não foi por causa das aspas que eu coloquei, mas sim por que eu teria que ter executado o who | wc -l antes do echo. Para resolver este problema, tenho que priorizar esta segunda parte do comando com o uso de crases, fazendo assim:
>
>
Epa! Que pasó?, no funcionó! Exactamente, no funcionó y no fue por causa de las aspas que coloqué, sino porque tendria que haber ejecutado el who | wc -l antes del echo. Para resolver este problema, tengo que priorizar esta segunda parte del comando com el uso de los acentos invertidos, haciéndolo de la siguiente forma:
 
Changed:
<
<
$ echo "Existem `who | wc -l` usuários conectados" Existem 8 usuários conectados
>
>
$ echo "Existen `who | wc -l` usuarios conectados" Existen 8 usuarios conectados
 
Changed:
<
<
Para eliminar esse monte de brancos antes do 8 que o wc -l produziu, basta tirar as aspas. Assim:
>
>
Para eliminar esa cantidad de espacios en blancos antes del 8 que el wc -l produjo, basta sacar las aspas. Así:
 
Changed:
<
<
$ echo Existem `who | wc -l` usuários conectados Existem 8 usuários conectados
>
>
$ echo Existen `who | wc -l` usuarios conectados Existen 8 usuarios conectados
 
Changed:
<
<
Como eu disse antes, as aspas protegem tudo que esta dentro dos seus limites, da interpretação do Shell. Como para o Shell basta um espaço em branco como separador, o monte de espaços será trocado por um único após a retirada das aspas.
>
>
Como dije antes, las aspas protejem todo lo que está dentro de sus límites, de la interpretación del Shell. Como para el Shell basta un espacio en blanco como separador, esa cantidad de espacios será cambiada por un único espacio, después de haber retirado las aspas.
 
Changed:
<
<
Antes de falar sobre o uso dos parênteses deixa eu mandar uma rapidinha sobre o uso de ponto-e-vírgula (;). Quando estiver no Shell, você deve sempre dar um comando em cada línea. Para agrupar comandos em uma mesma línea teremos que separá-los por ponto-e-vírgula. Então:
>
>
Antes de hablar sobre el uso de los paréntesis dejame explicar rapidamente acerca del uso del punto y coma (;). Cuando esté en el Shell, tu siempre debes dar un comando en cada linea. Para agrupar comandos en una misma línea tenemos que separarlos por punto y coma. De esta forma:
 
$ pwd ; cd /etc; pwd; cd -; pwd
Line: 386 to 385
 /home/meudir
Changed:
<
<
Neste exemplo, listei o nome do diretório corrente com o comando pwd, mudei para o diretório /etc, novamente listei o nome do diretório e finalmente voltei para o diretório onde estava anteriormente (cd -), listando seu nome. Repare que coloquei o ponto-e-vírgula (;) de todas as formas possíveis para mostrar que não importa se existe espaços em branco antes ou após este caracter.
>
>
En este ejemplo, listé el nombre del directório corriente con el comando pwd, me cambié para el directório /etc, nuevamente listé el nombre del directório y finalmente volví para el directório donde estaba anteriormente (cd -), listando su nombre. Note que coloqué el punto y coma (;) de todas las formas posibles para mostrar que no importa si existen espacios en blanco antes o después de este caracter.
 
Changed:
<
<
Finalmente vamos ver o caso dos parênteses. Veja só o caso a seguir, bem parecido com o exemplo anterior:
>
>
Finalmente vamos ver el caso de los paréntesis. Vea el caso a seguir, bien parecido con el ejemplo anterior:
 
$ (pwd ; cd /etc ; pwd;)
Changed:
<
<
/home/meudir
>
>
/home/midir
 /etc/ $ pwd
Changed:
<
<
/home/meudir
>
>
/home/midir
 
Changed:
<
<
    - Quequeiiisso minha gente? Eu estava no /home/meudir, mudei para o /etc, constatei que estava neste diretório com o pwd seguinte e quando o agrupamento de comandos terminou, eu vi que continuava no /home/meudir, como se eu nunca houvesse saído de lá!
>
>
    - Qué es eso, por amor del Shell!? Yo estaba en /home/midir, me cambié para el /etc, verifiqué que estaba en ese directório con el pwd seguiente y cuando el agrupamiento de comandos terminó, vi que continuaba en el /home/midir, como si nunca hubiera salido de alli!
 
Changed:
<
<
    - Ih! Será que é tem coisa de mágico aí?
>
>
    - Ah! Será que es cosa de mago?
 
Changed:
<
<
    - Tá me estranhando, rapaz? Não é nada disso! O interessante do uso de parênteses é que ele invoca um novo Shell para executar os comandos que estão no seu interior. Desta forma, realmente fomos para o diretório /etc, porém quando todos os comandos dentro dos parênteses foram executados, o novo Shell que estava no diretório /etc morreu e voltamos ao Shell anterior cujo diretório corrente era /home/meudir. Faça outros testes usando cd, e ls para você firmar o conceito.
>
>
    - No me confundas, amigo? No es nada de eso! Lo interesante del uso de paréntesis es que él llama a un nuevo Shell para ejecutar los comandos que están en su interior. De esta forma, realmente fuimos para el directório /etc, sin embargo cuando todos los comandos adentro de los paréntesis fueron ejecutados, el nuevo Shell que estaba en el directório /etc murió y volvimos a Shell anterior cuyo directório corriente era /home/midir. Haz otras pruebas usando cd, y ls para que dejes este concepto bien firme.
 
Changed:
<
<
Agora que já conhecemos estes conceitos veja só este exemplo a seguir:
>
>
Ahora que ya conocemos estes conceptos vea este ejemplo que sigue:
 
Changed:
<
<
$ mail suporte << FIM > Ola suporte, hoje as ‘date "+%H:%M"‘ > ocorreu novamente aquele problema > que eu havia reportado por > telefone. Conforme seu pedido > ai vai uma listagem dos arquivos > do diretorio:
>
>
$ mail apoyo << FIM > Hola apoyo, hoy a las ‘date "+%H:%M"‘ > ocorrió nuevamente aquel problema > que ya habia informado por > teléfono. De acuerdo con su pedido > ahí va una lista de los archivos > del directorio:
 > ‘ls —l‘
Changed:
<
<
> Abracos a todos.
>
>
> Abrazos a todos.
 > FIM
Changed:
<
<
Finalmente agora temos conhecimento para mostrar o que havíamos conversado sobre here document. Os comandos entre crases (`) serão priorizados e portanto o Shell os executará antes da instrução mail. Quando o suporte receber o e-mail, verá que os comandos date e ls foram executados imediatamente antes do comando mail, recebendo então uma fotografia do ambiente no momento em que a correspondência foi enviada.
>
>
Finalmente ahora tenemos el conocimiento para mostrar lo que habiamos conversado sobre here document. Los comandos entre acentos invertidos (`) tendrán prioridad y por tanto el Shell los ejecutará antes de la instrucción mail. Cuando el apoyo reciba el e-mail, verá que los comandos date y ls fueron ejecutados inmediatamente antes del comando mail, recibiendo entonces una fotografía del ambiente en el momento en que la correspondencia fue enviada.
 
Changed:
<
<
O prompt primário default do Shell, como vimos, é o cifrão ($), porém o Shell usa o conceito de prompt secundário, ou de continuação de comando, que é enviado para a pantalla quando há uma quebra de línea e a instrução não terminou. Esse prompt, é representado por um sinal de maior (>), que vemos precedendo a partir da 2ª línea do exemplo.
>
>
El prompt primario default del Shell, como vimos, es el símbolo de pesos ($), sin embargo el Shell usa el concepto de prompt secundario, o de continuación de comando, que es enviado para la pantalla cuando hay un quiebre de linea y la instrucción no terminó. Ese prompt, es representado por un símbolo de mayor (>), que vemos precediendo a partir de la 2ª linea del ejemplo.
 
Changed:
<
<
Para finalizar e bagunçar tudo, devo dizer que existe uma construção mais moderna que vem sendo utilizada como forma de priorização de ejecución de comandos, tal qual as crases (`). São as construções do tipo $(cmd), onde cmd é um (ou vários) comando que será(ão) executado(s) com prioridade em seu contexto.
>
>
Para finalizar y revolver todo, debo decir que existe una construcción mas moderna que viene siendo utilizada como forma de priorizar la ejecución de comandos, tal cual los acentos invertidos (`). Son las construcciones del tipo $(cmd), donde cmd es un (o varios) comando(s) que será(n) ejecutado(s) con prioridad en su contexto.
 
Changed:
<
<
Assim sendo, o uso de crases (`) ou construções do tipo $(cmd) servem para o mesmo fim, porém para quem trabalha com sistemas operacionais de diversos fornecedores (multiplataforma), aconselho o uso das crases, já que o $(cmd) não foi portado para todos os sabores de Shell. Aqui dentro do Botequim, usarei ambas as formas, indistintamente.
>
>
De esta forma, el uso de acentos invertidos (`) o construcciones del tipo $(cmd) sirven para el mismo fin, sin embargo para quien trabaja con sistemas operacionales de diversos fabricantes (multiplataforma), aconsejo el uso de los acentos invertidos, ya que el $(cmd) no fue trasladado para todos los sabores de Shell. Aqui dentro del Bar, usaré las dos formas, indistintamente.
 
Changed:
<
<
Vejamos novamente o exemplo dado para as crases sob esta nova ótica:
>
>
Veamos nuevamente el ejemplo dado para los acentos invertidos, ahora con una nueva visión:
 
Changed:
<
<
$ echo Existem $(who | grep wc -l) usuários conectados Existem 8 usuários conectados
>
>
$ echo Existen $(who | grep wc -l) usuarios conectados Existen 8 usuarios conectados
 
Changed:
<
<
Veja só este caso:
>
>
Mira este caso:
 
Changed:
<
<
$ Arqs=ls $ echo $Arqs
>
>
$ Archs=ls $ echo $Archs
 ls
Changed:
<
<
Neste exemplo eu fiz uma atribuição (=) e executei uma instrução. O que eu queria era que a variável $Arqs, recebesse a saída do comando ls. Como as instruções de um script são interpretadas de cima para baixo e da esquerda para a direita, a atribuição foi feita antes da ejecución do ls. Para fazer o que desejamos é necessário que eu priorize a ejecución deste comando em detrimento da atribuição e isto pode ser feito de qualquer uma das maneiras a seguir:
>
>
En este ejemplo, hice una atribución (=) y ejecuté una instrucción. Lo que quería era que la variable $Archs, recebiese la salida del comando ls. Como las instrucciones de un script son interpretadas de arriba para abajo y de la izquierda para la derecha, la atribución fue hecha antes de la ejecución del ls. Para hacer lo que deseamos es necesario que le dé prioridad a la ejecución de este comando en perjuicio de la atribución y esto puede ser hecho de cualquer una de las maneras a seguir:
 
Changed:
<
<
$ Arqs=`ls`
>
>
$ Archs=`ls`
 

ou:

Changed:
<
<
$ Arqs=$(ls)
>
>
$ Archs=$(ls)
 
Changed:
<
<
Para encerrar este assunto vamos ver só mais um exemplo. Digamos que eu queira colocar dentro da variável $Arqs a listagem longa (ls -l) de todos os arquivos começados por arq e seguidos de um único caracter (?). Eu deveria fazer:
>
>
Para cerrar este asunto con broche de oro, vamos a ver un último ejemplo. Digamos que quiera colocar dentro de la variable $Archs la lista larga (ls -l) de todos los archivos comenzados por arch y seguidos de un único caracter (?). Yo deberia hacer:
 
Changed:
<
<
$ Arqs=$(ls -l arq?)
>
>
$ Archs=$(ls -l arch?)
 

ou:

Changed:
<
<
$ Arqs=`ls -l arq?`
>
>
$ Arqs=`ls -l arch?`
 
Changed:
<
<
Mas veja:
>
>
Sin embargo, ve esto:
 
Changed:
<
<
$ echo $Arqs -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql
>
>
$ echo $Archs -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arch1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arch2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 archl
 
Changed:
<
<
    - Pô, saiu tudo embolado!
>
>
    - Caramba! salió todo junto!
 
Changed:
<
<
    - Pois é cara, como eu já te disse, se você deixar o Shell “ver” os espaços em branco, sempre que houver diversos espaços juntos, eles serão trocados por apenas um. Para que a listagem saia bonitinha, é necessário proteger a variável da interpretação do Shell, assim:
>
>
    - Eso mismo, como ya te dije, si tu dejas que el Shell “vea” los espacios en blanco, siempre que haya diversos espacios juntos, ellos serán cambiados por uno solo. Para que la lista salga bien bonita, es necesario proteger la variable de la interpretación de Shell, así:
 
Changed:
<
<
$ echo "$Arqs" -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql
>
>
$ echo "$Archs" -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arch1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arch2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 archl
 
Changed:
<
<
    - Olhe, amigo, vá treinando esses exemplos, porque, quando nos encontrarmos novamente, vou lhe explicar uma série de instruções típicas de programação Shell. Tchau! Ahh! Só mais uma coisinha que eu ia esquecendo de lhe dizer. Em Shell, o "jogo da velha" (#) é usado quando desejamos fazer um comentário.
>
>
    - Y ahora, amigo, anda practicando esos ejemplos, porque, cuando nos encontremos nuevamente, te voy a explicar una serie de instrucciones típicas de programación Shell. Chau! Ahh! Solamente una cosita mas que me estaba olvidando de decirte. En Shell, el símbolo (#) es usado cuando deseamos hacer un comentario.
 
Changed:
<
<
$ exit # pede a conta ao garcon frown
>
>
$ exit # pidele la cuenta al mozo frown
 
Changed:
<
<
Qualquer dúvida ou falta de companhia para um chope ou até para falar mal dos políticos é só mandar um e-mail para julio.neves@gmail.com. Vou aproveitar também para mandar o meu jabá: diga para os amigos que quem estiver afim de fazer um curso porreta de programação em Shell que mande um e-mail para julio.neves@uniriotec.br para informar-se.
>
>
Cualquer duda o falta de compañia para tomar un chopp o hasta para hablar mal de los políticos lo único que tienes que hacer es mandarme un e-mail para julio.neves@gmail.com. Voy aprovechar tambiém para mandar mi publicidad: digale a los amigos que quien quiera hacer un curso nota diez de programación en Shell que mande un e-mail para julio.neves@uniriotec.br para informarse.
 
Changed:
<
<
Valeu!
>
>
Gracias y hasta la próxima!
 

Revision 101 Sep 2006 - Main.HumbertoPina

Line: 1 to 1
Added:
>
>

Conversas de Bar - Parte I

Diálogo escuchado entre un Linuxer y un empujador de mouse:

    - Quién es el Bash?

    - El Bash es el hijo mas nuevo de la familia Shell.

    - Espera ahí! Quieres dejarme loco? Tenía una duda y ahora me dejas con dos!

    - No, loco ya eras antes de aparecer por aqui. Desde que decidiste usar aquél sistema operacional con el cual tienes que dar reinicio en tu máquina unas diez veces por dia y no tienes dominio ninguno sobre lo que está pasando en el computador. Pero deja eso para atrás, te voy a explicar lo que es el Shell y los componentes de su familia y al final de la explicación me dirás: "Mi Dios del Shell! Porque no opté antes por Linux?".

El Ambiente Linux

Para que entiendas lo que es y como funciona el Shell, primero te mostraré como funciona el ambiente en capas de Linux. Da una mirada atenta en el gráfico que sigue:

Visión del shell en relación al Kernel de Linux

En este gráfico da para ver que la capa de hardware es la mas profunda estando formada por los componentes físicos de tu computador. Envolviendo ésta, viene la capa del kernel que es el corazón de Linux, su núcleo, y es quien hace que el hardware funcione, efectuando su manejo y control. Los programas y comandos que envuelven el kernel, lo utilizam para realizar las tareas especificas para las cuales fueron desarrolladas. Encerrando todo eso viene el Shell que tiene este nombre porque en ingles, Shell significa concha, envoltura, o sea que, queda entre los usuarios y el sistema operacional, de forma que todo lo que interacciona con el sistema operacional, tiene que pasar por su filtro.

El Ambiente Shell

Bueno, si para llegar al núcleo de Linux, o sea al kernel que es lo que le interesa a cualquier aplicativo, es necesario el filtro del Shell, vamos entonces a entender como es que funciona, de forma de sacar el mayor provecho a las innúmeras facilidades que él nos ofrece.

El Linux por definición es un sistema multiusuario - no podemos nunca olvidar ésto – y para permitir el acesso de determinados usuarios e impedir la entrada de outros, existe un arquivo llamado /etc/passwd que además de proveer datos para esta función, especie de "guardián de puerta" del Linux, tambiém pasa informaciones para el login de aquellos que consiguieron pasar por esta primera barrera. El último campo de sus registros, informa al sistema cual es el_Shell_ que la persona va a recebir cuando se "logue" (Ajjjjj!!!).

Pinguim com placa de dica Cuando dije que el último campo del /etc/passwd informa al sistema cual es el Shell que el usuario va a recebir al "logarse", es para ser interpretado literalmente, o sea, si en este campo de su registro está prog, la persona al accesar al sistema recibirá la pantalla de ejecución del programa prog y al terminar la ejecución saldrá inmediatamente con un logout. Imagine cuanto podemos aumentar la seguridad con este simples truco.

Te acuerdas que te mencioné de la familia Shell? Exactamente, vamos a comenzar a entender esto: el Shell, que se vale de la imagen de una concha envolviendo el sistema operacional propiamente dicho, es el nombre genérico para tratar los hijos de esta idea que, con el correr de los años de existencia del sistema operacional Unix fueron apareciendo. Actualmente existen diversos “sabores” de Shell, entre ellos destaco el sh (Bourne Shell), el ksh (Korn Shell), bash (Bourne Again Shell) y el csh (C Shell).

Una visión rápida em los Principales Sabores de Shell

Bourne Shell (sh)

Desarrollado por Stephen Bourne de la Bell Labs (de AT&T donde tambiém fue desarrollado el Unix), este fue durante muchos años el Shell padrón del sistema operacional Unix. Es tambiém llamado de Standard Shell por haber sido durante varios años, el único y hasta hoy es el mas utilizado ya que fue transportado para todos los ambientes Unix y distros Linux.

Korn Shell (ksh)

Desarrollado por David Korn, tambiém de la Bell Labs, es un superconjunto del sh, o sea, posee todas las facilidades del sh y a ellas se agregaron muchas otras. La compatibilidade total con el sh viene trayendo muchos usuarios y programadores de Shell para este ambiente.

Boune Again Shell (bash)

Este es el Shell mas moderno y cuyo número de adeptos crece mas en todo el mundo, sea por ser el Shell default de Linux, su sistema operacional natural, o sea por su gran diversidad de comandos, que incorpora inclusive diversas instrucciones características del C Shell.

C Shell (csh)

Desarrollado por Bill Joy de la Berkley University es el Shell mas utilizado en ambientes *BSD e Xenix. La estrutura de sus comandos es bastante similar al de la lenguage C. Su grande pecado fue ignorar la compatibilidad con el sh, partiendo por un camino propio.

Además de estos Shells existen otros, pero contigo voy a hablar solamente sobre los tres primeros, tratandolos genéricamente por Shell y señalando las peculiaridades de cada uno que eventualmente tengan.

Explicando el funcionamento de Shell

El Shell es el primer programa que tu ganas al "logarte" en Linux. Es él quien va a resolver una cantidad de cosas de forma de no recargar el kernel con tareas repetitivas, aliviandolo para tratar asuntos mas importantes. Como cada usuario posee su propio Shell interponiendose entre él y el Linux, es el Shell quien interpreta los comandos que son teclados y examina sus sintaxes, pasándolos desmenuzados para su ejecución.

    - Alto ahí, no apure caballo flaco! Ese negocio de interpretar comandos no tiene nada que ver con intérprete, no es cierto?

    - Tiene que ver si, la verdad el Shell es un interpretador (o será intérprete realmente) que trae consigo un poderoso lenguaje con comandos de alto nivel, que permite la construcción de loops (lazos), tomas de decisión y de almacenamiento de valores en variables, como te voy mostrar ahora.

Voy a explicarte las principales tareas que el Shell cumple, por su orden de ejecución. Prestame mucha atención en este orden porque él es fundamental para compredener el resto de nuestra conversa.

Exámen de la Línea de Comandos

En este exámen el Shell identifica los caracteres especiales (reservados) que tienen significado para la interpretación de la línea,inmediatamente después verifica si la línea pasada es una atribución o un comando.

Atribución

Si el Shell encuentra dos campos separados por un símbolo de igual (=) sin espacios en blanco entre ellos, identifica esta secuencia como una atribución.

Exemplos

$ ls linux linux

En este ejemplo el Shell identificó el ls como un programa y el linux como un parámetro pasado para el programa ls.

$ valor=1000

En este caso, por no haber espacios en blanco (ya da para percibir que el espacio en blanco es un de los caracteres reservados) el Shell identificó una atribución y colocó 1000 en la variable valor.

Pinguim com placa de dica Nunca Haga:

$ valor = 1000 bash: valor: not found

Aqui el Bash achó la palabra valor aislada por blancos y juzgó que tu habrias mandado ejecutar un programa llamado valor, para el cual estarias pasando dos parámetros: = e 1000.

Comando

Cuando una línea es digitada en el prompt de Linux, ella es dividida en pedazos separados por espacios en blanco: el primer pedazo es el nombre del programa que tendrá su existencia investigada; identifica en seguida, en este orden: opciones/parámetros, redireccionamentos y variables.

Cuando el programa identificado existe, el Shell verifica los permisos de los archivos involucrados (inclusive el propio programa), dando un señal de error en caso de que tu no estés autorizado a ejecutar esta tarea.

Resolución de Redireccionamentos

Después de identificar los componentes de la línea que teclaste, el Shell parte para la resolución de redireccionamentos. El Shell tiene incorporado a su elenco de ventajas lo que llamamos de redireccionamento, que puede ser de entrada (stdin), de salida (stdout) o de errores (stderr), de acuerdo a como te explicaré a seguir.

Substitución de variables

En este puntonto, el Shell verifica si las eventuales variables (parámetros comenzados por $), encontradas en el campo del comando, están definidas y las substituye por sus valores actuales.

Substitución de Meta caracteres

Si algún metacaracter (*, ? ou []) es hallado en la línea de comando, es aqui que será substituído por sus posibles valores. Suponiendo que el único archivo en su directorio corriente que comienza por la letra n sea un directorio llamado nombregrandeparacaramba, si tu haces:

$ cd n*

Como hasta aqui quien está trabajando su línea es el Shell y el comando (programa) cd todavia no fue ejecutado, el Shell transforma el n* en nombregrandeparacaramba y el comando cd será ejecutado con éxito.

Pasa línea de Comando para el kernel

Completadas las anteriores tareas, el Shell monta la línea de comandos, ya con todas las substituciones hechas, llama el kernel para ejecutarla en un nuevo Shell (Shell hijo), ganando un número de proceso (PID o Process IDentification) y permanece inactivo, durmiendo una siestita, durante la ejecución del programa. Una vez finalizado este proceso (junto con el Shell hijo), recibe nuevamente el control y, exhibiendo un prompt, muestra que está listo para ejecutar otros comandos.

Descifrando la Piedra de Roseta

Para sacarse aquella sensación que tienes cuando ves un script Shell, que se parece mas a una sopa de letras o a un jeroglífico te mostraré los principales caracteres especiales para que puedas sali por ahí como el Jean-François Champollion descifrando la Piedra de Roseta (vale la pena buscar googlada para descubrir quién es este gaucho).

caracteres para retirar el sentido

Es eso mismo, cuando no deseamos que el Shell interprete un caracter especial, debemos "esconderlo" de él. Eso puede ser hecho de tres formas distintas:

Apóstrofe o plic (')

Cuando el Shell ve una cadena de caracteres entre apóstrofes ('), él saca los apóstrofes de la cadena y no interpreta su contenido.

$ ls linux* linuxmagazine $ ls 'linux*' bash: linux* no such file or directory

En el primer caso el Shell "abrió" el asterisco y descubrió el archivo linuxmagazine para listar. En el segundo, los apóstrofes evitaron la interpretación del Shell y dió la respuesta que no existe el archivo linux*.

Contrabarra o Barra Invertida (\)

Idéntico a los apóstrofes excepto que la barra invertida evita la interpretación del caracter que la sigue solamente.

Suponga que accidentalmente has creado un archivo llamado * (asterisco) – que algunos sabores de Unix permiten - y deseas eliminarlo. Si tu hicieras:

$ rm *

Tendrias un grande problema, ya que el rm borraria todos los archivos del directorio corriente. La mejor forma de hacerlo es:

$ rm \*

De esta forma, el Shell no interpretaria el asterisco, y por consiguiente no haria su abertura

Haga la siguiente experiencia científica:

$ cd /etc $ echo '*' $ echo \* $ echo *

Viste la diferencia? Entonces no precisa explicar mas.

Aspas (")

Exactamente igual a apóstrofe excepto que, si la cadena entre aspas contiene un signo de pesos ($), un acento invertido (`), o una barra invertida (\), estos caracteres seran interpretados por el Shell.

No precisa preocuparte ahora con eso, todavia no te di ejemplos del uso de las aspas porque todavia no conoces el signo de pesos ($) ni el acento invertido (`). De aqui en adelante veremos con mucho detalle el uso de estos caracteres especiales, lo mas importante es entender el significado de cada uno.

caracteres de redireccionamento

La mayoria de los comandos tiene una entrada, una salida y puede generar errores. Esta entrada es llamada Entrada Padrón o stdin y su default es el teclado del terminal. Análogamente, la salida del comando es llamada Salida Padrón o stdout y su default es la pantalla del terminal. Para la pantalla tambiém son enviadas por default los mensajes de error oriundas del comando que em este caso es la llamada Salida de Error Padrón o stderr. Veremos ahora como alterar este estado de cosas.

Vamos a hacer un programa tartamudo. Para eso haga:

$ cat

El cat es una instrucción que lista el contenido del archivo especificado para la Salida Padrón (stdout). En caso que la entrada no esté definida, el espera los datos de la stdin. Mira, como yo no especifiqué la entrada, el está esperándola por el teclado (Entrada Padrón) y como tambiém no cité la salida, lo que yo digitar irá para la pantalla (Salida Padrón) haciendo de esta forma, como habia propuesto un programa tartamudo. Pruebe, el teclado no muerde!

Redireccionamento de la Salida Padrón

Para especificar una salida de programa usamos el > (mayor que) o el >> (mayor, mayor) seguido del nombre del archivo para el cual se desea mandar la salida.

Vamos transformar el programa tartamudo en un editor de textos (que pretensión eh!). smile

$ cat > Arq

El cat continua sin tener una entrada especificada, por lo tanto está aguardando que los datos sean digitados, sin embargo su salida está siendo desviada para el archivo Arq. De esta forma, todo lo que esta siendo digitado está yendo para dentro de Arq, de forma que hicimos el editor de textos mas corto y pobre del planeta.

Si hacer nuevamente:

$ cat > Arq

Los datos contenidos en Arq se perderán, ya que antes del redireccionamento el Shell creará un Arq vacio. Para colocar mas informaciones en el final del archivo deberia haber hecho:

$ cat >> Arq

Pinguim com placa de atenção Como ya te habia dicho, el Shell resuelve la linea y despues manda el comando para la ejecución. Asi, si tu redireccionas la salida de un archivo para el mismo, primero el Shell "vacia" este archivo y después manda el comando para ejecución, de esta forma acabas de perder el contenido de tu querido archivo.

Con esto notamos que el >> (mayor mayor) sirve para incluir texto em el final del archivo.

Redireccionamento de la Salida de Error Padrón

Así como el default del Shell es recibir los datos del teclado y mandar las salidas para la pantalla, los errores tambiém serán enviados para la pantalla si tu no especificaste para donde deverán ser enviados. Para redireccionar los errores use 2> SalidaDeError. Vea que entre el número 2 y el símbolo de mayor (>) no existe espacio en blanco.

Pinguim com placa de atenção Preste atención! No confunda >> con 2>. El primero anexa datos al final de un archivo, en cuanto el segundo redirecciona la Salida de Error Padrón (stderr) para un archivo que está siendo designado. Esto es importante!

Suponga que durante la ejecución de un script tu puedes, o no (dependiendo del rumbo tomado por la ejecución del programa), haber creado un archivo llamado /tmp/seraqueexiste$$. Para no dejar basura en su disco, al final del script tu colocarias una línea:

$ rm /tmp/seraqueexiste$$

En caso que el archivo no existiese seria enviado para la pantalla un mensaje de error. Para que eso no ocurra se debe hacer:

$ rm /tmp/seraqueexiste$$ 2> /dev/null

Sobre el ejemplo que acabamos de ver tengo dos consejos a dar:

Pinguim com placa de dica Consejo # 1

El $$ contiene el PID, o sea, el número de su proceso. Como Linux es multiusuario, es de buen gusto anexar siempre el $$ a los nombre de los archivos que serán usados por varias personas para no haber problemas de propriedad, o sea, en caso que nombrases tu archivo simplemente como seraqueexiste, el primero que lo usase (creandolo entonces) seria su dueño y todos los otros obtendrian un error cuando intentasem grabar algo em él.

Para que hagas un test em la Salida de Error Padrón directo en el prompt del Shell, te voy a dar otro ejemplo. Haga:

$ ls noexiste bash: noexiste no such file or directory $ ls noexiste 2> archivodeerrores $ $ cat archivodeerrores bash: noexiste no such file or directory

En este ejemplo, vimos que cuando hicimos un ls en noexiste, tuvimos un mensaje de error. Después, redireccionamos la Salida de Error Padrón para archivodeerros y executamos el mismo comando, recebiendo solamente el prompt en la pantalla. Cuando listamos el contenido del archivo para el cual fue redireccionada la Salida de Error Padrão, vimos que el mensaje de error habia sido almacenado em él. Haz este test.

Pinguim com placa de dica Dica # 2

    - Quién es ese tal de /dev/null?

    - En Unix existe un archivo fantasma. Llamase /dev/null. Todo lo que es mandado para este archivo desaparece. Se parece a un Agujero Negro. En el caso del ejemplo, como no me interesaba guardar el posible mensaje de error proveniente del comando rm, lo redireccioné para este archivo.

Es interesante notar que estas caracteres de redireccionamento son acumulativos, o sea, si em el ejemplo anterior hicieramos:

$ ls naoexiste 2>> archivodeerrores

el mensaje de error proveniente del ls seria anexado al final de archivodeerrores.

Redireccionamento de la Entrada Padrón

Para hacer el redireccionamento de la Entrada Padrón usamos el < (menor que).

    - Y para que sirve eso? - me vas a preguntar.

    - Dejame darte un ejemplo que vas a entender rapidito.

Suponga que quieres mandar un mail para te jefe. Para el Jefe queremos lo mejor, no es así? entonces, al contrario de salir redirigindo el mail directo en el prompt de la pantalla de forma de que sea imposible la corrección de una frase anterior donde, sin querer, escribió un "nosotros va", tu editas un archivo con el contenido del mensaje y después de unas quince verificaciones sin constatar ningún error, decide enviarlo y para eso hace:

$ mail jefe < archivoconmailparaeljefe

Tu jefe receberá entonces el contenido del archivoconmailparaeljefe.

Otro tipo de redireccionamento muy loco que el Shell te permite es el llamado here document. Es representado por << (menor menor) y sirve para indicar al Shell que el alcance de un comando comenza en la línea siguiente y termina cuando encuentra una línea cuyo contenido sea unicamente la etiqueta que sigue al símbolo <<.

Vea el fragmento del script a seguir, con una rutina de ftp:

ftp -ivn hostremoto << fimftp
user $Usuario $Seña
binary
get archivoremoto
fimftp

En este pedacito de programa tenemos una cantidad de detalles interesantes: 1 Las opciones que usé para el ftp (-ivn) sirven para ir listando todo lo que está ocurriendo (—v de verbose), para no perguntar si tu tienes seguridad de que deseas transmitir cada archivo (—i de interactive), y finalmente la opción —n sirve para decirle al ftp para que no solicite el usuario y su seña, pues estos serán informados por la instrucción específica (user); 1 Cuando usé el << fimftp, estaba diciendo lo seguinte para el intérprete:
- Mira aqui Shell, no se meta en nada a partir de aqui hasta encontrar oel label fimftp. Tu no entenderias nada, ya que son instrucciones específicas del comando ftp y tu no entendies nada de ftp.
Si solo fuera eso, seria simple, pero por el mismo ejemplo dá para ver que existen dos variables ($Usuário e $Senha), que el Shell va a resolver antes del redireccionamento. Sin embargo, la gran ventaja de este tipo de construcción es que ella permite que los comandos tambiém sean interpretados dentro del alcance del here document, lo que tambiém contraria lo que acabe de decir. Enseguida explico como ese negocio funciona. En este momento todavia no dá, están faltando herramientas. 1 El comando user es del repertorio de instrucciones del ftp y sirve para pasar el usuario y la seña que habian sido leídos em una rutina anterior a ese fragmento de código y colocados respectivamente en las dos variables: $Usuário y $Senha. 1 El binary es otra instrucción del ftp, que sirve para indicar que la transferencia de archivoremoto será hecha en modo binario, o sea, el contenido del archivo no será interpretado para saber se está en ASCII, EBCDIC, ... 1 El get archivoremoto dice al ftp para sacar ese archivo de hostremoto y traerlo para nuestro host local. Si fura para mandar o archivo, usariamos el comando put.

%ATENCIÓN_INI% Un error muy frecuente en el uso de labels (como el fimftp del ejemplo anterior) es causado por la presencia de espacios en blanco antes o después del mismo. Quede muy atento en relación a esto, por que este tipo de errores causa muchos dolores de cabeza a los programadores, hasta que sea detectado. Acuérdese: un label que se precie tiene que tener una linea entera solamente para él. %_INI% Un_FIM%

    - Está bem, está bem! Eu sei que dei uma viajada e entrei pelos comandos do ftp, fugindo ao nosso assunto que é Shell, mas como é sempre bom aprender e é raro as pessoas estarem disponíveis para ensinar...

Redirecionamento de Comandos

Os redirecionamentos que falamos até aqui sempre se referiam a arquivos, isto é mandavam para arquivo, recebiam de arquivo, simulavam arquivo local, ... O que veremos a partir de agora redireciona a saída de um comando para a entrada de outro. É utilíssimo e quebra os maiores galhos. Seu nome é pipe (que em inglês significa tubo, já que ele encana a saída de um comando para a entrada de outro) e sua representação é uma barra vertical (|).

$ ls | wc -l     21

O comando ls passou a lista de arquivos para o comando wc, que quando está com a opção –l conta a quantidade de línea que recebeu. Desta forma, podemos afirmar categoricamente que no meu diretório existiam 21 arquivos.

$ cat /etc/passwd |sort | lp

Esta línea de comandos manda a listagem do arquivo /etc/passwd para a entrada do comando sort. Este a classifica e manda-a para o lp que é o gerenciador do spool de impressão.

caracters de Ambiente

Quando quer priorizar uma expressão você coloca-a entre parênteses não é? Pois é, por causa da aritmética é normal pensarmos deste jeito. Mas em Shell o que prioriza mesmo são as crases (`) e não os parênteses. Vou dar exemplos de uso das crases para você entender melhor.

Eu quero saber quantos usuários estão "logados" no computador que eu administro. Eu posso fazer:

$ who | wc -l     8

O comando who passa a lista de usuários conectados para o comando wc –l que conta quantas líneas recebeu e lista a resposta na pantalla. Pois bem, mas ao invés de ter um oito solto na pantalla, o que eu quero é que ele esteja no meio de uma frase.

Ora para mandar frases para a pantalla eu uso o comando echo, então vamos ver como é que fica:

$ echo "Existem who | wc -l usuários conectados" Existem who | wc -l usuários conectados

Hi! Olha só, não funcionou! É mesmo, não funcionou e não foi por causa das aspas que eu coloquei, mas sim por que eu teria que ter executado o who | wc -l antes do echo. Para resolver este problema, tenho que priorizar esta segunda parte do comando com o uso de crases, fazendo assim:

$ echo "Existem `who | wc -l` usuários conectados" Existem 8 usuários conectados

Para eliminar esse monte de brancos antes do 8 que o wc -l produziu, basta tirar as aspas. Assim:

$ echo Existem `who | wc -l` usuários conectados Existem 8 usuários conectados

Como eu disse antes, as aspas protegem tudo que esta dentro dos seus limites, da interpretação do Shell. Como para o Shell basta um espaço em branco como separador, o monte de espaços será trocado por um único após a retirada das aspas.

Antes de falar sobre o uso dos parênteses deixa eu mandar uma rapidinha sobre o uso de ponto-e-vírgula (;). Quando estiver no Shell, você deve sempre dar um comando em cada línea. Para agrupar comandos em uma mesma línea teremos que separá-los por ponto-e-vírgula. Então:

$ pwd ; cd /etc; pwd; cd -; pwd /home/meudir /etc/ /home/meudir

Neste exemplo, listei o nome do diretório corrente com o comando pwd, mudei para o diretório /etc, novamente listei o nome do diretório e finalmente voltei para o diretório onde estava anteriormente (cd -), listando seu nome. Repare que coloquei o ponto-e-vírgula (;) de todas as formas possíveis para mostrar que não importa se existe espaços em branco antes ou após este caracter.

Finalmente vamos ver o caso dos parênteses. Veja só o caso a seguir, bem parecido com o exemplo anterior:

$ (pwd ; cd /etc ; pwd;) /home/meudir /etc/ $ pwd /home/meudir

    - Quequeiiisso minha gente? Eu estava no /home/meudir, mudei para o /etc, constatei que estava neste diretório com o pwd seguinte e quando o agrupamento de comandos terminou, eu vi que continuava no /home/meudir, como se eu nunca houvesse saído de lá!

    - Ih! Será que é tem coisa de mágico aí?

    - Tá me estranhando, rapaz? Não é nada disso! O interessante do uso de parênteses é que ele invoca um novo Shell para executar os comandos que estão no seu interior. Desta forma, realmente fomos para o diretório /etc, porém quando todos os comandos dentro dos parênteses foram executados, o novo Shell que estava no diretório /etc morreu e voltamos ao Shell anterior cujo diretório corrente era /home/meudir. Faça outros testes usando cd, e ls para você firmar o conceito.

Agora que já conhecemos estes conceitos veja só este exemplo a seguir:

$ mail suporte << FIM > Ola suporte, hoje as ‘date "+%H:%M"‘ > ocorreu novamente aquele problema > que eu havia reportado por > telefone. Conforme seu pedido > ai vai uma listagem dos arquivos > do diretorio: > ‘ls —l‘ > Abracos a todos. > FIM

Finalmente agora temos conhecimento para mostrar o que havíamos conversado sobre here document. Os comandos entre crases (`) serão priorizados e portanto o Shell os executará antes da instrução mail. Quando o suporte receber o e-mail, verá que os comandos date e ls foram executados imediatamente antes do comando mail, recebendo então uma fotografia do ambiente no momento em que a correspondência foi enviada.

O prompt primário default do Shell, como vimos, é o cifrão ($), porém o Shell usa o conceito de prompt secundário, ou de continuação de comando, que é enviado para a pantalla quando há uma quebra de línea e a instrução não terminou. Esse prompt, é representado por um sinal de maior (>), que vemos precedendo a partir da 2ª línea do exemplo.

Para finalizar e bagunçar tudo, devo dizer que existe uma construção mais moderna que vem sendo utilizada como forma de priorização de ejecución de comandos, tal qual as crases (`). São as construções do tipo $(cmd), onde cmd é um (ou vários) comando que será(ão) executado(s) com prioridade em seu contexto.

Assim sendo, o uso de crases (`) ou construções do tipo $(cmd) servem para o mesmo fim, porém para quem trabalha com sistemas operacionais de diversos fornecedores (multiplataforma), aconselho o uso das crases, já que o $(cmd) não foi portado para todos os sabores de Shell. Aqui dentro do Botequim, usarei ambas as formas, indistintamente.

Vejamos novamente o exemplo dado para as crases sob esta nova ótica:

$ echo Existem $(who | grep wc -l) usuários conectados Existem 8 usuários conectados

Veja só este caso:

$ Arqs=ls $ echo $Arqs ls

Neste exemplo eu fiz uma atribuição (=) e executei uma instrução. O que eu queria era que a variável $Arqs, recebesse a saída do comando ls. Como as instruções de um script são interpretadas de cima para baixo e da esquerda para a direita, a atribuição foi feita antes da ejecución do ls. Para fazer o que desejamos é necessário que eu priorize a ejecución deste comando em detrimento da atribuição e isto pode ser feito de qualquer uma das maneiras a seguir:

$ Arqs=`ls`

ou:

$ Arqs=$(ls)

Para encerrar este assunto vamos ver só mais um exemplo. Digamos que eu queira colocar dentro da variável $Arqs a listagem longa (ls -l) de todos os arquivos começados por arq e seguidos de um único caracter (?). Eu deveria fazer:

$ Arqs=$(ls -l arq?)

ou:

$ Arqs=`ls -l arq?`

Mas veja:

$ echo $Arqs -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql

    - Pô, saiu tudo embolado!

    - Pois é cara, como eu já te disse, se você deixar o Shell “ver” os espaços em branco, sempre que houver diversos espaços juntos, eles serão trocados por apenas um. Para que a listagem saia bonitinha, é necessário proteger a variável da interpretação do Shell, assim:

$ echo "$Arqs" -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql

    - Olhe, amigo, vá treinando esses exemplos, porque, quando nos encontrarmos novamente, vou lhe explicar uma série de instruções típicas de programação Shell. Tchau! Ahh! Só mais uma coisinha que eu ia esquecendo de lhe dizer. Em Shell, o "jogo da velha" (#) é usado quando desejamos fazer um comentário.

$ exit # pede a conta ao garcon frown

Qualquer dúvida ou falta de companhia para um chope ou até para falar mal dos políticos é só mandar um e-mail para julio.neves@gmail.com. Vou aproveitar também para mandar o meu jabá: diga para os amigos que quem estiver afim de fazer um curso porreta de programação em Shell que mande um e-mail para julio.neves@uniriotec.br para informar-se.

Valeu!

-- HumbertoPina - 01 Sep 2006

 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki-SL? Send feedback