(Changing subject to reflect the current discussion)
On Sun, May 22, 2011 at 7:04 PM, Joerg Schilling <Joerg.Schilling@foku...> wrote: > I have no idea what you like to test here, this is why I asked you..... > > I am not sure what you are replying to as you reply to a mail with the subject: > "Test binary/auto.sh fa11" but this is a thread with a different subject. I > thus reply to the _content_ which is related to "Test binary/auto.sh fa11" but > not to the subject from this mail. > > I have not idea what you understand by "BOL" and a character with the value \001 > does not appear in this test. > > You write four characters into a file : 'x' a "\000' (nul) a 'y' and a new line > ('\n'). > > You then call: > > admin -iinfile s.infile > > As the file contains a null character, SCCS-5.0 and above will automatically > switch to binary mode. Your recent answers claim that CSSC should do the same. > > Your next test calls: > > prt -f s.infile > > and as this reports an encoded file, the test fails. > > From everything you wrote, this test is expected to fail with both SCCS and > CSSC.
At the time the test was written, I had not seen any version of SCCS which supported binary files and actually turned on encoding for this case. IIRC, the behaviour I saw was mixed; probably some versions just failed and some generated an unencoded history file (that is, none automatically went to binary mode). So I picked one behaviour and followed it.
> Question: why do you write a test that aborts the test suite because it > would require SCCS to encode a _binary_ file as text file in order to pass?
I'm pretty sure I was simply following the version of SunOS I was then mostly testing against. Most of the early functional testing of CSSC was done either by comparison with SunOS 4.1.x by myself, or against other versions of Unix by volunteers.