Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

Apologies for the odd means of responding - I'm not on the list, please CC
me in the future. :)


> Hi!
> Morgan Howe <mthowe@...> wrote:
> > I look at a lot of test generated html output and the like, so I
> > frequently hit problems with file paths. Because of the URI, things
> > would only open properly if I provided a full path, or something that
> > would be expanded by the shell into a full path such as
> > ~/html/index.html. Modified to use realpath() to fix this issue. It
> > would also fail to detect file parameters without a "/" in the path
> > (e.g. "index.html"), so changed to use stat() instead of looking for
> > "/" or "./" when determining if an argument is a file. This takes care
> > of any issues I have run into with using vimprobable to view local
> > files.
> Hmm... well, this seems to work as advertised, but I'd like to hear
> some opinions. As far as I can see, your problem boils down to
> a) relative paths not being recognised (e.g. ../dir/file.htm).
> b) you assuming that . should be in the search path (e.g. index.htm).
> The second one, I don't really consider a problem, to be honest. You
> could easily just write
> vimprobable ./index.htm
>

Agreed, the second case wasn't really a big issue, but the way I changed
the code fixed it for both cases.


> on your command line. Your solution would make it impossible to call
> URLs from a directory which has a file or subdirectory with the same
> name as the URL. E.g. if your file system looks like this:
> .
> ..
> http://www.example.org
> and you call
> vimprobable http://www.example.org
> it will call the local directory instead of the URL. No workaround
> possible. Before someone argues that this is a rather academic example,
> I would like to point out that such a directory structure is not so
> uncommon on machines used for web development.
>

Yeah, I considered this, though I was thinking that would be a rare
situation. Not being a web developer personally, that may have been a bit
presumptuous. Perhaps it may be better to check if the parameter is already
a URI first, before checking if it is a file? At least that way, there
would always be a workaround in case of name conflicts.

Regards,
Morgan