in reply to Re^4: @INC not reflecting correctly
in thread @INC not reflecting correctly

However, Linux (amazingly) apparently does not provide such a convenience. 

It's not that amazing: in Linux the dir(s) containing the executable(s) is common to all installed programs: /bin, /sbin, /usr/bin, /usr/local/bin. It is not the case that each program has its own private bin/, lib/ (include/, etc/) and keep adding private bin/ dirs to the PATH, which (the PATH) being such a primitive structure it is "difficult" to add a path somewhere in the middle, say, in order to precede some similarly-named program, e.g. another Perl. With a common bin/ dir (Linux), programs have to either overwrite existing one or be renamed. Deriving the INC by and relative to the location of the executable can not work in Linux (5' EDIT: see Re^5: Devel::NYTProf: "undefined symbol: PL_stack_sp" error for how paths are hardcoded within libraries). Or any other sane OS which likes to put its soldiers to a communal camp, provided they all keep clean socks. In this way, a single bin/ file-permissions and other security policy will be saner to maintain. Additionally, there are (usually) no private program installations (re: "Do you wish to install this program for all users or just for you?") except in a groups-based way (e.g. admin, staff, etc.). Again, easier to maintain security policy. The results are obvious from a glance at the battlefield: virtually each and every windows box is pawned (including that windows XP of UK's 3bn nuclear air-carrier, see also here, for the other side of the story).

bw, bliako