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.

  Could you send that source code to me? I use the Gnu sed.

  I remember they talking about this, but I don't remember the content of that talk.

  What I remember is that at that time the size in bits of the char type was different on different platforms and I know that the standard does not define if the char type is signed or unsigned.

>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.
  1) We, Lee McMahon and I, expected that in the future multicharacter commands would be added to the list of sed's commands.
  2) To understand the logic behind the 'a\\n' command a small example is needed:

pedro@microboard:~/programming/sed/George Utley's question$ cat test.txt
Hello
world.
pedro@microboard:~/programming/sed/George Utley's question$ cat test.txt | sed '1a insertion'
Hello
insertion
world.

  3) It seemed logic when the specification was written, that was before the source code had been written, that a content that must occupy at least a whole line should be separated from the commands by a line-feed.
  4) It was the typist who decided the separator that is needed after the r and w commands. And he was against the use of the backslash after the i, c, and a commands.
  5) Lee E. McMahon was punished with a punch on each of his eyes for not have included our names on sed's specification.

  Consistency may be expected from a single person but not from different people.

  The inconsistencies of sed prove that it was written by a group of people who did not communicate well.

  The lack of communication between us may be explained by some facts: The typist lived and worked on Niterói. I also lived on Niterói but I used to go to the post office every day in the morning and used to stay there for just about an hour. Lee McMahon lived on Rio de Janeiro and was officially allocated to work on Rio de Janeiro but used to go to Niterói every workday to talk to us personally. The sed's specification was typed hurriedly by McMahon and it was not revised by me nor by the typist until it had been published.