General, /bin/sh, IO, etc...

[Maarten Litmaath]

In article <1990Jun6.011303.22871 at virtech.uucp>,
	cpcahil at virtech.uucp (Conor P. Cahill) writes:
)In article <SCOTT.90Jun5133413 at croaker.cs.odu.edu> scott at cs.odu.edu (Scott Yelich) writes:
)>1)   Why does IFS affect the commands in a shell, not just the text?
)
)Because that is hat it is supposed to do.  The shell has no idea of 
)'text'.  It uses the IFS to parse all lines.

It is NOT supposed to!  It has always been a BUG in various shell
implementations.  POSIX 1003.2 has fixed it.

)>     Do the braces { } create a sub shell (yic!)?
)
)Not necessarily, but they will be if the input/output is redirected or if
)the group is put in the background.  This is similar to the way that
)while and/or for loops are processed.

Again: current implementations create a subshell if the IO of a
command group is redirected, but POSIX forbids this behavior.
Example:

	shell='a subshell'
	{
		:
		shell='the top level shell'
	} < /dev/null
	echo "the command group was executed in $shell"

On a POSIX system the second assignment won't get `lost'.

)...
)>     I get the same number... but the process table shows ``cat'' by a
)>different process number and it diagrams it as if it were a sub/child
)>process!  
)
)The problem with your example is that the $$ is interpreted when the 
)controlling shell reads the lines (i.e. before the lines are executed). 

Wrong.  If you would be right, the following example would print `foo':

	var=foo
	(
		var=bar
		echo $var
	)

The problem with `$$' is: it only gets set once, when the top level
shell has just started.  Therefore I've proposed the following to the
P1003.2 committee:

	Add another special parameter which equals the process ID of the
	shell executing the commands, e.g.:

		$%

	Now we can say e.g.:

		(
			echo "my process ID is $%"
			echo "the top-level shell has process ID $$"
		)
	
	In the `top-level' shell executing the shell script $% equals $$.

)>   %tail -f file | tr "Aa"
)>   Works...
)>   %tail -f file | tr "Aa" |\
)>    while read LINE
)>    do
)>      echo $LINE
)>    done 
)>    Doesn't work.
)
)What do you mean by "doesn't work"?  I have used whiles at the end of
)pipelines without any problems.

But I bet you didn't use the `-f' flag of `tail'...
What happens is this:

	- the file `file' is short;

	- in the first example the output of `tr' is connected to a
	  terminal, hence line-buffered, hence you get output immediately,
	  after which the command hangs because of the `-f' flag;

	- in the second example the output of `tr' is connected to a
	  pipe, hence block-buffered, so you won't get output until the
	  pipe fills up, which doesn't happen if the file is short...
--
 "COBOL is the revenge of some witch burned |Maarten Litmaath @ VU Amsterdam:
   in Salem, [...]"  (Bill Davidsen)  |maart at cs.vu.nl, uunet!cs.vu.nl!maart