Public bug reported:
do a 'strace env -i LANG=en_US.UTF-8 links www' (the env is just to
clear the environment so you know it's not just me).
You will see a bunch of:
open("../po/en_US.UTF-8.gmo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
open("../po/en_US.utf8.gmo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("../po/en_US.gmo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("../po/en.UTF-8.gmo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("../po/en.utf8.gmo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("../po/en.gmo", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
I imagine this is introduced in the compile (maybe for testing from the
source dir?):
$ strings `which links` | grep \\.\\./po
../po/
Apparently it's an upstream feature:
/* This is hacked for ELinks - we want to look up for the translations at the
* correct place even if we are being ran from the source/build tree. */
......
|| !add_to_string(str, "../po/")
This is a problem when ../po/ is slow. It could be a problem if ../po/ is
malicious, I think
(if you run links somewhere where there is a ../po/, will it override the
translations?)
** Affects: elinks (Ubuntu)
Importance: Undecided
Status: Unconfirmed
--
including hardcoded ../po/ in translation PATH
https://launchpad.net/bugs/70852
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
