Adding a runtime dependency to a package through override buildInputs causes the package to rebuild. Is there a simple way to inject runtime dependencies into a package without recompiling?
So basically adding package/bin to PATH and package/lib to LD_LIBRARY_PATH
If I understand correctly that you want to tweak the environment used when a Nix-installed app is run, not the one used when it is built, then a method I know of is as follows below. By using it, you essentially create a wrapper script, which overrides the "default command". So, something similar like creating e.g. a custom ~/bin/vim script, which adds some options/env overrides to the default vim binary, which is called with a "hardcoded original path" inside the script.
One example of it in nixpkgs is how vimutils.vimWithRC overrides vim command with a custom script. For your own use, you could write more or less something like below:
with import <nixpkgs> {};
writeScriptBin "vim" ''
#!/usr/bin/env bash
export PATH=package/bin:$PATH # whatever you like; I've added what you asked for
export LD_LIBRARY_PATH=package/lib:$LD_LIBRARY_PATH
${vim}/bin/vim --my-options "$#"
'';
If you put it in my-vim.nix, you should be able to install it with:
$ nix-env -e vim # REMOVE NORMAL VIM. I think this should be done first to avoid conflict
$ nix-env -i -f my-vim.nix
And hopefully it'll work and "override" the default vim for you.
DISCLAIMER: I haven't actually tested it in this exact form, sorry. Don't have a Nix console handy at this moment, unfortunately.
Related
What I think that I've understood about home-manager.
Instead of using
nix-env iA packageToBeInstalled
you write a list of package in a file (/home/nixos/.config/nixpkgs/home.nix that I from now on call just home.nix)
you run
home-manager switch
and the package are installed.
But I have already installed some packages with nix-env. (home-manager for instance)
I would like to have my configuration save just in home.nix in order to just have to import it and execute home-manager switch to import the exact same configuration in a other OS.
Therefore I need a command replicating my configuration in home.nix.
I am not aware of a tool that fully automates this.
The nix-env list of installed packages is maintained in ~/.nix-profile/manifest.nix, but does not contain the attribute path, which is the "name" you need to use in such configuration files.
To find the attribute paths for the things you've installed, you may first create an index of sorts based on your current nixpkgs (NIX_PATH etc):
nix-env -qaP >packages.tmp
and then use it to look up each package.
Here's a one-liner that doesn't work for all packages.
nix-env -q | while read name; do grep "$name" <packages.tmp; done
So make sure to read through nix-env -q yourself and look up anything that's missing using for example https://search.nixos.org/packages.
To finalize, remove the imperatively installed packages with nix-env -e, check nix-env -q, and rm packages.tmp.
When I use command sudo vipw to edit my password file, It's always use vi as editor. I don't like this very much and want to change it to vim.
I already tried:
Add export EDITOR=/usr/local/bin/vim in /etc/profile.
But shell told me "export: Command not found". I thought the reason is export is built-in function only in bash. And I don't want to change my shell.
AddEDITOR=/usr/lcoal/bin/vim in default block of /etc/login.conf
Add setenv EDITOR vim in /root/.cshrc, /.cshrc, ~/.cshrc
All above didn't work at all.
I have google for hours but could not find anything help.
Your /etc/sudoers file doesn't keep your EDITOR environment variable.
I personally have an /etc/sudoers.d/local file, something like
# We don't need to worry about wheel users breaking in to get root access because they already have it.
Defaults:%wheel env_keep+="HOME EDITOR",!set_home,shell_noargs
I'm not sure why this isn't the default, since wheel users have already been given full access. But it's apparently prevailing wisdom to continue hassling them.
Note: If you're using an older /etc/sudoers file that doesn't support an /etc/sudoers.d directory, these lines can be dropped in there... or you could add #includedir /etc/sudoers.d as the last line of your /etc/sudoers file to enable an /etc/sudoers.d directory. Um, yes, the # is a required part of that line, because someone thought it was important for that directive to look like a comment.
Try adding this to the root user /root/.chsrc:
setenv EDITOR vim
or to set it globally to all users using shell tcsh/csh add it in /etc/csh.cshrc
From the man:
A login shell begins by executing commands from the system files /etc/csh.cshrc
and /etc/csh.login. It then executes commands from files in the user's home directory:
first ~/.tcshrc or, if ~/.tcshrc is not found, ~/.cshrc ...
Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on startup.
Also verify vim is installed since is not by default, you could try:
pkg install vim-console
setting the EDITOR or VISUAL environment variable is the key.
if you don't want to go to the trouble of modifying config files (which is indeed the long term solution) then you could sudo su - to get to the root prompt and then you could export EDITOR=/usr/bin/vim before running vipw
There is an empty file called .selected_editor in $HOME (/root).
Remove it and the next call to vipw will ask you to select the editor.
I'm trying to write (what I thought would be) a simple bash script that will:
run virtualenv to create a new environment at $1
activate the virtual environment
do some more stuff (install django, add django-admin.py to the virtualenv's path, etc.)
Step 1 works quite well, but I can't seem to activate the virtualenv. For those not familiar with virtualenv, it creates an activate file that activates the virtual environment. From the CLI, you run it using source
source $env_name/bin/activate
Where $env_name, obviously, is the name of the dir that the virtual env is installed in.
In my script, after creating the virtual environment, I store the path to the activate script like this:
activate="`pwd`/$ENV_NAME/bin/activate"
But when I call source "$activate", I get this:
/home/clawlor/bin/scripts/djangoenv: 20: source: not found
I know that $activate contains the correct path to the activate script, in fact I even test that a file is there before I call source. But source itself can't seem to find it. I've also tried running all of the steps manually in the CLI, where everything works fine.
In my research I found this script, which is similar to what I want but is also doing a lot of other things that I don't need, like storing all of the virtual environments in a ~/.virtualenv directory (or whatever is in $WORKON_HOME). But it seems to me that he is creating the path to activate, and calling source "$activate" in basically the same way I am.
Here is the script in its entirety:
#!/bin/sh
PYTHON_PATH=~/bin/python-2.6.1/bin/python
if [ $# = 1 ]
then
ENV_NAME="$1"
virtualenv -p $PYTHON_PATH --no-site-packages $ENV_NAME
activate="`pwd`/$ENV_NAME/bin/activate"
if [ ! -f "$activate" ]
then
echo "ERROR: activate not found at $activate"
return 1
fi
source "$activate"
else
echo 'Usage: djangoenv ENV_NAME'
fi
DISCLAIMER: My bash script-fu is pretty weak. I'm fairly comfortable at the CLI, but there may well be some extremely stupid reason this isn't working.
If you're writing a bash script, call it by name:
#!/bin/bash
/bin/sh is not guaranteed to be bash. This caused a ton of broken scripts in Ubuntu some years ago (IIRC).
The source builtin works just fine in bash; but you might as well just use dot like Norman suggested.
In the POSIX standard, which /bin/sh is supposed to respect, the command is . (a single dot), not source. The source command is a csh-ism that has been pulled into bash.
Try
. $env_name/bin/activate
Or if you must have non-POSIX bash-isms in your code, use #!/bin/bash.
In Ubuntu if you execute the script with sh scriptname.sh you get this problem.
Try executing the script with ./scriptname.sh instead.
best to add the full path of the file you intend to source.
eg
source ./.env instead of source .env
or source /var/www/html/site1/.env
I have a nix expression file (.nix) and a shell script builder, specified like:
stdenv.mkDerivation rec {
name = "my-env";
builder = './my-builder.sh';
...
./my-builder.sh: No such file or directory when I run nix-build ./my-env.nix; the nix expression file and builder scripts are sitting side-by-side in my home directory.
My intent is to use this nix expression file to prepare an environment using nix-build and then to actually quickly run the environment whenever I want to use it (using nix-shell).
EDIT: I just noticed that nix-shell ./ my-env.nix works fine; so far I'm not actually building anything, so I should probably just omit the builder.
EDIT#2:
My concrete example is the following:
This line puts both the nix expression and the builder in the same directory. This other line uses nix-shell to prepare the environment, but I assume a similar nix-build command could be used (especially if one wanted to install a custom package as part of the environment, but maybe that is not very idiomatic in Nix)
Solution
Quotes around the builder's path were apparently a no-no. I ended up having other issues, and pieced this together to eventually get the thing to run:
builder = builtins.toFile "builder.sh" ''
source $stdenv/setup
mkdir -p $out
echo "" > $out/Done
echo "Done setting up Scala environment."
'';
Try putting a semicolon at the end of the line and removing the single quotes:
builder = ./my-builder.sh;
Then double-check to make sure my-builder.sh is in the same directory as the .nix file where you wrote that.
I want to replace some utilities(like telnet) with transparent wrappers(with loggers).
At first I used aliases, that worked nicely at the command line but gnome doesn't understand shell aliases so that when people would launch the utilities as the shell for a gnome-terminal profile it would run the actual utility instead of the wrapper.
Then I tried adding new folder with symlinks and prepended it to PATH(security isn't a huge concern plus its a special folder just for these symlinks) in ~/.bashrc but they still run the original(I'm guessing gnome doesn't run .bashrc since it works from the command line). Any ideas where setting path needs to go?
Maybe update-alternatives fits your needs?
I found two ways to do this that seem to work like I want(sourcing scripts for gnome env).
First putting it in ${HOME}/.gnomerc (but I found some places that say you should manually exec gnome session afterwards and others that don't(It seems to work fine without it) and I'm afraid of breaking login.)
Putting it in ~/.profile seems to work so I just
echo 'PATH=~/.symlink_dir/:${PATH}' > ~/.profile
(note that this is ignored by bash if a ~/.bash_profile exists so you may want to manually source it from ~/.bash_profile just in case
echo 'source ~/.profile' >> ~/.bash_profile).
If you really want to use your replacement utilities throughout, you could put symlinks to your replacements in /usr/bin/ (or wherever as appropriate) and move the originals to /usr/bin/originals/ (or wherever).
If you do that, you'd better make sure that your wrappers are rock solid though. Depending on what you're replacing, errors might prevent booting, which is generally undesirable.
It might not be what you are asking, but have you tried changing the commands of the launchers from the menu editor.
If you are using Gnome 3 you will have to download the alacarte package.