when to know we are going to work in sub shell or would be entering sub shell

sysmicuser · 05-03-2013, 11:35 AM

Guys,

I am being enlightened by one of the senior member from this forum that this is no requirement to do "export" for any variable unless it is going to be required in sub shell.

So now my question(s) goes,

How do we know that we are going to require a sub shell or we are entering(the variable) in fact is entering a sub shell.

Also can anybody advice me , when do we use words like let, define, set ??

Thank you in advance.

Habitual · 05-03-2013, 11:48 AM

bash?

theNbomr · 05-03-2013, 01:59 PM

Actually, the assertion about subshells is somewhat inaccurate. All processes (not just shells) have an environment that contains a list of key/value pairs. All processes inherit the environment of their parent process when the parent fork()s. Bash and other Bourne shells have a similar key/value pairs list which can be manipulated, and behaves otherwise like an environment variable. When one or more of those variables is exported, it is moved to the environment that allows it to be inherited by any child process (not just subshell) that is spawned by the shell.
What I described above is kind of jargon for what happens when you set and export an environment variable before running a program. By default, X client applications need to have a $DISPLAY variable set:

Code:

export DISPLAY=localhost:0
xterm

The child process (xterm) inherits the $DISPLAY variable, because it was exported.

--- rod.

David the H. · 05-05-2013, 01:24 PM

A subshell is formed whenever you run a secondary command inside another command string with command substitution or process substitution. They are also created for the second and subsequent commands in a command list (i.e. a pipe chain), and when a command is forked into the background with "&". Subshells can also be created explicitly with the '(..)' grouping. There may be other cases that I can't remember off-hand.

In other words, it's a temporary environment forked off by the shell in which to do some work, generally while in the process of executing another command. See the bash man page.

A sub-process, OTOH, is just what it says it is, an entirely new process thread created by and forked off from the parent. The sub-process runs pretty much independently, but is still a sub-node of its parent and will be terminated if the parent process terminates. In shell terms this usually refers to any external commands you run, although subshells are also a kind of sub-process.

The big difference between a sub-process and a subshell is that the former only inherits values from the parent that have the export flag set, whereas a subshell is an almost exact duplicate of the parent, and all environment values are made available, whether exported or not.

jpollard · 05-05-2013, 08:42 PM

As a bit of addition...

You also get sub-shells (at least with most of them) when you use loop constructs such as while, for, do. The advantage is that it allows you to redirect input/output to/from the loops. For example:

Code:

while read VAR ; do
   echo $VAR
done <filename

This example is from a procedure that used to be used during particular boot sequences on SunOS - it was termed a "shcat" (shell cat) because it accomplishes the same function as cat, but doesn't require a cat utility binary to work.

You also get sub-shells for certain grouping operations - using parentheses as in:

Code:

(cd path; tar -cf - .) | (cd otherpath; tar -xf -)

The parentheses here are used to group the context of two commands (the cd, and the tar). In this particular example, the two groups are tied together by sending the stdout of the first to the stdin of the second.

This example is a bit contrived (tar now has a -C option to do the same thing), but it used to be very common when copying directory trees around (especially when going from one system to another).

ntubski · 05-05-2013, 09:05 PM

Quote:

Originally Posted by jpollard

You also get sub-shells (at least with most of them) when you use loop constructs such as while, for, do. The advantage is that it allows you to redirect input/output to/from the loops.

No, loop constructs don't create sub-shells (redirection doesn't require having a sub-shell).

jpollard · 05-05-2013, 09:51 PM

Ok. got that one wrong.

David the H. · 05-07-2013, 10:50 AM

Perhaps you were thinking of this common gotcha:

Code:

cat file.txt | while read -r line; do
   [[ $line == *foo* ]] && fooline=$line
done

echo "$fooline"

$fooline will never contain anything because the while loop runs inside a subshell (it's the second element in a pipe chain). And no sub-process can modify the environment of its parent.

This does work, however, since there are no subshells involved:

Code:

while read -r line; do
   [[ $line == *foo* ]] && fooline=$line
done <file.txt

echo "$fooline"

I set variables in a loop that's in a pipeline. Why do they disappear after the loop terminates? Or, why can't I pipe data to read?
http://mywiki.wooledge.org/BashFAQ/024

theNbomr · 05-07-2013, 11:08 AM

Quote:

Originally Posted by David the H.

And no sub-process can modify the environment of its parent.[/url]

Or, more generally, no process can modify the environment of any other process, irrespective of the ancestral relationship.
--- rod.