On Sat, May 21, 2011 at 7:35 PM, Joerg Schilling
<joerg.schill...@fokus.fraunhofer.de> wrote:
> Well, the related code is only in the -i code path. The behavior thus seems to
> be indented this way by Sun.
>
> ==> I however could be convinced to permit admin -b -n
Thanks.
>> > admin/r-option.sh.
>> > docommand t5 "${admin} -n -r2 $s" 1 "" IGNORE
[...]
> SVr4 permits -r only with -i, so this is a Solaris change. I have no idea when
> it has been introduced. As mentioned, I believe it is useful.
>
> ==> I just like to inform you that there should be no test that expects to
> see "admin -r2 -n s.foo" to fail.
OK, point taken. I've commented out the test (so now the regression
tests permit either).
> Regarding portability of scripts, we could make the documentation in a way
> that
> permits admin -r -n to fail, e.g. by the hint: "max not work with onther SCCS
> versions".
Agree. The CSSC documentation already has a suitable section for this.
> I am sure that you know that the existence of --something in many GNU tools
> did
> already result in many non-portable scripts and there is no man page that
> warns
> of using --something.
CSSC doesn't do that though.
>> > 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.
>
> Well, I tried to inform you that you may enable _many_ other tests for a
> recent
> SCCS. There currently are just three tests that fail in case you enable all of
> these tests.
Two now.
> If you don't include code in CSSC that automatically switches to binary
> (encoded) mode, why did you write this test?
I do include such code.
>
>
>> > 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.
>
> Thank you
>
>> > 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.
>
> Let me quote the POSIX standard:
>
> -i[name]
> Specify the name of a file from which the text for a new SCCS file shall be
> taken. The text constitutes the first delta of the file (see the -r option
> for the delta numbering scheme). If the -i option is used, but the name
> option-argument is omitted, the text shall be obtained by reading the
> standard input. If this option is omitted, the SCCS file shall be created
> with control information but without any file data. The -i option implies
> the -n option.
>
> The last sentence is in conflict with historic SCCS behavior, but Sun chnaged
> their copy to match POSIX. POSIX does not mention that -n if exquivalent, but
> if we agree that the last sentence from POSIX -i should be interpreted to:
> "The options -n -and -i are equivalent except for the parameter to -i", then
> I would need to permit "admin -b -r s.foo" with SCCS.
>
> You however would then also need to permit "admin -r2 -n s.foo" with CSSC for
> orthogonality.
I just updated the test suite to remove the test for this case, but I
haven't yet made the code change to actually permit this combination.
Swap it for admin -b -n :)
>> > 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.
>
> If you just see it as a test to verify that nobody changes CSSC to
> automatically switsch to binary mode, you may be right.
>
>
>> > 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.
>
> See above....
>
>> 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.
>
> Do you have contact to the related people?
I'm afraid not. Indeed you indicated you think that no development
has taken place on the Unix vendors' SCCS implementations since y2k.
I can believe it, and if that's true, there will be no such people,
either. I mailed a friend of mine who would be likely to know but
don't expect a reply on that until the working week has begun.
James.
_______________________________________________
cssc-users mailing list
cssc-users@gnu.org
https://lists.gnu.org/mailman/listinfo/cssc-users
