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

[Peter Bex]

On Fri, Nov 08, 2013 at 10:50:47PM +0000, Mario Domenech Goulart wrote:
> 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.

That's exactly why it shouldn't be done by default :)

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

Hm, that's a use case i hadn't considered.   Raising an exception is the
easy way out, but you're right we might not always want that.

I guess any way around this is good, as long as it is clearly marked in
the documentation.

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

I have a slight preference for "/", as that results in more "stable",
reproducible behaviour.  Otherwise it's highly dependent on the directory
from which the user happened to start the application.

> `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.

Me too.

> 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).

I agree.

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

Yes, here I agree too.  But only under Windows!

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

It looks like to get the user homedir on Windows, you have to dig
into the Registry:  http://www.gossamer-threads.com/lists/python/python/613895
Ideally, user-information returns info from here.  However, we don't
support the Registry right now, so I guess for now we can just say
it's unsupported, and it won't expand to anything at all on Windows:

(pathname-expand "~foo") => "~foo"

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

What would that syntax do?  My shell doesn't seem to know about
this, and just keeps it unexpanded.  If someone has a username
of "~foo", then 

(pathname-expand "~~foo") => "/home/~foo"

Otherwise, 

(pathname-expand "~~foo") => "~~foo"

So, if ~ is followed by a / (or \ on Windows), it should expand to
homedir, otherwise take everything up to the next \,/ or the end of
the string and use that as the "username".  That's simple, and can
be explained easily to the user.  Robust semantics FTW :)

Cheers,
Peter
-- 
http://www.more-magic.net