jsmithso@aut.UUCP (Jim Smithson) (05/04/90)
Here's a small problem I can't really explain. I am running /bin/sh on my NCR Tower 32/650 under Sys V rel 2.01. Consider a shell script called foo.sh which contains the following two lines: vi foofile not_a_command # here to give some error output I want to run this shell script and capture the output (stdout and stderr) to a logfile, I also want to see the output as it happens. So I enter the command: foo.sh 2>&1 |tee foo.log But this totally hoses up `vi`. `vi` runs fine if I enter: foo.sh |tee foo.log But stderr is not written to the logfile. Same with: foo.sh | tee foo.log 2>&1 `vi` also runs fine if I enter: foo.sh 2>&1 Can anybody explain what the problem is? Can anybody suggest something that will work? Thanks in advance! -- James R. Smithson Ascom Autelca AG CH-3073 Guemligen/Switzerland E-mail: jsmithso@aut.UUCP FAX: +41 31 527 745 Voice : +41 31 529 214 UUCP: ...!uunet!mcsun!chx400!hslrswi!aut!jsmithso
mercer@ncrstp.StPaul.NCR.COM (Dan Mercer) (05/07/90)
In article <1284@telsys.aut.UUCP> jsmithso@aut.UUCP (Jim Smithson) writes:
:
:Here's a small problem I can't really explain.
:I am running /bin/sh on my NCR Tower 32/650 under Sys V rel 2.01.
:
:Consider a shell script called foo.sh which contains the following two lines:
:
:vi foofile
:not_a_command # here to give some error output
:
:I want to run this shell script and capture the output (stdout and stderr)
:to a logfile, I also want to see the output as it happens.
:
:So I enter the command: foo.sh 2>&1 |tee foo.log
:But this totally hoses up `vi`. `vi` runs fine if I enter: foo.sh |tee foo.log
:But stderr is not written to the logfile. Same with: foo.sh | tee foo.log 2>&1
:`vi` also runs fine if I enter: foo.sh 2>&1
:
:Can anybody explain what the problem is?
:Can anybody suggest something that will work?
:
:Thanks in advance!
:--
:James R. Smithson Ascom Autelca AG CH-3073 Guemligen/Switzerland
:E-mail: jsmithso@aut.UUCP FAX: +41 31 527 745 Voice : +41 31 529 214
:UUCP: ...!uunet!mcsun!chx400!hslrswi!aut!jsmithso
Vi uses stderr on the ioctl call that sets it up for raw data
handling. If stderr is redirected, the terminal will not be in the
correct state, and all the full screen algorithms will be off. I
know of no way around this.
However, ex works quite well with stdout and stderr redirected,
since it does not use raw mode (you exit insert mode by typing
a standalone period and an enter). When I wanted capture my
macro mappings for a seminar I was giving on vi, that's what I
did.
--
Dan Mercer
Reply-To: mercer@ncrstp.StPaul.NCR.COM (Dan Mercer)meadb@boulder.Colorado.EDU (MEAD BENNETT ROSS) (05/09/90)
In article <438@ncrstp.StPaul.NCR.COM> mercer@ncrstp.StPaul.NCR.COM (Dan Mercer) writes: >In article <1284@telsys.aut.UUCP> jsmithso@aut.UUCP (Jim Smithson) writes: >:... >:So I enter the command: foo.sh 2>&1 |tee foo.log >:But this totally hoses up `vi`. `vi` runs fine if I enter: foo.sh |tee foo.log >:But stderr is not written to the logfile. Same with: foo.sh | tee foo.log 2>&1 >:`vi` also runs fine if I enter: foo.sh 2>&1 >: ... > >Vi uses stderr on the ioctl call that sets it up for raw data >handling. If stderr is redirected, the terminal will not be in the >correct state, and all the full screen algorithms will be off. I >know of no way around this. > ... Alright, I don't know what characters are echoed to the screen by ioctl, but it shouldn't be hard to find out. Write a C program that echos these characters to stdout. Not too bad, but it will require a little research, and a little C knowledge. Then put this C program in your shell script. Not trivial, but there are ways to get around this problem, but it will take longer than just using ed. (as suggested by Dan.) But it looks like it's possible to do this. -Bennett. ----- | | meadb%tramp@boulder.colorado.edu | | Just annother wizard in training. | | | | meadb!tramp!boulder!ncar.... | | | | | | | | | | | | | | | | | |meadb!tramp!boulder!sunybcs!rutgers...| | | | | | | | | |
jik@athena.mit.edu (Jonathan I. Kamens) (05/09/90)
In article <20829@boulder.Colorado.EDU>, meadb@boulder.Colorado.EDU (MEAD BENNETT ROSS) writes: |> Alright, I don't know what characters are echoed to the screen by ioctl, |> but it shouldn't be hard to find out. Write a C program that echos |> these characters to stdout. Not too bad, but it will require a little research, |> and a little C knowledge. Then put this C program in your shell script. Not |> trivial, but there are ways to get around this problem, but it will take |> longer than just using ed. (as suggested by Dan.) But it looks like it's |> possible to do this. It is erroneous to assume that an ioctl works by echoing characters to the screen. In fact, I very much doubt that the ioctl to put the terminal into raw mode echoes anything to the screen. Therefore, what you would have to do is to write a C program to do the ioctl(s) vi does when it starts up, not a C program to echo characters to stdout. However, it is likely that vi doesn't only do ioctl() calls when it starts up -- it also probably does them while it's working. The ioctl()'s it does while it's working will probably fail, and it will lose. Hence I think the suggestion to use ex, rather than vi, was probably a better one. Note that Dan did not suggest the use of ed. He suggested the use of ex, which is very different from ed. Ed is a line-based editor, while ex is display-based (like vi). In fact, ex and vi run the same code, which is why the output of vi and ex are similar. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
leo@ehviea.ine.philips.nl (Leo de Wit) (05/10/90)
In article <438@ncrstp.StPaul.NCR.COM> mercer@ncrstp.StPaul.NCR.COM (Dan Mercer) writes: |[] | |Vi uses stderr on the ioctl call that sets it up for raw data |handling. If stderr is redirected, the terminal will not be in the |correct state, and all the full screen algorithms will be off. I |know of no way around this. I seriously doubt that this is always the case. A simple test, doing $ vi 2>/dev/null /etc/termcap on a Pyramid (ucb universe) showed no apparent problems. Can you elaborate on what should go wrong? Leo.