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.
Related
I would like to change my HOMEBREW_EDITOR. Sadly I do not have a ~/.bash_profile as I am using a Mac. Instead I have a ~/.zprofile which usually does the job. Now I added HOMEBREW_EDITOR=nano to this profile and typed in source ~/.zprofile but nothing changes. What can I do?
Thanks,
Emil
I was expecting nano to open when typing in brew edit but vim opened again.
Having a ~/.bash_profile is unrelated to you using a Mac or not: you can create it if you want. However if you used ~/.zprofile in the past for such thing indicates you are using Zsh instead of Bash, so your configuration should go in ~/.zprofile (or ~/.zrc) rather than ~/.bash_profile (or ~/.bashrc).
The part you are missing is the export keyword:
export HOMEBREW_EDITOR=nano
Without export, the variable would be set for your shell but wouldn’t be passed to child processes such as Homebrew.
At some point, whenever I use vi from the command line (windows 10/WSL) it starts up in insert mode, meaning that everything I usually do to navigate ends up adding stuff to the file, wasting time having to clean it up.
I didn't have a vimrc file, and there doesn't seem to be anything in my bash rc files to modify vi behavior. Any ideas what I may have done or any ideas how to stop this behavior? I'm using Ubuntu-20.04
FWIW, adding a .vimrc file with tab related settings didn't change it's behavior. I looked at the /etc/vimrc file, and nothing inside it seemed relevant.
After plowing through google search and trying everything I understand about configuring 'vim' and doing comparison tests, I think:
This behavior is specific to Windows Terminal when opening a WSL terminal. Using WSL's "native" terminal (i.e., clicking the "Ubuntu 20.04 LTS" menu in the "Start" menu) doesn't have this problem.
My original motivation for switching to Windows Terminal is for its multi-tab feature. But this new behavior is crazy -- it works against years of my muscle memory of using "vi", and I'm almost certain that one day I'll accidentally update some configuration file while reading it in "vi". And, I cannot re-train a new muscle memory because all the rest of the UNIX world (e.g., when I SSH into a remote server) hasn't changed. This is like constantly switching between a Mac keyboard and a PC keyboard where the Ctrl key, etc., are in different places.
My solution: I switched to MobaXterm. It has multi-tab support, and is actually richer in features compared to Windows Terminal.
Please run the following:
alias | grep vim
sudo find / -name .vimrc 2>/dev/null
These commands should show you all the places to check, change the alias or fix the .vimrc files found.
Do you find it always going into edit mode, when you vim a file directly and when you use vim as the git commit editor for example?
EDIT:
You could also try which -a vim or whereis vim to see if you have multiple versions. Or failing that sudo find / -name vim 2>/dev/null
here is a better solution. I downloaded the binary.
https://github.com/lxhillwind/vim-bin/releases/tag/v9.0.0978
Put the vim command in /usr/bin/vi
Put the runtime in:
/usr/local/share/vim/runtim
sudo apt remove vim vim-common vim-runtime vim-tiny
sudo apt purge vim vim-common vim-doc vim-runtime vim-tiny
The second line actually gets rid of residual-defaults.
There is also a defaults.vim someplace on the system. I just nuked it.
I went through and made sure there were no aliases or vi or vim configuration files, but still no luck.
This is a horrible solution, but the only thing that is keeping my sanity right now.
vi -c ":imap jj "
You can alias it in your .bashrc. Looking into better solutions.
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
when checking my $PATH on ubuntu (16.04)
I get a long list of directories, few of which even do not exist in my file
system, and some of them I just don't need:
echo $PATH
.../usr/games:/usr/local/games:/snap/bin
where they are created and how can I remove them?
I wnant to control the creation of the $PATH, rather than
correct it later by the tricks described in
https://unix.stackexchange.com/questions/108873/removing-a-directory-from-path
Some typical places where $PATH can be set when starting up a bash shell on Ubuntu include:
/etc/profile
~/.profile
~/.bashrc
where ~ represents your home directory.
Also look at any scripts called by those scripts.
There may be other things that get called when starting up a bash shell, depending on various conditions. For details, take a look at the INVOCATION section from the command:
$ man bash
See this answer from askubuntu.com to edit the path either using a text editor or the command line.
I found the answer to your question today. The path you want to edit is in /etc/environment.