[MPlayer-cvslog] r25556 - trunk/libmenu/menu_filesel.c

[Ulion]

2008/1/17, Rich Felker <dalias at aerifal.cx>:
> On Wed, Jan 16, 2008 at 02:39:42PM +0800, Ulion wrote:
> > > It actually does make perfectly good sense as long as MPlayer does not
> > > change its working directory during operation, and it's more robust
> > > than trying to resolve an absolute pathname which might not always be
> > > possible.
> > >
> > > Alternatively, prepend the working directory if it's possible to
> > > resolve it (and if the pathname does not begin with /) and resolve .
> > > and .. elements like a webserver would do.
> >
> > In all languages, there are pre-defined function do get the absolute
> > path, even in microsoft's api.
>
> This has nothing to do with languages but operating systems.
>
> > in standard c, the realpath seems do that,
>
> I think you mean standard Unix. Standard C does not even have a notion
> of pathnames and even POSIX does not require realpath.
>
> > but it's buggy or risky on some certain conditions, right? I
>
> It doesn't do what's desired here. Specifically, it resolves symbolic
> links, which is additional behavior which is probably undesirable to
> the user. (For instance the user does not want /home/myname to get
> changed to /mnt/nfs/foo/bar/homes/m/myname or something similar.)

Yes, symbolic resolve is not wanted.

>
> > don't think write such a function is so easy, if so there should
> > already be such safe function we could directly use.
>
> If you only want to resolve . and .. it's fairly easy, and the
> resolution can be done in-place over top of the original string.
> Prefixing the working directory if it's not an absolute path is also
> easy. Resolving symlinks is a bit of code, but again, I consider that
> highly undesirable behavior so don't do it.
>
> However, keep in mind that even the operation of identifying the
> working directory is not necessarily easy. On many systems it may not
> be possible to get the name if read or execute permission is missing
> somewhere in the parent hierarchy, and even if it is possible to get
> the name, the absolute pathname WILL NOT WORK for opening files if
> execute (search) permission is missing at any stage along the way,
> even though files can of course be accessed with relative pathnames.

try libmenu's file selection feature, the path we resolved will be
showed on the menu title, there need an absolute path. so what we need
is a path join function, just join a relative path to an absolute one,
and combine any './' or '../', and even more it's better it can handle
'\' properly for pathes come from command line parameter by windows
user.

-- 
Ulion