Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
scripting:processtree [2015/08/06 03:08]
bill_thomson
scripting:processtree [2019/08/30 14:55] (current)
ersen [Bash playing with pipes]
Line 9: Line 9:
 Every process has its **own** environment space. Every process has its **own** environment space.
  
-The environment stores, among other things ​other stuff, data that's useful to us, The **environment variables**. These are strings in common ''​NAME=VALUE''​ form, but they are not related to shell variables. A variable named ''​LANG'',​ for example, is used by every program that looks it up in its environment to determinate the current locale.+The environment stores, among other things, data that's useful to us, the **environment variables**. These are strings in common ''​NAME=VALUE''​ form, but they are not related to shell variables. A variable named ''​LANG'',​ for example, is used by every program that looks it up in its environment to determinate the current locale.
  
 **__Attention:​__** A variable that is set, like with ''​MYVAR=Hello'',​ is **not** automatically part of the environment. You need to put it into the environment with the bash builtin command ''​export'':​ **__Attention:​__** A variable that is set, like with ''​MYVAR=Hello'',​ is **not** automatically part of the environment. You need to put it into the environment with the bash builtin command ''​export'':​
Line 17: Line 17:
 ===== Executing programs ===== ===== Executing programs =====
  
-All the diagrams of the process tree use names like "''​xterm''"​ or "''​bash''",​ but that's just to make it easier understand what's going on, it doesn'​t mean those processes are actually executed.+All the diagrams of the process tree use names like "''​xterm''"​ or "''​bash''",​ but that's just to make it easier ​to understand what's going on, it doesn'​t mean those processes are actually executed.
  
 Let's take a short look at what happens when you "​execute a program"​ from the Bash prompt, a program like "​ls":​ Let's take a short look at what happens when you "​execute a program"​ from the Bash prompt, a program like "​ls":​
Line 45: Line 45:
 ===== Bash playing with pipes ===== ===== Bash playing with pipes =====
  
-Pipes are a very powerful tool. You can connect the output of one process to the input of another process. We won't delve into pipin at this point, we just want to see how it looks in the process tree. Again, we execute some commands, this time, we'll run ''​ls''​ and ''​grep'':​+Pipes are a very powerful tool. You can connect the output of one process to the input of another process. We won't delve into piping ​at this point, we just want to see how it looks in the process tree. Again, we execute some commands, this time, we'll run ''​ls''​ and ''​grep'':​
  
 <​code>​ <​code>​
Line 58: Line 58:
 </​code>​ </​code>​
  
-Note once again, ''​ls''​ can't influence the ''​grep''​ environment''​grep''​ can't influence the ''​ls'' ​environmet, and neither ''​grep''​ nor ''​ls''​ can influence the ''​bash''​ environment.+Note once again, ''​ls''​ can't influence the ''​grep''​ environment''​grep''​ can't influence the ''​ls'' ​environment, and neither ''​grep''​ nor ''​ls''​ can influence the ''​bash''​ environment.
  
 __**How is that related to shell programming?​!?​**__ __**How is that related to shell programming?​!?​**__
Line 79: Line 79:
 </​code>​ </​code>​
  
-See the relationship?​ The forked Bash process will count the lines like a charm. It will also set the variable ''​counter''​ as directed. But if everything ends, this extra process will be terminated - **your "​counter"​ variable is gone** You see a 0 because in the main shell it was 0, and wasn't changed by the child process!+See the relationship?​ The forked Bash process will count the lines like a charm. It will also set the variable ''​counter''​ as directed. But if everything ends, this extra process will be terminated - **your "​counter"​ variable is gone.** You see a 0 because in the main shell it was 0, and wasn't changed by the child process!
  
 __**So, how do we count the lines?**__ __**So, how do we count the lines?**__
Line 91: Line 91:
 </​code>​ </​code>​
  
-It's nearly self-explanitory. The ''​while''​ loop runs in the **current shell**, the counter is incremented in the **current shell**, everything vital happens in the **current shell**, also the ''​read''​ command sets the variable ''​REPLY''​ (the default if nothing is given), though we don't use it here. +It's nearly self-explanatory. The ''​while''​ loop runs in the **current shell**, the counter is incremented in the **current shell**, everything vital happens in the **current shell**, also the ''​read''​ command sets the variable ''​REPLY''​ (the default if nothing is given), though we don't use it here.
 ===== Actions that create a subshell ===== ===== Actions that create a subshell =====
  
Line 103: Line 102:
 But if your command is a subprocess that sets variables you want to use in your main script, that won't work. But if your command is a subprocess that sets variables you want to use in your main script, that won't work.
  
-For exactly this purpose, there'​s the ''​source''​ command (also: the //dot// ''​.''​ command). Source doesn'​t execute the script, it importss ​the other script'​s code into the current shell:+For exactly this purpose, there'​s the ''​source''​ command (also: the //dot// ''​.''​ command). Source doesn'​t execute the script, it imports ​the other script'​s code into the current shell:
 <​code>​ <​code>​
 source ./​myvariables.sh source ./​myvariables.sh
  • scripting/processtree.1438830505.txt
  • Last modified: 2015/08/06 03:08
  • by bill_thomson