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