To leave the system in a cleaner state, I am trying to remove entries from the PATH in the %preun section of my rpm spec file.
I found couple of threads on stackoverflow that I tried
What is the most elegant way to remove a path from the $PATH variable in Bash?
AND
Linux: Remove path from $PATH variable
Answers in both these links work perfectly when I manually run them on a terminal.
But, they don't work when I run the rpm -e xx command.
If my PATH looked like this after successful installation:
/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/lpp/mmfs/bin
and I am trying to remove /usr/lpp/mmfs/bin,
After the rpm uninstall the PATH looks like:
/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin
Questions:
1) Do I need to do something different when the commands mentioned in the earlier links are run from the spec file?
2) What are some recommended ways to remove PATH entries during rpm uninstalls?
Note
Commands I have tried in spec file are:
PATH=$(echo $PATH | sed -e 's;:\?/home/user/bin;;' -e 's;/home/user/bin:\?;;')
and
PATH=${PATH/:\/home\/user\/bin/}
The RPM %preun script cannot affect the PATH variable of any running shells. That isn't possible.
It can't (directly) affect the PATH variable of any new shells either.
The only thing it can do is remove whatever changes it made to the system (or user shudder) shell startup files that caused the PATH variable additions to be made.
Removing those changes will cause any new shells not to have those changes made and therefore not to have those additional PATH entries in them.
The proper way of adding to a PATH (and subsequently, removing it later), would be to drop a file yourpackage.sh and yourpackage.csh in /etc/profile.d.
I also agree with others that it's probably a bad idea, but if you need to do it, that's how I would.
Related
I've been trying to use fpm to create an rpm, but have ran into a problem. After I install the package, there are files I no longer need which are deleted in a post-install script in order to save space. Unfortunately, when the packages in uninstalled, it complains about the files not being there, as they are still registered by the rpm as part of the package. When I looked into how to fix this via the rpm, I stumbled on the %config(missingok) macro which seems ideal. However, it doesn't seem like there is a way to set this via fpm.
My current options for possible solutions are changing the -edit flag from using vi to edit the spec file to using a script by setting the fpm_editor variable, or touching the file in a pre-remove script to try and trick the rpm into thinking these problematic file still exist. Neither of these option are very appealing.
So my question is this: Is there a way to use fpm to either a: remove the package from the "sight" of the rpm post-install, or b: mark the file as noconfig(missingok) via fpm?
Without utilizing the two solutions above of course.
The usual way of doing this is rm -f these files at the end of the %install section, instead of doing this in the post-install scriptlet.
This way the useless files will not be packaged in the final rpm.
I never packaged an rpm with fpm, but looking at the source code I see the command-line switches --exclude and --exclude-file that should be the ones you're looking for:
option ["-x", "--exclude"], "EXCLUDE_PATTERN",
"Exclude paths matching pattern (shell wildcard globs valid here). " \
"If you have multiple file patterns to exclude, specify this flag " \
"multiple times.", :attribute_name => :excludes do |val|
excludes << val
next excludes
end # -x / --exclude
option "--exclude-file", "EXCLUDE_PATH",
"The path to a file containing a newline-sparated list of "\
"patterns to exclude from input."
I did
brew install python3
when i run python --version it shows 2.7
Document says:
If you still see 2.7 ensure in PATH /usr/local/bin/ takes precedence over /usr/bin/
How do I go about this?
First, you'll want to verify the problem is as stated.
Try running e.g.
> echo $PATH
/usr/local/bin:/Users/jsh/code/go/bin:/usr/bin:/bin:/usr/local/sbin:/usr/texbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
You'll notice that the output is a series of paths separated by ':' characters. Your terminal looks in those locations, in order, until it finds something that matches your command (in this case 'python') and it runs that binary.
This means that earlier items take precedence over later items. You'll note that in my listing, /usr/local/bin/ is at the very beginning, and /usr/bin/ is somewhat later in the listing.
If your listing also has this ordering, you're getting a misleading message, and will need to dig deeper. Hopefully, however, you will find that either /usr/local/bin/ isn't in your list at all, or it is for some reason occurring after /usr/bin/. That's good -- you've now identified the problem -- and we're now at your nominal question, vis: how do you change the ordering?
The environment variable $PATH can be modified by any number of startup tools. There are probably ways to systematically observe all the things that are editing your $PATH, but what I would do is
1) Search in your home directory for things that might be messing with $PATH, something like:
> egrep -d skip -l PATH .*
.gvimrc
.zhistory
.zshrc
.zhistory, here, is a red herring -- it's a list of the stuff I've done in my shell, so I can ignore it.
.gvimrc is also misleading, because it's actually setting $GOPATH, not $PATH.
So the only configuration file I have messing with my $PATH, at least in my home directory, is .zshrc, the config file for my shell itself. This is typically true, and you can just start by assuming this, but it's always good to do a quick search...
2) Edit the responsible file until it is setting PATH so that /usr/bin/local/ precedes /usr/bin/. Open the file in your choice of editor and either modify the line that sets PATH, or add a line that prepends /usr/local/bin/ to PATH (if you go with the latter, make sure that prepend happens after all other modifications to the variable).
For example, my .zshrc has a block like this:
# PATH setup (Starting with hard reset)
export PATH=/sbin
export PATH=/usr/sbin:$PATH
export PATH=/usr/texbin:$PATH
export PATH=/usr/local/sbin:$PATH
export PATH=/bin:$PATH
export PATH=/usr/bin:$PATH
export PATH=/Users/jsh/code/go/bin:$PATH
export PATH=/usr/local/bin:$PATH
(Note that the FINAL LINE is the one prepending /usr/local/bin !)
Then restart your shell (or prompt it to reload the config file, but I'm betting if you knew how to do that, you wouldn't have needed this guidance!). Now re-run 'echo $PATH', and verify that the ordering is correct. If so, try running python again, and you should have an uncle named Bob.
Good luck!
I keep getting errors saying bash command not found, also I am unable to make changes as it asks for root, even though I am an admin and own the laptop.
I was also able to type .. and move up a directory and now I cannot for some reason.
My second issue is I was formerly able to complete commands in terminal using the key but now it does not seem to work.
I must add that my $PATH looks very long and muddled at the moment so this may be an issue.
because your $PATH only contains system admin binary file path, use need to set env like this
export PATH=$PATH:/usr/local/bin
make sure your local binary file is under dir of /usr/local/bin
I want to add a small script to the linux PATH so I don't have to actually run it where it's physically placed on disk.
The script is quite simple is about giving apt-get access through a proxy I made it like this:
#!/bin/bash
array=( $# )
len=${#array[#]}
_args=${array[#]:1:$len}
sudo http_proxy="http://user:password#server:port" apt-get $_args
Then I saved this as apt-proxy.sh, set it to +x (chmod) and everything is working fine when I am in the directory where this file is placed.
My question is : how to add this apt-proxy to PATH so I can actually call it as if it where the real apt-get ? [from anywhere]
Looking for command line only solutions, if you know how to do by GUI its nice, but not what I am looking for.
Try this:
Save the script as apt-proxy (without the .sh extension) in some directory, like ~/bin.
Add ~/bin to your PATH, typing export PATH=$PATH:~/bin
If you need it permanently, add that last line in your ~/.bashrc. If you're using zsh, then add it to ~/.zshrc instead.
Then you can just run apt-proxy with your arguments and it will run anywhere.
Note that if you export the PATH variable in a specific window it won't update in other bash instances.
You want to define that directory to the path variable, not the actual binary e.g.
PATH=$MYDIR:$PATH
where MYDIR is defined as the directory containing your binary e.g.
PATH=/Users/username/bin:$PATH
You should put this in your startup script e.g. .bashrc such that it runs each time a shell process is invoked.
Note that order is important, and the PATH is evaluated such that if a script matching your name is found in an earlier entry in the path variable, then that's the one you'll execute. So you could name your script as apt-get and put it earlier in the path. I wouldn't do that since it's confusing. You may want to investigate shell aliases instead.
I note also that you say it works fine from your current directory. If by that you mean you have the current directory in your path (.) then that's a potential security risk. Someone could put some trojan variant of a common utility (e.g. ls) in a directory, then get you to cd to that directory and run it inadvertently.
As a final step, after following the solution form proposed by #jlhonora (https://stackoverflow.com/a/20054809/6311511), change the permissions of the files in the folder "~/bin". You can use this:
chmod -R 755 ~/bin
make an alias to the executable into the ~/.bash_profile file and then use it from anywhere or you can source the directory containing the executables you need run from anywhere and that will do the trick for you.
adding to #jlhonora
your changes in ~./bashrc or ~./zshrc won't reflect until you do
source ~./zshrc or source ./bashrc , or restart your pc
I'm pretty new to programming for Linux environments, so I don't exactly know what to search for in order to answer this question for myself. I need to understand how applications set the shell to accept a certain command to start them. For example, you can start Firefox from the command line by executing the command: firefox.
I don't know where this is defined. Makefile? Configure script? In the source code itself?
Any resources / reading on Linux programming tidbits like these would be greatly appreciated!
Thank you.
Firefox is launched by the command "firefox" because there is an executable file in one of the folders in the $PATH environment variable called "firefox".
Are you talking about the PATH variable? It seems like you are.
In linux, you should be able to type: "echo $PATH" (without quotes) and get a ":"-separated list of locations where programs are located (like firefox).
If you need to add something to your path, you should be able to do:
export PATH=$PATH:/another/directory
In your shell (which is most likely bash)
You can also type:
which firefox
To display the location of the firefox executable.
Typically the shell is going to have an environment variable called $PATH set. This is just an ordered list of all the directories to look when somebody types in a command. As soon as it finds an executable file (by which I mean a file for which you have execute permissions, not a file ending in .exe) with the same name as whatever was typed, it will run that file. Common directories in $PATH might be /bin, /usr/local/bin, ~/bin, etc.
So, when you type 'firefox', the shell looks through all the directories in $PATH until it finds /usr/local/bin/firefox, which it then runs. To make your own programs run the same way, you'll either need to put them (or a symbolic link to them) in a directory that is likely to be in every user's path (/usr/local/bin/ is a good choice), or you'll need to get your users to add your program's directory to their $PATH.
For a more complete description, see the Wikipedia article about the $PATH variable.
As an alternative to the modification of $PATH mentioned earlier, you could also copy or link your executable in one of the directories already in your $PATH. more specifically, /usr/local/bin/ is available on most UNIX system for pretty much this purpose (installing software outside the default package management of the operating system).
It has to be in the path as everyone else mentioned, but you might also need to make it executable with something like this:
chmod +x /path/to/file
And if it's a script there's usually a shebang at the top that tells the os what to use to execute it:
#! /usr/bin/python
Often, large packages are installed in /opt with a wrapper script or link somewhere in the PATH. For example, on my system, Google Picasa is installed in /opt/google/picasa and there is a symlink at /usr/bin/picasa to /opt/google/picasa/3.0/picasa
Firefox is at /usr/bin/firefox on my system and that's a symlink to /usr/bin/firefox-3.0 which is itself a symlink to /usr/lib/firefox-3.0.11/firefox.sh - That shell file fumbles around until it finally runs /usr/lib/firefox-3.0.11/firefox (unless it finds a reason to do something else). That, finally, is a binary executable. So /usr/lib is where firefox is installed, for me.
You can use this command to find out where a program is:
type -a firefox
Then, you can find out what kind of file it is using this:
file /usr/bin/firefox
Also see the Filesystem Heirarchy Standard for more information about recommended locations for files and programs.