[comp.unix.questions] General, /bin/sh, IO, etc...

scott@cs.odu.edu (Scott Yelich) (06/06/90)

I have a couple of questions that I am working on... and I wouldn't
mind some additional EMAIL input just to help me sort out the answers.

[ I am using either a sun 3/60 or a sparcstation and sunos 4.0.3... ]

1)   Why does IFS affect the commands in a shell, not just the text?
     %sh
     {
      IFS="$IFS-"
      tail -f /usr/spool/mail/$USER
     }
     
     tail: f: No such file or directory

     If I do:
     %sh
     {
      IFS="$IFS-"
      set "H-H"
      echo $#
      VAR=$@
     }
     set $VAR
     echo $#
 
     I get ``1'' then ``2'' so the ``-'' is in there... at one point.

     Do the braces { } create a sub shell (yic!)?
     What about functions?
    
     %sh
     PR=$$
     SUB ()
     {
      SUBPR=$$
      {
       SUBSUBPR=$$
      }
     }          
     SUB
     echo $PR $SUBPR $SUBSUBPR

     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 environments are different with some commands!  Like ``for''...

2) What is the bufferring done here?
   %tail -f file | tr "Aa"
   Works...
   %tail -f file | tr "Aa" |\
    while read LINE
    do
      echo $LINE
    done 
    Doesn't work.
   
Is there anyway to get ``tr'' to pass stuff through in this type of a situation?
% tail -f file | tr -d "chars"| loop

What I want to do is trap the ``tr'' in a pipe sequence so I don't
keep calling it.  I could also just use
IFS="all_chars_that_I_want_to_delete" ... but I would much rather get
the `tr' working since one of the characters I want to delete is a
``-''.

Hmmm.... that's enough for now.

 -----------------------------------------------------------------------------
 Scott D. Yelich                         scott@[xanth.]cs.odu.edu [128.82.8.1]
 After he pushed me off the cliff, he asked me, as I fell, ``Why'd you jump?''
 Administrator of:    Game design requests to <game-design-request@cs.odu.edu>
 -----------------------------------------------------------------------------

cpcahil@virtech.uucp (Conor P. Cahill) (06/06/90)

In article <SCOTT.90Jun5133413@croaker.cs.odu.edu> scott@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.

>     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.

>     What about functions?

Functions are run in the current shell unless run in the background.

>     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). 

>   %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
ithout any problems.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

maart@cs.vu.nl (Maarten Litmaath) (06/07/90)

In article <1990Jun6.011303.22871@virtech.uucp>,
	cpcahil@virtech.uucp (Conor P. Cahill) writes:
)In article <SCOTT.90Jun5133413@croaker.cs.odu.edu> scott@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@cs.vu.nl, uunet!cs.vu.nl!maart