opensuse
[Arriba] [Todas las Listas]

Re: [opensuse] Tipo diferente de pelar guiones

To: opensuse@xxxxxxxxxxxx
Subject: Re: [opensuse] Tipo diferente de pelar guiones
From: George OLson <grglsn765@xxxxxxxxx>
Date: Fri, 23 Sep 2011 22:16:11 +0800
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 23 Sep 2011 10:13:43 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nHoph3vNMlVboXX1SgZ7K5Jl1VOznVUK1uM7ZS5WzjA=; b=R/ppvI97/V2gC3OD2MK9qG2GN7w6S/vY/yI+O7/FcFho1bz27Z4tQNcvj/jU37KzJT EIkfzFt8/b6hJFrywF8d3ZEAk22GPVguTxW1dcto+1kSv14+6BPeaPj/nK2TQb5F15v/ 8YM54pBtQIvthD8k2Qtj+NrgbSjGTI7ho3aKk=
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <1316714545.4805326@mail.aljex.com>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
References: <4E7AED97.1000309@gmail.com> <1316714545.4805326@mail.aljex.com>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0
En 09/23/2011 02:02 AM, brian@xxxxxxxxx escribió:


-----Mensaje Original-----
De: "George *OLson"<*grglsn765@*xxxxxxxxx>
Envió: jueves, septiembre 22, 2011 4:11soy
A: "*suse"<opensuse@xxxxxxxxxxxx>
Tema: [*opensuse] tipo diferente de pelar guiones

descargué un programa que necesité del internet y el
programa de instalación era un archivo de guión con la extensión .*sh. Las
instrucciones del *developer dijo para correr el guión en una línea de orden
por escribir la orden:

./<*filename>

Pensé (*mistakenly) que podría correr cualquier pelar guión por escribir la orden
.<*filename>  (Con un espacio entre el punto y el *filename). Así que
intenté correrlo que manera, y conseguía el error "no puede ejecutar *binary
archivo".

Aun así, cuándo seguí el *developer instrucciones y escrito dentro
./<*filename>, el guión ejecutó perfectamente e instalado el programa.

Así que mi cuestión es, qué es la diferencia entre correr un archivo de guión
con el espacio

<de punto><de la orden><*filename>, por ejemplo "#>  . *myscript.*sh"

Y corriéndolo con punto

<><*slash><*filename>, por ejemplo  "#>  ./*myscript.*sh"?


Punto-espacial-*filename significa a fuente el archivo no #correr.

Cuándo te corrido un archivo tú *spawn un proceso nuevo y ejecutar el archivo en aquel proceso. Puesto que pelar guiones un paso extra pasa dentro que el guión especificado no es ejecutado, el *appropriate el intérprete es ejecutado, y QUE entonces lee el guión especificado. Al final que proceso de niño y todo es el entorno muere y va fuera. El proceso de padre es en control en el fondo durante aquello, y *resumes donde dejó fuera, *unaffected por cualquier cosa el proceso de niño  otro que sabiendo el valor de salida de procesos de niño.

*Sourcing Un archivo es bastante diferente.

Cuándo te fuente un archivo, ningún proceso de niño si *spawned. El proceso actual directamente lee y (prueba a) interpreta los archivos contenta igual cuando si habías escrito en las mismas líneas a mano en vuestro pelar puntual. Si hay una orden de salida en el archivo, vuestro actualmente corriendo pela saldrá y vuestro *xterm la ventana cerrará o serás *logged fuera de vuestro *ssh sesión *etc. Cualesquier variables de entorno que consiguen puesto o cambiado en el archivo todavía será puesto en vuestro entorno después del archivo es hecho. Si había un *cd orden, todavía serás sentando *wherever el archivo *cd'*d a.

Básicamente, es casi nunca corregir a archivos de fuente a mano en la orden interactiva incita. *Ok hay situaciones teóricas donde intencionadamente podrías querer hacer aquello, pero, generalmente ningún.

El propósito del *sourcing el mecanismo es para dejar un guión para incluir *chunks de configuración y código modular *settings de otros archivos en vez de teniendo que incluir todo dentro del guión él. Te deja para tener un guión en /*sbin aquello es igual en todas las  cajas como un *binary, todavía tiene sitio-específico *config variables en /*etc o incluso personal *config variables en /casa, y una copia sola de funciones de biblioteca en /*lib que guiones diferentes múltiples todos utilizan en vez de cada guión teniendo que tener una copia dentro de ellos.

También, *sourcing trabajos únicos si el ser de archivo *sourced es incluso lengua válida para el intérprete pasas para ser corriendo en el tiempo.

Dentro de un guión, el autor de guión sabe que el archivo ha *sourcing ES guión válido en la misma lengua como el guión de padre. Cuándo eres *logged dentro a una orden puntual, estás corriendo *bash, pero cualquier archivo aleatorio necesitas correr podría ser escrito en cualquier cosa. Podría contener perfectamente bueno *perl *syntax que podría resultar en *bash *overwriting archiva justo por habiendo un ">" *somewhere para caso. Incluso si tú sólo nunca  que puesto que *.*sh Archivos, todavía tienes el problema de entorno. *Poorly Los Guiones escritos no molestan estableciendo su entorno propio en el inicio, y no molesta utilizando la orden de salida para poner valores de salida significativa, y así que a menudo puedes conseguir fuera con *sourcing *poorly los guiones escritos y vuestra corriente pelan el proceso corre las órdenes incluidas y parece a todos trabajan bien. Pero si un guión correctamente escrito tuvo decir, alguna detección de error en él dónde utilizó la orden de salida para poner un valor de salida que el guión de padre puede leer, la orden de salida en el guión  de hecho *lo
*g tú completamente fuera de vuestro *xterm o *ssh sesión en el sitio.


*Thanks Para tomar el tiempo para escribir todo aquello. Aquello es una explicación realmente buena, y es ahora muy útil cuando aprendo más sobre escribir guiones.

George
--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
Puesto que órdenes adicionales, *e-correo: *opensuse+help@xxxxxxxxxxxx


On 09/23/2011 02:02 AM, brian@xxxxxxxxx wrote:


-----Original Message-----
From: "George OLson"<grglsn765@xxxxxxxxx>
Sent: Thursday, September 22, 2011 4:11am
To: "suse"<opensuse@xxxxxxxxxxxx>
Subject: [opensuse] different types of shell scripts

I downloaded a program that I needed off the internet and the
installation program was a script file with the extension .sh. The
instructions from the developer said to run the script on a command line
by typing the command:

./<filename>

I thought (mistakenly) that I could run any shell script by typing the
command .<filename>  (with a space between the dot and the filename). So
I tried to run it that way, and I got the error "cannot execute binary
file".

However, when I followed the developer's instructions and typed in
./<filename>, the script executed perfectly and installed the program.

So my question is, what is the difference between running a script file
with the command

<dot><space><filename>, for example "#>  . myscript.sh"

and running it with

<dot><slash><filename>, for example  "#>  ./myscript.sh"?


dot-space-filename means to source the file not run it.

When you run a file you spawn a new process and execute the file in that process. For shell scripts an extra step happens in that the specified script is not executed, the appropriate interpreter is executed, and THAT then reads the specified script. At the end that child process and all it's environment dies and goes away. The parent process is on hold in the background during that, and resumes where it left off, unaffected by anything the child process did other than knowing the child processes exit value.

Sourcing a file is quite different.

When you source a file, no child process if spawned. The current process directly reads and (tries to) interpret the files contents the same as if you had typed in the same lines manually at your shell prompt. If there is an exit command in the file, your currently running shell will exit and your xterm window will close or you'll be logged out of your ssh session etc. Any environment variables that get set or changed in the file will still be set in your environment after the file is done. If there was a cd command, you'll still be sitting wherever the file cd'd to.

Basically, it's almost never correct to source files manually at interactive command prompts. Ok there are theoretical situations where you might intentionally want to do that, but, generally no.

The purpose of the sourcing mechanism is to allow a script to include chunks of modular code and configuration settings from other files instead of having to include everything inside the script itself. It allows you to have a script in /sbin that's the same on all boxes like a binary, yet have site-specific config variables in /etc or even personal config variables in /home, and a single copy of library functions in /lib that multiple different scripts all use instead of each script having to have a copy inside themselves.

Also, sourcing only works if the file being sourced is even valid language for the interpreter you happen to be running at the time.

Inside a script, the script author knows that the file he's sourcing IS valid script in the same language as the parent script. When you're logged in to a command prompt, you're running bash, but any random file you need to run might be written in anything. It might contain perfectly good perl syntax that might result in bash overwriting files just by having a ">" somewhere for instance. Even if you only ever did that for *.sh files, you still have the environment problem. Poorly written scripts don't bother establishing their own environment at the start, and don't bother using the exit command to set meaningful exit values, and so you can often get away with sourcing poorly written scripts and your current shell process runs the included commands and seems to all work fine. But if a properly written script had say, some error detection in it where it used the exit command to set an exit value that the parent script can read, the exit command in the script will actually lo
g you all the way out of your xterm or ssh session on the spot.


Thanks for taking the time to write all that. That is a really good explanation, and is now very helpful as I learn more about writing scripts.

George
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>