bug-cssc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-cssc] Test delta/errorcase.sh -> E30 .. E32


From: James Youngman
Subject: Re: [Bug-cssc] Test delta/errorcase.sh -> E30 .. E32
Date: Sun, 22 May 2011 00:28:04 +0100

On Sat, May 21, 2011 at 7:35 PM, Joerg Schilling
<address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]