I want to use an environment variable in the subprocess command, eg:
[program:server]
command=/server/bin/server --loglevel=$LOGLEVEL
I also tried %(ENV_LOGLEVEL) which didn't work.
what is the proper way of doing this ?
I believe %(ENV_LOGLEVEL)s would be the correct way, but bear in mind that this was only added in version 3.0a11 - versions installed by eg apt-get on ubuntu may be older than this.
Related
I have a Linux server, and it has its own Perl whose version is not what I want. So I want to install another Perl on it.
I tried to solve it with Perlbrew, but my server can't download it. It seems like my server does not trust that website address. And I don't know whether I should download it as root. Besides, I think there is a huge difference between root and a normal user to download and install it, and I just want do it as a normal user.
Is there another way install different version Perl on my server?
I downloaded the version I want before, and I tried to install it in a usual way, but it just failed.
Here is the wrong when I tap the command
wget -O - https://install.perlbrew.pl | bash as a normal user.
Maybe I should tap it as root?
And when I try to install the Perl v5.8.8(this is version I want) in ~/bin,i run the Configure.
But I can not run make after that, it just told me that make:No rule to make target , needed by miniperlmain.o Stop.
Besides,
my Linux is Centos 7.4. I don`t how to fix it.
It seems that I find a way to let me to make.
Here is the link.
After I edit the makedepend.SH, I run make again. But I got this wrong:
The thing is really weird. Why Perl V5.8.8 is so difficult to install.
The easy answer is 'just install perl' - it'll drop by default into /usr/local/bin, and you can just use that instead.
DON'T overwrite /usr/bin/perl, as that's a recipe for pain. (Lots of stuff will have dependencies on perl versions installed via your package manager).
Im working on a Ubuntu 14.04 64bit machine.
I need to use Perl 5.14 to work with certain modules which wont install with the newest version of perl (5.18). My postgresql-9.3 server needs to install perl 5.18 while installing postgres-plperl.
Therefore i want to tell Postgres to use the 5.14 version but i havent found a way to do that.
Is there a way to do that?
You must recompile the plperl extension against 5.14 if you really need this. PostgreSQL links against Perl as a library, and Perl libraries aren't ABI-compatible across releases, so you can't just substitute 5.14 for 5.18 at runtime.
You can change the Perl version used by performing an install of PostgreSQL from source and specifying the correct Perl install path to configure using --with-perl or the PATH env var.
Or you can apt-get source postgresql-9.3 and edit debian/rules to use the desired Perl, edit debian/control to specify the correct Perl dependency, and rebuild the package.
It makes a lot more sense to instead fix the modules.
I was using ubuntu 12.04 until 12.10 was released. I used ubuntu for software development and after installing 12.10, i noticed that the perl version (5.14) shipped with 12.10 does not include the Switch.pm module needed while building WebKiT-GTK.
Looking around on the internet i found few suggestions indicating that i should install something call p5-switch from something called ports. I have looked around and was not able to get this done. I am not a perl guy and have no idea where i can get this package.
Can someone please help me as to
1. Where to download the package for ubuntu 12.10
2. In case it is not a .deb, How do i install it.
OR
1. At least be able to downgrade the perl installation to something lower than 5.14
Thanks and Regards
~Sameer
sudo apt-get install libswitch-perl
will install it for you.
"ports" is a *BSD packaging system of sorts, not what you should be looking for.
You can find what package has a particular perl module by going to packages.ubuntu.com, entering Module/Name.pm (in this case, Switch.pm) in the "Search the contents of packages" form and checking "packages that contain files whose names end with the keyword" and selecting the desired distribution, then making sure you ignore false hits like CGI/Switch.pm in the results. Debian has the identical search for its packages at packages.debian.org.
(Note that Switch.pm has serious limitations, was never really intended to be used in production, and should certainly not be used in new code.)
Do make sure you've checked properly that there isn't the Switch module available via apt. If it is available, that's the one you want.
No, then you've two options the longer, correct way and a shorter way that's not quite as clean.
1. Longer
Install cpanm and perlbrew with apt. The perlbrew tool lets you install a complete version of Perl from scratch in a separate directory. Set up a user for your webkit building, run perlbrew as that user, install your perl. Then, use cpanm to install required modules and you are done. A bit of googling will get you step-by-step examples of how to use these tools. If anything goes badly wrong, you can just delete all the files in that user's home directory and start again - all you waste is a little time.
The reason experienced Perl people prefer this is that it keeps the perl you want for webkit-gtk separate from your system perl that ubuntu's packages will expect to be unchanged from the one they ship.
2. Shorter
Install cpanm with apt. As root, run "cpanm Switch" and it will install the Switch.pm package and any dependencies. It will also upgrade any already installed packages it thinks it needs to. This last step is why this option isn't ideal. In the (rare) case when the update isn't compatible with something else on your system uninstalling is fiddly.
I've installed REE on CentOS 5 for a very special task (using rails 2.3.10 and ruby 1.8) and I really need it to be isolated
In this case I won't use bundler or smth so.
Everything works ok if I'll setup every gem manually via
/opt/ree/bin/gem install agem
But when I run
/opt/ree/bin/rake gems:install
in prepared for this command project - all (or most, I haven't check every dependency) gems are installed via /usr/bin/gem into common gem path, where I do not need any of them
This is an issue and I do not want to install all gems manually. Have smb ever hit into this issue and probably knows solution?
Solution that really helped me was to temporarily replace /usr/bin/gem with a symbolic link to /opt/ree/bin/gem
With this replacement /opt/ree/bin/rake gems:intall worked as expected - all required gems were installed to REE path - returning /usr/bin/gem to original gem executable made system stable again
This is not very clean solution but it works, so it can be used like hammer in critical situation.
There's either a GEM_HOME variable somewhere in the environment, or the runtime ruby called is not ree. Therefore, I'd suggest at least 3 things to try:
Start with an almost empty environment (run env -i sh for example) and run again the rake command, see if this is still installs gems in the common gem path. Be careful, because env -i is an empty environment, you might see complaints from rubygems (because no HOME or nothing else is set)...
Check that the shebang line (first line of the rake program) really indicates your REE binary and not something else
Finally, do run rake using the REE binary with /opt/ree/bin/ruby /opt/ree/bin/rake gems:install
This should give you an indication of what's going wrong. All in all, I think that the environment issue is probably the most probable culprit of this thing
I'm using perlbrew right now to manage multiple versions of perl, but perlbrew is global. If I do perlbrew switch perl-5.10.1 in any shell, then all shells and scripts will now be using perl version 5.10.1. There is no isolation. Is there any way to make perlbrew switches local to a shell, or is there a similar tool capable of locally changing the active perl?
Just don't use perlbrew. All it's doing is changing symlinks for you. It's supposed to save you work, but when it's not, there's no longer a reason to use it.
I talk about how I do it in Make links to per-version tools in The Effective Perler. I always know which perl I'm using because I never have to remember which one I switched to last, and I don't disturb anything else expecting a particular version behind a symlink. You can still use perlbrew to install perls, but it's not saving you that much work there either.
In more recent versions of Perlbrew, you can do perlbrew use perl-5.12.3 or whatever and you'll be using that version of Perl, but only in the current shell session. Other sessions won't be affected.