Re: warn about conflicting skeleton-generated files

[Joel E. Denny]

On Thu, 14 Dec 2006, Hans Aberg wrote:

> On 14 Dec 2006, at 07:54, Joel E. Denny wrote:
> 
> > A point of ambiguity just occurred to me.  What are relative file names
> > relative to?  For --skeleton, I think it's the current working directory.
> > For %skeleton, it seems like the grammar file directory, so that would
> > have to be prepended.

Sorry, my wording was confusing.  I meant to discuss what it should be not 
what it is.

> When I checked it (the right way) in 2.3a, there seems to be no difference:
> they are always relative the /usr/local/share/bison/ directory in my
> installation.

That's what it is.

> There, I want a way to make it relative the directory 'bison'
> was invoked.

For --skeleton, this is what I think it should be.  For %skeleton, I think 
it makes more sense for it to be relative to the grammar file, which is 
where the %skeleton is located.  In other words, I think it should always 
be relative to where you specified the file name.

> > I propose:
> > 
> > 1. If the file name does not contain `/', prepend `pkgdatadir/'.
> > 2. If it does, don't.
> 
> So this might suffice for that. But what if one writes
>   %skeleton "my/lalr.cc"
> Would one not expect it to work like
>   %skeleton "lalr.cc"
> but checking in the subdirectory "my"?

You mean checking in /usr/local/share/bison/my/ (the pkgdatadir)?  That 
was also my original intuition, which is strange since I can't think of 
any precedent that agrees with both it and the rest of my proposal.  That 
is, shell command lookup and `info --file' treat the file name as relative 
to the current directory simply because it contains a `/'.

I agree with Paul that following some widespread precedent has value when 
it comes to something as common as specifying a file name.