If you wish to install ikiwiki in your home directory (for example because you don't have root access), you need to set environment variables (such as PATH and PERL5LIB) to point to these directories that contain your personal copy of IkiWiki.

The CGI wrapper remembers PATH, but not the environment variable PERL5LIB. Consequently, it will look for plugins and so on in the usual system directories, not in your personal copy. This is particularly insidious if you have a system copy of a different version installed, as your CGI wrapper may then load in code from this version.

I think the CGI wrapper should remember PERL5LIB too.

-- Martin

Thank's a lot for pointing me to this location in the code. I was looking it for some time.

This brutal patch implement your solution as a temporary fix.

    *** Wrapper.pm.old      2012-08-25 16:41:41.000000000 +0200
    --- Wrapper.pm  2012-10-01 17:33:17.582956524 +0200
    ***************
    *** 149,154 ****
    --- 149,155 ----
      $envsave
            newenviron[i++]="HOME=$ENV{HOME}";
            newenviron[i++]="PATH=$ENV{PATH}";
    +       newenviron[i++]="PERL5LIB=$ENV{PERL5LIB}";
            newenviron[i++]="WRAPPED_OPTIONS=$configstring";
      
      #ifdef __TINYC__

As I am not sure that remembering `PERL5LIB` is a good idea, I think that a prettier solution will be to add a config variable (let's say `cgi_wrapper_perllib`) which, if fixed, contains the `PERL5LIB` value to include in the wrapper, or another (let's say `cgi_wrapper_remember_libdir`), which, if fixed, remember the current `PERL5LIB`.

-- Bruno

**Update:** I had not seen this bug earlier, but I ran into the same issue and made a more general solution. You can already add stuff to `%config{ENV}` in the setup file, but it was being processed too late for `PERL5LIB` to do any good.
[This change](https://github.com/jcflack/ikiwiki/compare/early-env) moves the `%config{ENV}` handling earlier in the wrapper, so anything specified there is placed back in the actual environment before Perl gets control. Problem solved!

-- Chap

> Thanks, this looks like a nicer solution than the above. Some review:
>
>     + $val =~ s/([\\"])/\\$1/g;
>
> This is *probably* OK, because the configuration is unlikely to include
> non-ASCII, but I'd prefer something that covers all possibilities,
> like this:
>
>     my $tmp = $val;
>     utf8::encode($tmp) if utf8::is_utf8($tmp);
>     $tmp =~ s/([^A-Za-z0-9])/sprintf "\\x%02x", $1/ge;
>
> and then passing $tmp to addenv.
>
>     + delete $config{ENV};
>
> I don't think this is particularly necessary: there doesn't seem any harm
> in having it in the storable too?
>
> --[[smcv]]

Happy to make the escaping change, thanks for the sharp eye.

My thinking on `delete` is once it's handled, it's handled. The C code
is going to put this straight into the real environment and then do
a simple `exec` ... is there any way this hasn't been handled?

It just takes up space twice in the generated wrapper otherwise.
Admittedly it's not much space, but seems to be even less point ... ?

-- Chap

> That makes sense, as long as nothing else is going to read
> `$config{ENV}` for purposes other than copying it into the actual
> environment. --[[smcv]]