GNU bug report logs - #21571
[patches] some small message improvements

Previous Next

To reply to this bug, email your comments to 21571 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Benno Schulenberg <bensberg <at> justemail.net>
To: Coreutils <bug-coreutils <at> gnu.org>
Subject: [patches] some small message improvements
Date: Sun, 27 Sep 2015 09:58:09 +0200

[Message part 1 (text/plain, inline)]

Hi,

Attached three patches (sorry, I can't do 'git send-email' from here)
make some small changes to error messages and option descriptions.

The first patch puts the words "carriage return" and "newline" a bit
wider apart, instead of gluing them together with a hyphen -- this
had confused me up to now.  And it makes the wording for the onlret
option the same as for the ocrnl and onlcr options.  If the latter
change is not correct, please suggest another wording that makes
clear how this option differs from ocrnl and onlcr.

Benno

-- 
http://www.fastmail.com - Email service worth paying for. Try it for free

[0001-stty-improve-the-wording-of-the-CR-LF-translation-op.patch (text/x-diff, attachment)]

[0002-stty-remove-an-inconsistent-newline-from-an-error-me.patch (text/x-diff, attachment)]

[0003-sync-slightly-improve-the-usage-text.patch (text/x-diff, attachment)]

Message #8 received at 21571 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Benno Schulenberg <bensberg <at> justemail.net>, 21571 <at> debbugs.gnu.org
Subject: Re: bug#21571: [patches] some small message improvements
Date: Sun, 27 Sep 2015 11:10:32 +0100

On 27/09/15 08:58, Benno Schulenberg wrote:
> @item onlcr
> @opindex onlcr
> @cindex newline, translating to crlf
> -Translate newline to carriage return-newline.  Non-POSIX@.  May be
> +Translate newline to carriage return + newline.  Non-POSIX@.  May be
>  negated.

Better thanks.

>  @item onocr
> @@ -13918,7 +13918,7 @@ May be negated.
>  
>  @item onlret
>  @opindex onlret
> -Newline performs a carriage return.  Non-POSIX@.  May be negated.
> +Translate newline to carriage return.  Non-POSIX@.  May be negated.

While this new wording doesn't overlaps with other descriptions,
the original wording comes from POSIX.  I don't know that the distinction
here is TBH. Perhaps onlret relates to input while onlcr relates to output?

thanks,
Pádraig.

Message #11 received at 21571 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 21571 <at> debbugs.gnu.org, Benno Schulenberg <bensberg <at> justemail.net>
Subject: Re: bug#21571: [patches] some small message improvements
Date: Sun, 27 Sep 2015 13:26:15 +0200

Pádraig Brady <P <at> draigBrady.com> writes:

> While this new wording doesn't overlaps with other descriptions,
> the original wording comes from POSIX.  I don't know that the distinction
> here is TBH. Perhaps onlret relates to input while onlcr relates to output?

<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_02_03>

 If ONLCR is set, the NL character shall be transmitted as the CR-NL
 character pair. If OCRNL is set, the CR character shall be transmitted
 as the NL character. If ONOCR is set, no CR character shall be
 transmitted when at column 0 (first position). If ONLRET is set, the NL
 character is assumed to do the carriage-return function; the column
 pointer shall be set to 0 and the delays specified for CR shall be
 used. Otherwise, the NL character is assumed to do just the line-feed
 function; the column pointer remains unchanged. The column pointer
 shall also be set to 0 if the CR character is actually transmitted.

So ONLRET is mostly about properly keeping track of the column.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #14 received at 21571 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 21571 <at> debbugs.gnu.org, Benno Schulenberg <bensberg <at> justemail.net>
Subject: Re: bug#21571: [patches] some small message improvements
Date: Sun, 27 Sep 2015 13:30:55 +0200

Pádraig Brady <P <at> draigBrady.com> writes:

> On 27/09/15 08:58, Benno Schulenberg wrote:
>> @item onlcr
>> @opindex onlcr
>> @cindex newline, translating to crlf
>> -Translate newline to carriage return-newline.  Non-POSIX@.  May be
>> +Translate newline to carriage return + newline.  Non-POSIX@.  May be
>>  negated.
>
> Better thanks.
>
>>  @item onocr
>> @@ -13918,7 +13918,7 @@ May be negated.
>>  
>>  @item onlret
>>  @opindex onlret
>> -Newline performs a carriage return.  Non-POSIX@.  May be negated.
>> +Translate newline to carriage return.  Non-POSIX@.  May be negated.

BTW, non-POSIX is misleading.  Most of those extensions are now part of
POSIX, but XSI shaded.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #17 received at 21571 <at> debbugs.gnu.org (full text, mbox):

From: Benno Schulenberg <bensberg <at> justemail.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 21571 <at> debbugs.gnu.org,
 Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#21571: [patches] some small message improvements
Date: Sun, 27 Sep 2015 18:24:43 +0200

On Sun, Sep 27, 2015, at 13:26, Andreas Schwab wrote:
> <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_02_03>
> 
>  [...]  If ONLRET is set, the NL character is assumed to do the
> carriage-return function; [...] Otherwise, the NL character is
> assumed to do just the line-feed function; [...]

This wording seems to faintly suggest that ONLRET is meant to
cause NL to do /also/ CR besides doing NL.  Is that whjat is
meant?

Or does it just mean that when ONLRET is set that the receiving
end will do also a CR when a LF is received?  The tty doesn't do
any conversion, it just has to be aware that sending a LF causes
also a CR in order to be able to line things up properly?

Benno

-- 
http://www.fastmail.com - Faster than the air-speed velocity of an
                          unladen european swallow

Message #20 received at 21571 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Benno Schulenberg <bensberg <at> justemail.net>
Cc: 21571 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#21571: [patches] some small message improvements
Date: Sun, 27 Sep 2015 20:14:10 +0200

Benno Schulenberg <bensberg <at> justemail.net> writes:

> Or does it just mean that when ONLRET is set that the receiving
> end will do also a CR when a LF is received?  The tty doesn't do
> any conversion, it just has to be aware that sending a LF causes
> also a CR in order to be able to line things up properly?

Yes.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #23 received at 21571 <at> debbugs.gnu.org (full text, mbox):

From: Benno Schulenberg <bensberg <at> justemail.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 21571 <at> debbugs.gnu.org,
 Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#21571: [patches] some small message improvements
Date: Mon, 28 Sep 2015 13:07:16 +0200

On Sun, Sep 27, 2015, at 20:14, Andreas Schwab wrote:
> Benno Schulenberg <bensberg <at> justemail.net> writes:
> > Or does it just mean that when ONLRET is set that the receiving
> > end will do also a CR when a LF is received?  The tty doesn't do
> > any conversion, it just has to be aware that sending a LF causes
> > also a CR in order to be able to line things up properly?
> 
> Yes.

Hm.  But the termios layer cannot know whether the sender is
aware that NL also causes a carriage return, so it cannot take
any compensatory action on the data coming through.  So, ONLRET
by itself does not do anything at all.  Only when combined with
ONOCR does it have an effect: not only after a CR but also after
an NL any subsequent CRs are discarded, until some printable
character moves the cursor out of column zero again.  Right?

Maybe then the documentation should mention that ONLRET
is only useful in combination with ONOCR?  Because otherwise
the introduction of the "Output settings" section is somewhat
misleading: "These settings control operations on data sent to
the terminal."  As ONLRET does not cause anything to be done
with the data unless ONOCR is set.


Glibc only documents ONLCR, not OCRNL nor ONLRET nor ONOCR.
Is that just a lack of documentation?  Or does it mean that
the latter three flags are in effect nonfunctional?

Benno

-- 
http://www.fastmail.com - Access your email from home and the web

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.