Manual files in Linux are stored in /usr/share/man. Before, my application could only be installed by a root user and it put the manual files in this directory. Now, I want to enable non-root installation; to achieve this, all my data and configuration files will be installed under ~/<appname>/. However, manual files copied to home will no longer be accessible by man command.
What are the usual workarounds to this problem?
I've thought in creating a "man" command in my application that runs man -M /<man_path>/<appname>/ (as this is easier to users than running the command by themselves). Is this a good option?
Thanks in advance.
[spatel#ap4004 appname]$ export MANPATH=/home/spatel/appname/man
[spatel#ap4004 appname]$ manpath
/home/spatel/appname/man/en:/home/spatel/appname/man
Other workaround is command alias
[spatel#ap4004 appname]$ alias man='man -M /home/spatel/appname/man'
[spatel#ap4004 appname]$ alias man
alias man='man -M /home/spatel/appname/man'
You'll need to use manpath command.
man has new behaviour by default (at least on Fedora 14 and on) that it searches in paths corresponding to PATH environment variable, i.e. for PATH=/xyz/bin it searches /xyz/bin/man, /xyz/share/man and other nearby places. Unless MANPATH is set.
You need to unset MANPATH at the end of your .bash_profile, some startup scripts in /etc may set it to spite you.
If you don't specify an explicit path list with -M or MANPATH, man develops its own path list based on the contents of the configuration file /etc/man.config. The MANPATH statements in the configuration file identify particular directories to include in the search path.
Furthermore, the MANPATH_MAP statements add to the search path depending on your command search path (i.e. your PATH environment variable). For each directory that may be in the command search path, a MANPATH_MAP statement specifies a directory that should be added to the search path for manual page files. man looks at the PATH variable and adds the corresponding directories to the manual page file search path. Thus, with the proper use of MANPATH_MAP, when you issue the command man xyz, you get a manual page for the program that would run if you issued the command xyz.
In addition, for each directory in the command search path (we'll call it a "command directory") for which you do not have a MANPATH_MAP statement, man automatically looks for a manual page directory "nearby" namely as a subdirectory in the command directory itself or in the parent directory of the command directory.
You can disable the automatic "nearby" searches by including a NOAUTOPATH statement in /etc/man.config.
Related
When ever I log into Linux I usually go straight to the same folder i was wondering if in stead of typing in:
$cd Document/..../..../..../..../....
I could create an executable so I could just type ./csFolder and it would go straight there.
You can add a shell function in your .bashrc and restart your terminal:
csf() {
cd Document/..../..../..../..../....
}
Whenever you want to go to that directory, you just run csf.
Yo can do a symlink
ln -s /path/to/file /path/to/symlink
In addition to the other options (though if you use the function/alias option you want to use an absolute path to the target directory so it works from wherever you happen to be) you can use the environment variable CDPATH to help with this if you have a location you often go to from various other locations.
From the POSIX specification:
CDPATH
A -separated list of pathnames that refer to directories. The cd utility shall use this list in its attempt to change the directory, as described in the DESCRIPTION. An empty string in place of a directory pathname represents the current directory. If CDPATH is not set, it shall be treated as if it were an empty string.
Which means that if you set CDPATH to the parent of your target directory you can just use cd dirname from anywhere and go directly to the directory you wanted to be in.
At first I had
touch $NAME_OF_FILE$DATE.$FILE_EXT
then I changed it to
PATH="Logs/"
touch $PATH$NAME_OF_FILE$DATE.$FILE_EXT
The file is created correctly in the folder, however only echos are being printed in there because says commands are not found like grep, awk, and others.
EDIT: The folder is already created on my desktop
Thanks
Alan
PATH is an environment variable that specifies where executables are located and is used by your shell to look for commands executables (grep, awk, ...). You should not override it in your script.
Try:
MYPATH="Logs/"
touch $MYPATH$NAME_OF_FILE$DATE.$FILE_EXT
To understand what PATH is open a shell and type echo $PATH. You will see it contains the directories where your commands executables are.
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 have a file called x.sh that I want to execute. If I run:
x.sh
then I get:
x.sh: command not found
If I run:
./x.sh
then it runs correctly. Why do I have to type in ./ first?
Because the current directory is not into the PATH environment variable by default, and executables without a path qualification are searched only inside the directory specified by PATH. You can change this behavior by adding . to the end of PATH, but it's not common practice, you'll just get used to this UNIXism.
The idea behind this is that, if executables were searched first inside the current directory, a malicious user could put inside his home directory an executable named e.g. ls or grep or some other commonly used command, tricking the administrator to use it, maybe with superuser powers. On the other hand, this problem is not much felt if you put . at the end of PATH, since in that case the system directories are searched first.
But: our malicious user could still create his dangerous scripts named as common typos of often used commands, e.g. sl for ls (protip: bind it to Steam Locomotive and you won't be tricked anyway :D).
So you see that it's still better to be safe that, if you type an executable name without a path qualification, you are sure you're running something from system directories (and thus supposedly safe).
Because the current directory is normally not included in the default PATH, for security reasons: by NOT looking in the current directory all kinds of nastiness that could be caused by planting a malicious program with the name of a legitimate utility can be avoided. As an example, imagine someone manages to plant a script called ls in your directory, and that script executes rm *.
If you wish to include the current directory in your path, and you're using bash as your default shell, you can add the path via your ~/.bashrc file.
export PATH=$PATH:.
Based on the explanation above, the risk posed by rogue programs is reduced by looking in . last, so all well known legitimate programs will be found before . is checked.
You could also modify the systemwide settings via /etc/profile but that's probably not a good idea.
Because current directory is not in PATH (unlike cmd in Windows). It is a security feature so that malicious scripts in your current directory are not accidentally run.
Though it is not advisable, to satisfy curiosity, you can add . to the PATH and then you will see that x.sh will work.
If you don't explicitly specify a directory then the shell searches through the directories listed in your $PATH for the named executable. If your $PATH does not include . then the current directory is not searched.
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
This is on purpose. If the current directory were searched then the command you type could potentially change based on what directory you're in. This would allow a malicious user to place a binary named ls or cp into directories you frequent and trick you into running a different program.
$ cat /tmp/ls
rm -rf ~/*
$ cd /tmp
$ ls
*kaboom*
I strongly recommend you not add . to your $PATH. You will quickly get used to typing ./, it's no big deal.
You can't execute your file by typing simply
x.sh
because the present working directory isn't in your $PATH. To see your present working directory, type
$ pwd
To see your $PATH, type
$ echo $PATH
To add the current directory to your $PATH for this session, type
$ PATH=$PATH:.
To add it permanently, edit the file .profile in your home directory.
I just installed Cygwin, and it looks like the home directory in the bash prompt is on my Z: drive. That's not where I want it.
How can I change this?
Starting with Cygwin 1.7.34, the recommended way to do this is to add a custom db_home setting to /etc/nsswitch.conf. A common wish when doing this is to make your Cygwin home directory equal to your Windows user profile directory. This setting will do that:
db_home: windows
Or, equivalently:
db_home: /%H
You need to use the latter form if you want some variation on this scheme, such as to segregate your Cygwin home files into a subdirectory of your Windows user profile directory:
db_home: /%H/cygwin
There are several other alternative schemes for the windows option plus several other % tokens you can use instead of %H or in addition to it. See the nsswitch.conf syntax description in the Cygwin User Guide for details.
If you installed Cygwin prior to 1.7.34 or have run its mkpasswd utility so that you have an /etc/passwd file, you can change your Cygwin home directory by editing your user's entry in that file. Your home directory is the second-to-last element on your user's line in /etc/passwd.¹
Whichever way you do it, this causes the HOME environment variable to be set during shell startup.²
See this FAQ item for more on the topic.
Footnotes:
Consider moving /etc/passwd and /etc/group out of the way in order to use the new SAM/AD-based mechanism instead.
While it is possible to simply set %HOME% via the Control Panel, it is officially discouraged. Not only does it unceremoniously override the above mechanisms, it doesn't always work, such as when running shell scripts via cron.
Cygwin 1.7.34+
For those using Cygwin 1.7.34 or higher Cygwin supports configuring how to fetch home directory, login shell, and gecos information in /etc/nsswitch.conf. This is detailed in the Cygwin User Guide section:
Cygwin user names, home dirs, login shells
If you've previously created an /etc/passwd or /etc/group file you'll want to remove those and configure Cygwin using the new Windows Security model to POSIX mappings.
[[ -f /etc/passwd ]] && mv /etc/passwd /etc/passwd.bak
[[ -f /etc/group ]] && mv /etc/group /etc/group.bak
The /etc/nsswitch.conf file's db_home: setting defines how Cygwin fetches the user's home directory. The default setting for db_home: is
db_home: /home/%U
So by default, Cygwin just sets the home dir to /home/$USERNAME. You can change that though to point at any other custom path you want. The supported wildcard characters are:
%u The Cygwin username (that's lowercase u).
%U The Windows username (that's uppercase U).
%D Windows domain in NetBIOS style.
%H Windows home directory in POSIX style. Note that, for the db_home: setting, this only makes sense right after the preceeding slash, as in db_home: /%H/cygwin
%_ Since space and TAB characters are used to separate the schemata, a space in the filename has to be given as %_ (that's an underscore).
%% A per-cent character.
In place of a path, you can specify one of four named path schemata that are predefined.
windows The user's home directory is set to the same directory which is used as Windows home directory, typically something along the lines of %USERPROFILE% or C:\Users\$USERNAME. Of course, the Windows directory is converted to POSIX-style by Cygwin.
cygwin AD only: The user's home directory is set to the POSIX path given in the cygwinHome attribute from the cygwinUser auxiliary class. See also the section called “The cygwin schema”.
unix AD only: The user's home directory is set to the POSIX path given in the unixHomeDirectory attribute from the posixAccount auxiliary class. See also the section called “The unix schema”.
desc The user's home directory is set to the POSIX path given in the home="..." XML-alike setting in the user's description attribute in SAM or AD. See the section called “The desc schema” for a detailed description.
The following will make the user's home directory in Cygwin the same as is used for the Windows home directory.
db_home: windows
Cygwin 1.7.33 or earlier
For those using Cygwin 1.7.33 or earlier, update to the latest version Cygwin and remove previously used /etc/passwd and /etc/group files, then see the steps above.
Else, follow these older steps below.
Firstly, set a Windows environment variable for HOME that points to your user profile:
Open System on the Control Panel
On the Advanced tab click Environment Variables (toward the bottom)
In the User Variables area click "New…"
For Variable name enter HOME
For Variable value enter %USERPROFILE%
Click OK in all the open dialog boxes to apply this new setting
Now we are going to update the Cygwin /etc/passwd file with the Windows %HOME% variable we just created. Shell logins and remote logins via ssh will rely on /etc/passwd to tell them the location of the user's $HOME path.
At the Cygwin bash command prompt type the following:
cp /etc/passwd /etc/passwd.bak
mkpasswd -l -p $(cygpath -H) > /etc/passwd
mkpasswd -d -p $(cygpath -H) >> /etc/passwd
The -d switch tells mkpasswd to include DOMAIN users, while -l is to only output LOCAL machine users. This is important if you're using a PC at work where the user information is obtained from a Windows Domain Controller.
Now, you can also do the same for groups, though this is not necessary unless you will be using a computer that is part of a Windows Domain. Cygwin reads group information from the Windows account databases, but you can add an /etc/group file if your machine is often disconnected from its Domain Controller.
At the Cygwin bash prompt type the following:
cp /etc/group /etc/group.bak
mkgroup -l > /etc/group
mkgroup -d >> /etc/group
Now, exit Cygwin and start it up again. You should find that your HOME path points to the same location as your Windows User Profile -- i.e. /cygdrive/c/Users/username
I did something quite simple. I did not want to change the windows 7 environment variable. So I directly edited the Cygwin.bat file.
#echo off
SETLOCAL
set HOME=C:\path\to\home
C:
chdir C:\apps\cygwin\bin
bash --login -i
ENDLOCAL
This just starts the local shell with this home directory; that is what I wanted. I am not going to remotely access this, so this worked for me.
Cygwin mount now support bind method which lets you mount a directory. Hence you can simply add the following line to /etc/fstab, then restart your shell:
c:/Users /home none bind 0 0
Change your HOME environment variable.
on XP, its right-click My Computer >> Properties >> Advanced >> Environment Variables >> User Variables for >> [select variable HOME] >> edit
I'd like to add a correction/update to the bit about $HOME taking precedence. The home directory in /etc/passwd takes precedence over everything.
I'm a long time Cygwin user and I just did a clean install of Windows 7 x64 and Cygwin V1.126. I was going nuts trying to figure out why every time I ran ssh I kept getting:
e:\>ssh foo.bar.com
Could not create directory '/home/dhaynes/.ssh'.
The authenticity of host 'foo.bar.com (10.66.19.19)' can't be established.
...
I add the HOME=c:\users\dhaynes definition in the Windows environment but still it kept trying to create '/home/dhaynes'. I tried every combo I could including setting HOME to /cygdrive/c/users/dhaynes. Googled for the error message, could not find anything, couldn't find anything on the cygwin site. I use cygwin from cmd.exe, not bash.exe but the problem was present in both.
I finally realized that the home directory in /etc/passwd was taking precedence over the $HOME environment variable. I simple re-ran 'mkpasswd -l >/etc/passwd' and that updated the home directory, now all is well with ssh.
That may be obvious to linux types with sysadmin experience but for those of us who primarily use Windows it's a bit obscure.
I happen to use cwRsync (Cygwin + Rsync for Windows) where cygwin comes bundled, and I couldn't find /etc/passwd.
And it kept saying
Could not create directory '/home/username/.ssh'.
...
Failed to add the host to the list of known hosts (/home/username/.ssh/known_hosts).
So I wrote a batch file which changed the HOME variable before running rsync. Something like:
set HOME=.
rsync /path1 user#host:/path2
And voila! The .ssh folder appeared in the current working dir, and rsync stopped annoying with rsa fingerprints.
It's a quick hotfix, but later you should change HOME to a more secure location.