Re: [Bug-cssc] bug-CSSC post from address@hidden requires approval

[James Youngman]

On Sat, Apr 30, 2011 at 3:18 PM, Joerg Schilling
<address@hidden> wrote:
> James Youngman <address@hidden> wrote:
>
>> address@hidden (Joerg Schilling) wrote:

>> > Out of curiosity: the new 'x' flag is not mentioned by your "val"
>> > implementation if present in a SCCS history file.
>>
>> Yes.  The 'x' flag is from SCO SCCS.   I'm not sure what you're
>> suggesting val should do differently here.
>
> Thank you for pointing to this problem. It is a long time since I used the SCO
> sccs (aprox. 10 years) and it seems that it is too long that I read the
> related man page. The 'x' flag as used by SCO however seems to be useless
> as SCCS has a better way to deal with the execitable bit on files: Just
> chmod +x SCCS/s.somefile
> This is more intuitive.
>
> It seems however that I should ignore the 'x' flag in case that it has not 
> been
> added together with the "SCHILY" argument.

Or you could support the SCO semantics if the flag value is "1" rather
than "SCHILY".   Up to you.

However, there's still an incompatibility.  The problem is, what an
implementation should do in response to:

admin -fx /somepath/s.foo

Clearly there are two options:

1. Set the x flag to 1: be compatible with SCO SCCS
2. Set the x flag to SCHILY: be compatible with Schily SCCS v 1.1 and
later (I think that's the right version)

I can't see a way for the admin program to determine which behaviour
the user wants.   Apart of course from introducing an incompatible
configure-time selection or relying on some environment variable.   I
don't think using stat on the g-file is likely to be reliable enough,
especially since there may be no gfile.

James.