Re: [Chicken-hackers] [PATCH] add pathname-expand

[Mario Domenech Goulart]

Hi Felix and all,

Sorry for taking so long to handle this issue.  To be honest I'm a bit
lost at it (see comments and questions below).

`pathname-expand' looks quite simple at the first sight, but it turns
into a can of worms when some corner cases come into play.

On Tue, 20 Aug 2013 09:35:49 +0200 (CEST) Felix <address@hidden> wrote:

>> I noticed your patch uses `user-information', that can be called
>> depending on the input format, but it doesn't check if it's running on a
>> windows system.  Isn't it going to "break" on windows?  
>
> Yes.
>
>> I don't have a windows box at hand right now, so I cannot test it,
>> but it seems that posixwin uses define-unimplemented to define
>> user-information, which will just make it raise an error.
>
> That's correct.
>
>> Sorry for bringing this topic again, but with regard to
>> pathname-expand's behavior: you already said you are not for raising an
>> error in case no home can be determined.  OTOH, in the
>> http://lists.nongnu.org/archive/html/chicken-hackers/2013-07/msg00009.html
>> thread at least Peter, Alan, Evan and Alaric think raising an exception
>> is the right thing to do (I think so).
>> 
>> Since people seem to disagree on that point, I think I should ask again
>> as an attempt to reach a consensus or to at least justify our decision,
>> even if it doesn't make everybody happy: should we go ahead and assume
>> "."  when no home can be determined instead of raising an exception?
>
> Well, that's how I handled it. If raising an exception is considered
> the better option, then, fine.

I've been thinking about that behavior and I have to agree with you.
Raising an exception would be too extreme.  For example, some programs
run by system users (e.g., daemons), which may not have the home
directory set, would fail because of that behavior.  You may ask why
such programs would want to read a file in the user home dir in the
first place, since it is not supposed to be set.  I don't have a decent
answer for that question, but some eggs do explicitly expand pathnames,
and software that use those eggs would simply break with such a change.
Maybe eggs should be considered broken in that case?  I don't know.

Some assorted comments and questions:

In case we decide not to raise an error when no home is set, what should
we use as fallback for homeless users?  The current patch to implement
`pathname-expand' uses `user-information' to determine the user home
directory on Unix.  On Unix, `user-information' gives "" when no home is
set in passwd.  Should we really use ""?  Or "/"?

`user-information' uses getpwnam to obtain information about users.  The
manual page for getpwnam(3) on the system I'm using (Debian GNU/Linux)
says:

    An application that wants to determine its user's home directory
    should inspect the value of HOME (rather than the value
    getpwuid(getuid())->pw_dir) since this allows the user to modify
    their notion of "the home directory" during a login session.  To
    determine the (initial) home directory of another user, it is
    necessary to use getpwnam("username")->pw_dir or similar.

That calls for another question: should `pathname-expand' assume that
the user home directory can change along the process execution?  I think
so.

In any case, I think `pathname-expand' should use the HOME environment
variable on Unix, just like it does on Windows.  And I think it should
not cache HOME's value (i.e., it should properly handle changes in
HOME's value).

With regard to Windows: both #\\ and #\/ are valid directory separators.
Should `pathname-expand' expand ~/foo _and_ ~\foo?  I think so.

What should `pathname-expand' do on Windows when given ~foo?

With regard to the ~~ syntax: what ~~foo should expand to?

Best wishes.
Mario
-- 
http://parenteses.org/mario