misc/163871: 'script' save endline as ^M

Bruce Evans brde at optusnet.com.au
Sat Jan 7 06:10:10 UTC 2012


The following reply was made to PR bin/163871; it has been noted by GNATS.

From: Bruce Evans <brde at optusnet.com.au>
To: Eugen Konkov <kes-kes at yandex.ru>
Cc: freebsd-gnats-submit at FreeBSD.org, freebsd-bugs at FreeBSD.org
Subject: Re: misc/163871: 'script' save endline as ^M
Date: Sat, 7 Jan 2012 17:00:20 +1100 (EST)

 On Fri, 6 Jan 2012, Eugen Konkov wrote:
 
 >> Description:
 > there must not be ^M endline style
 
 >> How-To-Repeat:
 >
 > #script
 >
 > Script done, output file is typescript
 >
 > when look into 'typesript' file  in 'mc' you can see ^M as endline
 >
 > Edit src/sys/dev/et/if_etreg.h^M
 >  Add delta 1.4.2.2 2012.01.06.18.15.27 yongari^M
 > ...
 
 This is a mostly a feature.  script(1) just echos whatever data goes
 through the pty.  Normally the pty is in "opost onlcr" mode, so \n is
 translated to \r\n.  script(1) can't possibly undo this, because it
 is impossible in general for it to distinguish between \r's that are
 the result of the translation and \r's that are needed (e.g., the one
 in:
 
  	#! /bin/sh
  	printf 'The following \\r is not needed'
  	printf '\r'
  	printf 'The preceding \\r __is__ needed!\n'
 
 ).
 
 If you don't want this, then turn off onlcr or opost.  You won't like
 the result of this in interactive shells unless the terminal translates
 nl to crnl and you don't turn this off too.
 
 However, watch(8) doesn't have this problem, since it sees and reports
 the data written to the terminal before opost processing.
 
 watch(8) probably works better for input too.  Someone recently tried to
 fix EOF handling in script(1) and had problems using VEOF since this gives
 input processing unless the default echo mode is turned off.  Perhaps
 watch(8) can handle this better too.  But watch doesn't understand EOF at
 all, and is hard to terminate (the old version that I'm testing with
 is terminated by ^G which generates a SIGINT, but it dumps core instead
 of catching this signal as intended, and all versions have an unsafe
 SIGINT handler which asks for core dumps).
 
 Bruce


More information about the freebsd-bugs mailing list