Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Jan 2012 17:00:20 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Eugen Konkov <kes-kes@yandex.ru>
Cc:        freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject:   Re: misc/163871: 'script' save endline as ^M
Message-ID:  <20120107150716.C1012@besplex.bde.org>
In-Reply-To: <201201061955.q06JtftN038154@red.freebsd.org>
References:  <201201061955.q06JtftN038154@red.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120107150716.C1012>