URL:
<https://savannah.gnu.org/bugs/?60803>
Summary: tr request does not warn when it can't translate an
input space
Project: GNU troff
Submitted by: gbranden
Submitted on: Sun 20 Jun 2021 06:04:03 AM UTC
Category: Core
Severity: 3 - Normal
Item Group: Warning/Suspicious behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Details:
T. Kurt Bond and Oliver Corff noted an oddity with .tr on the groff mailing
list.
You can translate characters _to_ space with .tr, but not _from_ a space.
While this may make sense for a syntactical and/or typographical perspective,
.tr is completely silent about this and it probably should not be.
"I fumbled with .tr after reading your mail and it seems how space is used as
a delimiter in general input processing prohibits it from being recognized as
a character which is recognized and accepted as an element of the input
character set by .tr.
In contrary, normal characters can be converted to spaces by .tr--just
consider the following example:
.tr n iI
This is a string.
I added the substitution pair iI in order a) to signal to .tr that the space
is a valid input and b) in order to have quick check whether .tr works as
expected with spaces in the chain of substitution pairs. It does."
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?60803>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
