Re: Historical question on y command

Looking around further at minnie.tuhs.org, the AUSAM version of Unix, based
on version 6 Unix, includes a pre-release version of sed from 1975,
predating the Kubla Khan doc by years. Although recognisably still sed,
it's very different to the version we know today, much more similar to ed.
It's fascinating to see how it evolved.
Unsurprisingly the y command is missing. Perhaps more surprisingly:
-There is no hold space, and therefore no commands using the hold space
(today's g,h,G,H, and x commands).
-Although g & v commands exist, these are not today's g & v commands.
Rather they are a clone of ed's g & v commands, which were used for
applying multiple commands to lines matching or not matching a specific
regex. As such the g command is redundant in sed.
-There is no provision for ! to negate the addresses. Instead you have to
use the abovementioned v command.
-The b (branch) command is called the j (jump) command, which I personally
prefer. I guess Lee wanted to avoid confusion with ed's j (join) command in
the day's when compatibility with ed was more important.
-The l command is parsed but not implemented. It is just a Do Nothing
command at this stage.
-The p & P cpommands print nothing unless the -n flag is in effect, unlike
today's sed which prints the pattern space twice.
-There are mysterious O, W and e commands provided for in the header file
but not parsed or implemented. This remained true for the first official
1979 release.
-There is no semi-colon separator for commands. The commands must be one
per line, so no sed one-liners.
-As per ed, there is no choice of field separator for regex addresses; only
"/" can be used.

On Sat, Mar 15, 2014 at 10:47 PM, George Utley <[email protected]> wrote:

>  Historical Unix source code is available at
> http://minnie.tuhs.org/cgi-bin/utree.pl and elsewhere.
>
>   On Sun, Mar 2, 2014 at 2:54 PM, Pedro Izecksohn <[email protected]>wrote:
>
>>
>>
>> >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.
>>
>> 
>>
>
>