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 [2016/07/22 10:32]
tejr [Bash playing with pipes] Fix typo
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, 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 pipign ​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.1469183531.txt
  • Last modified: 2016/07/22 10:32
  • by tejr