Thomas Adam <[email protected]> writes:
> On Thu, Jan 07, 2010 at 11:25:29AM -0500, [email protected] wrote:
>> I don't think using CWD is part of documented behavior...
>
> Hmm -- Do What I Mean (DWIM) approach here. It doesn't say it isn't part of
> documented behaviour either. :P
>
>> Making CWD the new default...hmm.
>
> Not the default unless specified as such, see below.
I meant that the logic looked first in the CWD.
The old logic looked first using the USERDIR/DATADIR.
>> All of my config files start with a dot.
>>
>> At first I thought testing for './' or '../' would
>> be the right fix. Does that seem right to you?
>
> I think so. See the patch attached. The comment block in the patch
> hopefully is self-explanatory.
>
> It does mean though that, whilst:
>
> fvwm -f ../../some_file
>
> ... makes sense, if it appears in a config file as:
>
> Read ../../some_file
>
> ... that FVWM will no longer find it, as it's never then expanded out to
> look in FVWM_USERDIR and FVWM_DATADIR. I personally don't consider *that*
> to be a bug, as the explicit action of "../../" is relative to something to
> the user -- what that might be is unknown, but I wouldn't want to suggest we
> then exapand it out to:
>
> FVWM_USERDIR/../../some_file
>
> Users doing this in their config file will have already made use of "$."
> anyway, I'd have hoped.
>
> What do you think?
Sounds reasonable but the patch doesn't look right:
+ if ((filename[0] == '.') &&
+ (filename[1] != '.' && filename[1] != '/'))
+ {
+ /* It's a relative path. */
"Read ABC" uses a relative path and doesn't pass.
How about going back to just slash for absolute paths,
then if DATADIR and USERDIR fail, try CWD.
