Re: Historical question on y command

Thanks a lot for that, Pedro, that was awesome. I never imagined I would
ever get a reply from someone who was actually there at sed's creation, let
alone that the original developers were still alive.

So if I understand you correctly, the y command was initially intended for
transliteration WITHIN a character set between high-ASCII ISO8859 foreign
characters such as Hebrew, and the equivalent low-ASCII Latin characters,
within parts of an otherwise English document? That would certainly explain
the lack of support for character ranges or control characters, as the
equivalent characters would not line up so neatly, and the line-oriented
rather than regex-oriented nature of the command. And this application
certainly wouldn't be catered for by the existing whole-file utility tr.
Now it all makes sense. But this intended use was thwarted by a lazy
programmer who couldn't be bothered fixing his code for high-ASCII support?
Note that by "high ASCII" I don't mean multibyte, I mean 8 bit characters
>127. I have seen the source code for the version 7 Unix sed command, and
the y command's lookup table strips the high bit of each source character
and stops at offset 0177, apparently permitting translation from low ASCII
to high ASCII but not from high ASCII to low ASCII, which seems the
opposite of Lee's intentions.

And don't apologise for the D command, as I use sed primarily in multiline
mode and need it. But now that you bring it up, what problem was the
obligatory backslashed newline after the i/c/a commands intended to solve?
If it was to allow whitespace in front of the first displayed character,
couldn't that have been achieved just as easily by starting the displayed
text at the second character after the command, regardless of whether or
not the second character was whitespace? This at least would have been
consistent with the similarly finicky r & w commands, which used to
require exactly one space after the command and interpreted the subsequent
characters as the parameter.

On Mon, Feb 24, 2014 at 11:28 AM, Pedro Izecksohn <[email protected]>wrote:

>    Before I answer your question you need to know that sed was not
> developed by Lee McMahon alone: He was helped by 2 other guys whose names
> are not in the sed's first public documentation: I was one of those guys.
> (I invented the 'D' command and the back-slash followed by the line-feed
> that follows the commands 'a', 'i' and 'c'. And I regret having suggested
> all these features.)
>
> On those days of teletypes, people that used to use other alphabets
> together with ASCII used to use character encodings specified by the ISO
> 8859.
>
> I was inside that post-office room where sed was developed when McMahon
> came with a problem: Someone was writing a book about Jewish culture and to
> write that text he needed to include Latin characters, Hebrew characters
> and characters transliterated from Hebrew to Latin on the same line.
>
>
> >People have come up with fiendishly clever ways to use it for
> mathematics, but it's pretty clear to me that Lee hadn't intended it for
> that, given you have to really fight and bastardise the language to use it
> for that purpose. Similarly rot13 sometimes features in examples, but I
> question how important rot13 is in real-world uses of sed.
>
>   These uses were also discussed there.
>
> >The y command has also been used to insert newlines using "\n" back in
> the days when the s command didn't allow "\n" in the replacement string.
> But this is silly as an intended purpose, since the developers could
> easilly have allowed "\n" in the s command's replacement string in the
> first place. Does anyone know why "\n" wasn't initially allowed in the
> replacement string of the s command?
>   What I remember is this: I asked: "-Which would be the escape
> character?" The answer was: "-The back-slash as common." Then I rejoined:
> "-Why not use the character generated by the Esc key?"
>
>   So probably the answer to this question is this: The escape character
> had not been decided yet.
>
>   sed was not intended to be used to modify binary data nor to be used
> with multi-bytes character sets. I'm almost sure that the C functions and
> data types that deal with multi-bytes character sets had not been
> standardized yet. And the digitizer was lazy and said to McMahon: "-Do you
> want to modify what I already typed? Do it yourself. For my purpose (this
> meant: "For the purpose of the post-office") it is already good enough. If
> someone want to use sed for some text that use some multi-byte character
> set then he should use some other tool to convert the text." McMahon then
> asked him: "-What if someone want to write a text that use 3 different
> alphabets?" Then the digitizer rejoined: "-I work here sending e-mails
> every day for almost X years and never anyone brought a text like this for
> me to type it."
>
>
> >Unlike the s command, the right hand side of the final "/" character in
> the y command is unused for parameters. This could have been used for
> context control, e.g. make the translation only happen within parenthesised
> portions of the regexp on the right hand side of the final "/". Such a
> feature would have made the y command vastly more useful and would have fit
> in neatly with the regexp-based philosophy of sed. Yet to this day no such
> feature exists.
>
>   If you don't bother of writing free software then you may modify Gnu
> sed, sign the paper and post the diff for the FSF.
>   I hope that I have answered all your questions. You made me happy for
> have given me the opportunity to write this message: Thank you.
>
> 
>