[CC += cssc-users]
On Sat, May 21, 2011 at 11:11 AM, Joerg Schilling
<
Joerg.Schilling@...> wrote:
> James Youngman <
jay@...> wrote:
>
>> > why do you expect that it makes sense that a file with
>> > no new line at the end should be "delta"d wihout error?
>>
>> It's a property required of CSSC but not other implementations.
>> Required of CSSC because SCCS doesn't allow a history file to be
>> switched to being uuencoded after its creation, and if the newline at
>> EOF is deleted, we have to do something.
>>
>>
>> > Why do you expect that it is possible to retrieve back such
>> > a file and successfully compare it with the original file that
>> > misses the newline at the end?
>>
>> I'm not sure why you're asking why: it's a property required of CSSC.
>> I don't hold other implementations to that. Hence the enormous
>> conditional enclosing these tests.
>
> The test checks for something that is different from what you just explained.
Sorry if I was unclear.
> It tests whether it is possible to create an encoded SCCS history file by
> calling:
>
> admin -b -n s.foo
>
> As this does not match the documented behavior for SCCS, it is not expected to
> succeed.
That is common behaviour. But it's not documented behaviour. At
least, it's not documented in a place where many users will see it.
Pulling a fragment from a SUNOS 5.10 manpage from the web:
"""
-b
Forces encoding of binary data. Files that contain ASCII NUL or other
control characters, or that do not end with a NEWLINE, are recognized
as binary data files. The contents of such files are stored in the
history file in encoded form. See uuencode(1C) for details about the
encoding. This option is normally used in conjunction with -i to force
admin to encode initial versions not recognized as containing binary
data.
"""
Note "is normally used" not "can only be used".
> docommand E28 "${admin} -b -n -i/dev/null $s" 0 IGNORE IGNORE
>
> Will match the SCCS documentation....
>
>
> The background for my mail is that there are more than 1100 tests in your suite
> and only three of them fail with SCCS:
>
> delta/errorcase.sh E28 (se above)
> This test as implemented by you
> does not match the documented
> behavior and I believe that the
> man page is correct here and
> you should chnage your test.
I've never seen documentation stating that "-b -n" is not allowed but
"-b -n -i/dev/null" is allowed. I agree it is the historic
behaviour, but frankly I've always considered that to be an oversight
in the Sun implementation.
I don't really see a case here for disallowing -b without -i, when the
user's intent is clear and for decades the SCCS documentation didn't
point out that -b is not allowed without -i.
> admin/r-option.sh.
> docommand t5 "${admin} -n -r2 $s" 1 "" IGNORE
> Here you are aligned with the
> documentation, but I am
> interested to change the
> documentation as SCCS started
> to asume -n in case -i was
> specified and SCCS now permits
> -r with both -n and -i (which
> looks useful).
The only use I can think of offhand is the initialisation of multiple
SCCS files with empty bodies at a revision greater than 1. I concede
that there may be a use case for it. I'm a little concerned that
this could result in people writing shell scripts which don't work on
older versions of SCCS but that's always a risk with any functional
change.
> binary/auto.sh
> test_ascii fa11 "x\000y\n" Is expected to succeed and not
> to fail as you asume, as it
> matches the way Sun implemented
> it.
I hope my previous email on this subject helped clear up this
misunderstanding. The CSSC regression test suite does not *expect*
this test to fail for SCCS. In fact this test is *not carried out at
all* on SCCS. If this test is run, somehow on an implementation of
SCCS, it may fail, or it may not fail, depending on the SCCS
implementation.
> I know that there are a bunch of very old SCCS versions around that will not
> pass all tests (e.g. because before Solaris, there was a line length limit of
> typocally 512 bytes.
>
> Given the fact that the current SCCS implementation can be identified by calling
>
> sccs -V
>
> Output is:
> sccs schily-SCCS version 1.00.05 2011/04/20 (i386-pc-solaris2.11)
> or similar
>
> it would be nice if all tests could be called and passed by both, the current
> CSSC and the current SCCS.
I also think that would be a good idea.
> Conclusion:
>
> E28 should be changed to match the documented behavior.
I disagree, because this behaviour is not documented, and the user's
intent is clear.
> fa11 should be changed to match observed behavior from SCCS since
> 1987
This test shouldn't be run on SCCS, so I think this is moot.
> t5 We need to discuss whether it is better to match observed
> behavior from SCCS from Solaris (SVR4 behaves as documented)
> or whether it seems to be better to follow the documented
> behavior.
Let's try to be unambiguous here. The SunOS 5.10 manpage says of
"-r", " -r may be used only in conjunction with -i". However, the
POSIX 2008 standard does not require this. Hence I suppose a strict
reading of the text of the POSIX standard would imply that "admin -n
-r2 s.foo" should succeed, as you suggest.
It seems to me that we may be able to get this fixed as a bug in the
commercial Unix vendors' SCCS implementations, too. We can deal
with that in a separate thread.
James.
_______________________________________________
cssc-users mailing list
cssc-users@...
https://lists.gnu.org/mailman/listinfo/cssc-users
