How do I configure Mercurial to use environment variables in mercurial.ini - variables

How can I modify the mercurial.ini file to include an environment variable such as %userprofile%.
Specific situation:
I am learning to use Mercurial. I have modified the [ui] section of Mercurial.ini (in my home path) to include:
ignore = c:\users\user\.hgignore
Where user is my username literal. The .hgignore file includes filename filters that are used to ignore files during commit. How can I alter it from being the a literal user to an environment variable $user?

It won't interpolate environment variables in the hgrc, but I do believe that tilda expands to your home/profile directory correctly even on windows.
So:
ignore = ~/.hgignore
should work on windows and elsewhere (even the slashes get spun the wrong way automatically for you).
For other variables you'd need to get a little tricker and write a batch/cmd file that does the interpolation in advance and then hands the result off to mercurial for processing.

The mercurial.ini parses the environment variables just fine.
From my mercurial.ini:
[ui]
ignore = %USERPROFILE%/.hgignore
Works like a charm. Windows 7 Ultimate x64, Mercurial 1.5 (binary installation). The hgignore file is honored both my the command line hg.exe, and tortoiseHG.

Related

Why are the files called .babelRC and .npmRC? [duplicate]

In my home folder in Linux I have several config files that have "rc" as a file name extension:
$ ls -a ~/|pcregrep 'rc$'
.bashrc
.octaverc
.perltidyrc
.screenrc
.vimrc
What does the "rc" in these names mean?
It looks like one of the following:
run commands
resource control
run control
runtime configuration
Also I've found a citation:
The ‘rc’ suffix goes back to Unix's grandparent, CTSS. It had a command-script feature called "runcom". Early Unixes used ‘rc’ for the name of the operating system's boot script, as a tribute to CTSS runcom.
Runtime Configuration normally if it's in the config directory. I think of them as resource files. If you see rc in file name this could be version i.e. Release Candidate.
Edit: No, I take it back officially... "run commands"
[Unix: from runcom files on the CTSS system 1962-63, via the startup script /etc/rc]
Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up.
Thus, it would seem that the "rc" part stands for "runcom", which I believe can be expanded to "run commands". In fact, this is exactly what the file contains, commands that bash should run.
Quoted from What does “rc” in .bashrc stand for?
I learnt something new! :)
In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command. It is believed to have originated somewhere in 1965 from a runcom facility from the MIT Compatible Time-Sharing System (CTSS).
Reference: https://en.wikipedia.org/wiki/Run_commands
In Unix world, RC stands for "Run Control".
http://www.catb.org/~esr/writings/taoup/html/ch10s03.html
To understand rc files, it helps to know that Ubuntu boots into several different runlevels. They are 0-6, 0 being "halt", 1 being "single-user", 2 being "multi-user"(the default runlevel), etc. This system has now been outdated by the Upstart and initd programs in most Linux Distros. It is still maintained for backwards compatibility.
Within the /etc directory are several folders labeled "rc0.d, rc1.d" etc, through rc6.d. These are the directories the kernel refers to to know which init scripts it should run for that runlevel. They are symbolic links to the system service scripts residing in the /etc/init.d directory.
In the context you are using it, it would appear that you are listing any files with rc in the name. The code in these files will set the way the services/tasks startup and run when initialized.

BlueZ: Change local storage directory

By default, BlueZ stores its persistent data in /var/lib/bluetooth. This includes controller settings and information about paired devices. However, I'm working in a system where the /var directory is unreliable, so I wonder if there is any way I can change this directory?
I have seen examples where it can be changed during installation, with the "--localstatedir" flag, but I'm looking for a solution that doesn't require reinstallation.
Without reinstalling its not possible. Path is configured at compile time so recompilation and installation is required. You can replace STORAGEDIR macro with string which is read from main.conf to different path at runtime. After modifying these changes you can restart bluetoothd every time you change path then it works.

How to use an environment variable in the odoo.conf

I am trying to use an environment variable in the odoo.conf
file to specify the path where the logs are stored.
So far I have tried:
logfile = ${test.rueda}/odoo.log
But it does not work.
Is there any way to achieve this?
The Odoo configuration files do not support access to environment variables.
I can think of 2 possible approaches:
Use relative paths. The file names in the configuration are relative to the working directory of the Odoo server process. Start the Odoo server in different directories, one for every purpose, and keep the same structure relative to that.
Use environment variables in the command line. When starting the Odoo server, any configuration option can be passed using -- (2 dash signs) as a prefix. In the start script, you can then use environment variables as in any other shell script.
See https://www.odoo.com/documentation/11.0/reference/cmdline.html for details.
For referencing files or path:
When i work without external disk (where i can find my datadir):
i use in odoo config file data_dir = my_absolute_path_in_my_local_disk.
This path have a symbolic redirection to where is my local physical location of my local data directory
When my external disk come back, i change the symbolic link:
my_absolute_path_in_my_local_disk -> my_external_disk_..._data

SSH unzip BUT with CASE-SENSITIVITY

I have am trying to unzip a file via SSH, I require a case sensitive unzip.
My server is using Debian Unzip 6.
It shouldn't be doing this, but it is converting all my file names to lower case, causing my Joomla site to buckle.
There are far too many files to rename manually or to FTP if I want to finish in my lifetime.
I have a zip called bv2.zip placed in the directory I want to extract in...
I have cd'd into my directory and simply issued: unzip bv2.zip .... filenames all go to lowercase...
I have also tried absolute paths to no avail, the UNZIP help and manual states that case sensitivity is enabled by default with this version, but obviously not...
Any ideas??
what does unzip -v file.zip show? The docs say
by default unzip lists and
extracts such filenames exactly as they're stored (excepting
truncation, conversion of unsupported characters, etc.)
It'd be worth checking how they are stored. If the creating zip program is storing them all as lowercase, then that's where you need to look for a way to actually store unaltered filenames.
Finally, just to be sure, check that there's no alias or environment variable on your Debian server forcing use of the -L option. Look at output of the following commands, run on the Debian server's terminal:
alias
(there should be no weird alias for unzip)
echo $UNZIP
(Any flags contained in this environment variable will be used by unzip as if they'd been added to the command invocation).
I was facing same problem in my 1&1 hosting. I have solved it by defining a new alias, by typing:
alias unzip='unzip'
The problem was unzip -L was aliased.
Now I have unzipped prestashop backup and it works like a charm
Regards
Are you sure your .zip file didn't have all lowercase names to begin with? Maybe whatever program you used to create the zip file is converting the names to lowercase.
The "-L" (convert all filenames to lowercase) and "U" (convert all filenames to upper case) options control this behavior:
http://www.mkssoftware.com/docs/man1/unzip.1.asp
This would ONLY be an issue if the files in the .zip were from a case-insensitive filesystem (like MS-DOS or VAX/VMS). It should not be an issue if the files were .zipped up on ANY contemporary filesystem (Unix, MacOS, Windows 95 or higher) with ANY contemporary version of Zip or WinZip.
Soooo ......
Is there any chance these are DOS files?
Or did you use a DOS version of PKZip?
Or were the files simply lower case to begin with?

Declaring global variable with php.ini

Is it possible to keep variables in php.ini file. Like that we do with the web.config in .net. I like to keep a flag type variable in the php.ini and use it to different projects.
It's not possible to set user-level variables within a plain php.ini file (or the .htaccess equivilents). There are some PECL modules that do allow that, such as hidef (http://pecl.php.net/package/hidef) - though these would need to be installed on every installation you use.
Including (or pre-including) a file with auto_prepend_file is quite possible - though that would be on every PHP request.
What is frequently done is setting an environment variable as part of the webserver process, which can be read from PHP. In Apache this is quite easy, with the SetEnv module.
SetEnv PRODUCTION_SERVER 1
And accessing it in PHP:
if ($_ENV['PRODUCTION_SERVER']) {...} // or getenv('PRODUCTION_SERVER')
Have you looked at get_cfg_var()?
I needed to do something similar, and this was able to do it for me.
Nope.
You could use the auto_prepend_file directive to automatically include a file that said, although as it uses the include_path, you'd need to specify the full path.
However, it's probably more transparent just to explicitly include/require the relevant file.
One technique that I have found useful for passing a limited number of global variables to a bootstrap script is to take advantage of the SetEnv directive in an .htaccess file. The advantage is that the variable you set will be made available to any script in that directory, plus any scripts in child directories under it.
You could use a SetEnv varibale with the location of a configuration file, such as:
in .htaccess:
SetEnv init_path /home/hendepher/TestApp/init/init.php
In your .php scipt:
<?php
if(!getenv('init_path')) throw new Exception('Must set init_path in .htaccess');
require_once getenv('init_path');
.
.
.
?>
If you have a test directory that requires different initialization o global variables, simply add another .htaccess file in your test directory:
SetEnv init_path /home/hendepher/TestApp/init/testing_init.php
Doing it this way, as opposed to using the 'auto_prepend_file' directive, is that your global configuration script is not run by all the php applications on your server: some may not need it.
The accepted answere also worked for me, with one change.
I didn't test this on earlier versions, but in my environment (php 5.4.22) this doesn't show up in $_ENV, but rather in $_SERVER.
In my .htacess file:
SetEnv PRODUCTION_SERVER 0.
My php code:
$production="PRODUCTION";
if (!isset($_SERVER['PRODUCTION_SERVER']) || $_SERVER['PRODUCTION_SERVER'] != 1){
$production="DEVELOPMENT";
}
I don't think that's a good place to store variables. php.ini is for storing configuration for PHP itself not your applications. You should consider putting the shared variables into a .inc file and including that instead.
Have you considered hidef?
Allow definition of user defined constants in simple ini files,
which are then processed like internal constants, without any
of the usual performance penalties.
Complementing #Ascherer answer, use get_cfg_var() to save custom variables in custom php.ini (variable created by you, not an official PHP ini directive). For example:
In php.ini: custom_variable = "abcde"
In any php script: get_cfg_var('custom_variable') returns abcde
I use this in in a small project in local dev. As I run the local server via php -S localhost:8000 -c php.ini (not running an Apache server locally), it's a good option to call some configuration constants. In production, these constants are set in .htaccess.