terminal. Unfortunately the fix was incorrect and for flushtime > 0 it
keept sending VEOF.
Sent VEOF generates ^D\b\b echoed by the terminal, which was reported
in bin/161526. Note, we still send VEOF at least once. Otherwise
commands like below would hang forever:
echo 1 |script /tmp/script.out cat
PR: bin/161526
Reported by: Adrian Wontroba <aw1@stade.co.uk>, Stefan Bethke <stb@lassitu.de>
Tested by: Stefan Bethke <stb@lassitu.de>
MFC after: 3 days
reads eating 100% CPU. Fix this by skipping select on STDIN after
reading EOF -- permanently if STDIN is not terminal and for one second
if it is.
Also after reading EOF from STDIN we have to pass it to the program
being scripted. The previous approach was to write zero bytes into the
pseudo-terminal. This does not work because zero-byte write does not
have any effect on read. Fix this by sending VEOF instead.
Submitted by: Ronald Klop <ronald-freebsd8@klop.yi.org>
Discussed with: kib, Chris Torek <chris.torek@gmail.com>
Approved by: kib
MFC after: 1 week
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
Also add $FreeBSD$ to a few files to keep svn happy.
Discussed with: imp, rwatson
the name of the typescript file.
+ Add the 'command' argument (if supplied on the command line) to the
typescript file. This creates a more complete typescript when invoked
this way - more equal to invoking script without supplying the 'command'
argument.
All these functions and variables are local to this compilation unit, so
there is no reason why we shouldn't mark them static. This slightly
reduces the binary size.
Because script(1) now reliably terminates when the TTY is closed, it may
be the case that the call to wait3() occurs just before the child
process exits. This causes error codes to be ignored.
Just change script(1) to use waitpid() instead of wait3(). This makes it
more portable and prevents the need for a loop, since waitpid() only
returns a specified process.
PR: bin/146189
Tested by: amdmi3@, older version
MFC after: 2 weeks
Close the file descriptor to the TTY. There is no reason why the parent
process should keep track of the descriptor. This ensures that the
application inside properly drains the TTY during exit(2).
Reported by: alfred
MFC after: 2 weeks
read EOF from STDIN_FILENO, write zero bytes into the pseudo-terminal;
this is interpreted as an EOF by the program being scripted.
I've tested this with two non-interactive scripts:
# echo 5 | script foo sh -c 'read x; sleep $x; echo bar'
# echo bar | xargs script foo echo
and one interactive program:
# script foo more /etc/passwd
and everything seems to work properly...
PR: bin/56166, bin/57414, ports/57415, ports/60534
Approved by: rwatson (mentor)
MFC after: 2 weeks
re-breaks non-interactive portupgrade (or at least old versions of
portupgrade); I'll see if I can put together a solution which avoids
breaking anything later.
Approved by: rwatson (mentor)
Noticed by: Stefan Farfeleder, Joshua Goodall
1. Don't do tty stuff to stdin if stdin isn't a tty.
2. When running in non-interactive mode, don't select(2)
on the standard input.
This un-breaks non-interactive portupgrade.
PR: bin/59036 [1]
PR: bin/56166, bin/57414, ports/57415, ports/60534 [2]
MFC after: 7 days
Approved by: rwatson (mentor)
Add some constness to avoid some warnings.
Remove use register keyword.
Deal with missing/unneeded extern/prototypes.
Some minor type changes/casts to avoid warnings.
Reviewed by: md5
of the recent WARNS commits. The idea is:
1) FreeBSD id tags should follow vendor tags.
2) Vendor tags should not be compiled (though copyrights probably should).
3) There should be no blank line between including cdefs and __FBSDIF.
- if a command was specified and script(1) failed to execute it,
it would print the name of your shell in the error message
instead of that of the command that failed.
- since finish() was installed as a SIGCHLD handler, it would
often run before the main loop had had time to process the
last few bytes of output. This resulted in very strange
truncated error messages.
- script(1) would almost always return with an exit status of 0,
even if the command returned a non-zero exit status. This broke
my 'build world, install it and rebuild the kernel' scripts
because 'make installworld' would run even if 'make buildworld'
had failed.
