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

[Mario Domenech Goulart]

On Fri, 08 Nov 2013 22:50:47 +0000 Mario Domenech Goulart <address@hidden> 
wrote:

> 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?

Attached you can find an attempt to implement pathname-expand according
to the following assumptions:

* when no user home directory can be determined, assume "/"

* the home directory may change along the program execution

* use the HOME environment variable instead of `user-information' on
  non-Windows systems to determine the home directory.  On Windows, use
  HOMEPATH or USERPROFILE.

* use `user-information' on non-Windows to determine the home directory
  of other users (~user syntax).  On windows, the ~user syntax only
  works if user is the same as the value of the USERNAME environment
  variable.  I don't know a way to get information about the home
  directory of other users.

* expands both ~/foo and ~\foo on Windows

* expands ~~ at the beginning of paths to (or (repository-path) ".")

The attached program can be run with csi (or you can compile it with csc
if you want, naturally).  For tests to work on Windows, you'll need
b663e07c84bc011db7590f556b3cac02ce3e4308 (which fixes unsetenv).

Please, let me know what you think.  If the implemented behavior looks
sane, I can provide a proper patch.

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

pathname-expand.scm
Description: Binary data