Re: [Vimprobable-users] Improve handling of file parameters
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
From: Hannes S. <ha...@yl...> - 2013-02-24 15:16:44
|
Hi! Morgan Howe <mt...@gm...> 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 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: . .. www.example.org and you call vimprobable 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. The first one, though, I cannot really argue against. In the end, I would say it is a matter of policy what the browser should 'assume', i.e. what it should give preference to. Right now, by using a very restrictive definition of calling local files, external URLs are always given preference. I'm not totally against changing this a bit in the way you describe. Does anyone else have an opinion? Hannes |