Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
In the linux file system, where should user scripts be placed?
I'm thinking specifically python scripts to be called by cron.
the information i got:
/usr/local/sbin custom script meant for root
/usr/local/bin custom script meant for all users including non-root
chatlog snips from irc.debian.org #debian:
(02:48:49) c33s: question: where is the _correct_ location, to put custom scripts
for the root user (like a script on a webserver for createing everything needed
for a new webuser)? is it /bin, /usr/local/bin,...? /usr/local/scripts is
mentioned in (*link to this page*)
(02:49:15) Hydroxide: c33s: typically /usr/local/sbin
(02:49:27) Hydroxide: c33s: no idea what /usr/local/scripts would be
(02:49:32) Hydroxide: it's nonstandard
(02:49:53) Hydroxide: if it's a custom script meant for all users including
non-root, then /usr/local/bin
(02:52:43) Hydroxide: c33s: Debian follows the Filesystem Hierarchy Standard,
with a very small number of exceptions, which is online in several formats at
http://www.pathname.com/fhs/ (also linked from http://www.debian.org/devel/ and
separately online at http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html)
(02:53:03) Hydroxide: c33s: if you have the debian-policy package installed, it's
also in several formats at /usr/share/doc/debian-policy/fhs/ on your system
(02:53:37) Hydroxide: c33s: most linux distributions follow that standard, though
usually less strictly and with more deviations than Debian.
thanks go out to Hydroxide
If you're talking about scripts created by a user that will be run from that users crontab, I typically put those in either a bin or scripts folder in the home directory, or if they're intended to be shared between users, a /usr/local/scripts directory.
For whom it interests, the Filesystem Hierarchy Standard (FHS) is a standards document and still a very good read. I describes the foundation for almost any Linux distribution and is officially endorsed e.g. by Debian and the Linux Standards Base (LSB).
You won't find any positive answer for that question, though, since ... it's not defined ;-). Only thing I can say: Don't put in /bin (neither in /usr/bin). /usr/local/scripts is unusual as well. $HOME/bin seems to be an acceptable place, iff the script is only used by this single user.
I'm a strong beleiver that if a file is made by a user, it goes in his user directory (/home/username) if he didn't make it then it gets more complicated. I have in the past just put them in either /usr/local/bin, /bin, or /usr/local/scripts, I'm not sure about etch, but you need to check to make sure that /usr/local/scripts is actually in Cron's $PATH.
The Debian guide can be quite useful when it comes to Ubuntu:
Normally, programs install themselves in the /usr/local subdirectories. But, Debian packages must not use that directory, since it is reserved for system administrator's (or user's) private use
/usr/local/bin seems to be acceptable according to the guide.
Personally I put my scripts in $HOME/.scripts.
I wish that LSB would specifically address this question though.
How about /home/username/bin?
Add ~/bin to $PATH and make the script executable with chmod +x filename.
personally I prefer
/home/username/.bin
This way the bin folder is hidden but you can still add it to the PATH and execute all scripts with the x-bit inside.
I like my home directory to be clean (at first glance) with very few folders.
You can also add paths to your crontab file as shown in a previous cron-related question.
Related
I’m not root for the linux server,
so I choose to install softwares in my $HOME/local/bin, I already added the $HOME/local/bin directory to the PATH environment variable, wrote in my .bashrc.
Some softwares install this way like:
tar xvzf ncurses-5.9.tar.gz
cd ncurses-5.9
./configure --prefix=$HOME/local
make
make install
cd ..
So it will directly install in my $HOME/local/bin.
But for some softwares, after download like sbt-1.2.1.zip (based on java), and decompression, shows just a file fold sbt, it contains three foldsbin conf lib, and in its bin, contains one executable file named sbt and java9-rt-export.jar sbt-launch-lib.bash sbt-launch.jar sbt.bat.
Here I wonder:
I should just soft link this executable sbt file path under my $HOME/local/bin, then source my .bashrc?
Or, after decompression, add one line in my .bashrc export PATH="downloadpath/sbt/bin:$PATH"?
Since just one executable downloadpath/sbt/bin, so I'm not sure it is right to add whole bin fold path, if software's bin fold contains executable files (one or many), I think this situation is more convenient for just add it's bin in .bashrc, but even so, I'm not sure its right?
I'm not familiar with installation software, now I usually know way
but not why. Here I shows two ways (more ways not be showed here) to
install, executable file always be written in bin or src? But some
softwares no bin just src but no executable files in it...
Slurm also can use modules to install software, conda also other way, but I want to
confirm these traditional ways I mentioned (that two) still can be
used on slurm or conda?
However, any suggestion even one aspect's reminding will be grateful!
For precompiled software, or, in general, software that does not offer configure scripts or (C)make files, it is ofter better to leave them in their target directory and adapt the *PATH (PATH to binaries, but also LD_LIBRARY_PATH, LIBRARY_PATH to libraries and CPATH to include files and MANPATH to the man page) environment variables.
The reason is that the software might be configured to read files with hardcoded paths, relative to the position of the executable, such as libraries, etc.
In your case, you might also need to setup the CLASSPATH env variable to the directory with the jar files.
To ease software installation, you can use tools such as easybuild that can help, and even create user modules just like the system module installed by the system administrators.
There is something wrong in my opinion with your setup. If you don`t have root account on your server, is not better to test what you have to test, in a more safe environment - for example a vm/container on your developement machine ?
However, in your situation maybe it can be better to start sbt by using a separate bash script than modifying your .bashrc
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm not a complete beginner with Linux but I'm using Debian to familiarise myself with it for work.
I have a few quick questions:
To run a binary from a terminal, does it have to be in /bin/? What if it has dependencies, must they also go in /bin/?
I'm used to installing things on Windows by clicking 'next' a lot. If I download a .tgz and it contains an .exe along with several folders, exactly how is it installed?
Is uninstalling in Linux as simple as removing the files, or are there registry style devices that must be modified?
I know these will have been asked before but I cannot get good, clear answers written from a noob friendly point of view. Thanks!
To run a binary from a terminal, does it have to be in /bin/? What if it has dependencies, must they also go in /bin/?
To run a binary just run it from the terminal and see if it works. If it has dependencies they will usually be found automatically or check the readme.
I'm used to installing things on Windows by clicking 'next' a lot. If I download a .tgz and it contains an .exe along with several folders, exactly how is it installed?
Try to double click the .tgz file first then extract and view the README.
Is uninstalling in Linux as simple as removing the files, or are there registry style devices that must be modified?
Depends which Linux OS you are using. Ubuntu is very simple and has a simple interface just like Windows for uninstalling apps.
Not every binary will be in /bin or /usr/bin. To run them from the command line you would set the PATH env var to the directory where executables live. For example, if you create a dir /home/users/foo/bin then set the PATH like so:
export PATH=${PATH}:/home/users/foo/bin
After that, you just type the name of the executable into the shell and the full path is found by searching the directories listed in the PATH.
A .tgz should not contain a .exe since that is a Windows specific executable. Typically, executable on Linux do not have an extension.
No, there is no registry under Linux. That specific insanity is only found under Windows.
1) An executable can be anywhere in directories specified in PATH variable, and you also can run an executable from any location by specifying path to it (if it's in current directory, then write ./<exename>).
2-3) Debian has its own package management system, usually software is installed/uninstalled using sudo apt-get install <package> or sudo apt-get remove package (I recommend reading about apt-get and sudo). Instead of Windows registry, there are many small configuration files in Linux, and some software makes changes to them so it should be carefully uninstalled (but Debian package management usually handles these cases well).
If I start a new distro (e.g. LFS):
How can I change the directory structure?
What should I expect after it's ready? (probably can't install most of the packages without modification, right?
But, before you down vote: I've been asked to make a new distro for a specific project which they need (actually, want) a new directory structure with a few changes, for example remove the var and bin directories, but without halting the system. The application of this distro is so limited, so i think it shouldn't be a big deal as they need just a few packages to be installed.
These are few pointers that come to my mind and definitely it is not complete:
Your PATH should be updated in the startup scripts like ~/.bashrc, /etc/profile.d, and so on to reflect the updated directories.
Configuration files tend to use /var quite often. (/var/log, /var/tmp) You'd need to modify all these location references.
Basically your kernel is going to start /sbin/init which is going to start the initialization at /etc/rc.d or equivalent. If you start tracing all the scripts and services invoked in these startup scripts, I believe you should be able to capture all the places you'd need to modify the path names.
you can create a folder called system and the move all the files into the /system folder. and after that create symlinks, so the system can still be used. example:
su -i
cd /
mkdir system
mv /usr /system/usr
ln -s /system/usr /usr
I just did it........it broke my system XD (i think it was because i moved all the files into /system , including /boot witch is used by GRUB)
The chance of breaking the system is huge if you don't have background knowledge. Example if you move /bin to /system/bin, then you won't be able to create the symlink afterwards because the ln command (which is a program) is located in the /bin folder so moving it will end up in an error.
also, check out gobolinux.org which is based around what i just did. The entire system has been reorganized and to maintain compatibility, they have created symlinks so that they don't have to reprogram an app when porting applications.
I am relatively new to Linux and Unix. With the help of the internet I finally figured out how $PATH and aliases in my .bashrc work.
But I really couldn't find anything that describes when to use which.
Let's say I installed Python3.3 in Library/Frameworks and the executable is
/Library/Frameworks/Python.framework/Versions/3.3/bin/python3, but I want to execute python 3.3 just by typing python3 into my terminal.
When I understand it correctly, there are (at least) three methods to achieve this:
1) I modify $PATH in my .bashrc:
export PATH=/Library/Frameworks/Python.framework/Versions/3.3/bin:${PATH}
2) I set an alias in my .bashrc:
alias python3=/Library/Frameworks/Python.framework/Versions/3.3/bin
3) creating a symbolic link (symlink):
ln -s /Library/Frameworks/Python.framework/Versions/3.3/bin /usr/local/bin
What would you say (from your experience) is the "recommended" way?
Putting python3 in your path is the correct way to invoke it anywhere you might find yourself in your filesystem. A symbolic link is the best way to change that command to python and keep your scripts non version dependent (you can run a script that depends on python use the symbolic link and a script that needs python 3.0 specifically use python3, even though on your computer they are the same thing). Symbolic links are still files in your filesystem, so they still need to be in your path.
I only see aliases used when you are trying to create some kind of behavior that is different than the default behavior for a command line utility like an alias for ls that adds -a silently.
Also symbolic links are stored in the filesystem so once created they exist for all other users who log in, while aliases only apply to the logged in user who has defined them. They can also have file permissions applied to them.
Here is a fun article about things you can do to your terminal through your .bash_profile including some great aliases.
First, there is no reason to install Python in a /Library/Frameworks/ directory. My suggestion is that (at least for a beginner) you should not add top level directories like your /Library. If you compile it from source code, you should have built it with a standard ./configure (and it probably goes into /usr/local/)
I don't know well about compiling Python from source code, but most Linux source code gets by default ./configure-d to a /usr/local/ prefix so their binary go into /usr/local/bin/ which is often already by default in your PATH
Some Linux distributions have an /etc/profile which indirectly, if the directory $HOME/bin/ exists, adds it inside your PATH; in that case just adding binaries and scripts (or symbolic links) there is the most simple way.
My general advice is to avoid having a very long or very specific PATH. In particular, adding a directory inside your PATH for each product is IMHO a mistake. See e.g. the directory-variables section of GNU coding standards, and keep your PATH quite short. Personally I add programs only in /usr/local/bin/ (system-wide) or in $HOME/bin/, perhaps as symbolic links (so I don't change my PATH since it already contains both /usr/local/bin/ and $HOME/bin).
By past experience having a very long PATH is a nightmare, and slows down your interactive shells
Thank you all for your explanations.
As I already said, I am pretty new to Unix and Linux. I just wrote an article about those things (aliases, symlinks $PATH) for my blog for other "newbies". I like to write about those things, because they really interest me, and I want to share my experiences - I hope they are helpful to other people, too. Furthermore, it helps me to deepen my understanding if I have to explain things - and it is a good future reference, too!
It would be nice if you could skim over the article very quickly, and if I got some things wrong, I would be very happy about suggestions!
http://scientific-ocean.com/2013/02/17/an-introduction-to-linuxunix-executables-path-aliases-and-symlinks/
I would suggest go for alias which would make it easier for conflicts arising if you different versions of Python. The shell will look up the PATH variable and wherever it matches the executable of Python it will execute it. The alias has to be put in your shell profile like .bash_profile.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Just as a preface, sorry if I am missing something obvious. I am mainly a PHP/Python programmer but am doing server config for a friend's startup.
I only have left to install Apache Ant on my friend's Linux VPS server (he wants to compile Android apps on server- just a note I have already somehow manged to get the JDK and LAMP that would also be necessary).
When I did some digging on how to get Ant, this was all I got that really met my needs: http://ant.apache.org/manual/install.html#jpackage
Can someone give me some kind of push on what to do at all? Maybe a wget with the appropriate link? Anything at all is appreciated.
Thanks in advance to all.
Did you search for the package apache-ant in your RPM database?
If you're not using your RPM for installing packages (and why wouldn't you), you can download Ant directly from Apache. (Note that there are directions for JPackage RPMs too. Just in case you change your mind about not using RPMs.
Ant is a Java program, so you must have a Java JDK installed (Ant will run under the JRE, but you couldn't build Java apps with that), and make sure that the java command is in your Path. However, that also means that there is no special version of the Ant binary for each platform, so it's much easier to install.
Download and extract the Ant archive to a suitable directory (/opt or /usr/local or /usr/lib or whatever standard you're using). Inside the archive, when unpacked, will be a bin directory. Those files under bin are mainly shell scripts (the ones that end with *.bat are Windows Batch files, you can ignore those). Just execute those.
I like to symbolically link those files under Apache-Ant's bin directory to a similar name under /usr/local/bin directory. That way, you don't need to put /usr/local/apache-ant-1.8.3/bin in your $PATH.
And that's really about it.
Just follow the "Short Story" section at the top of the page you referenced:
To get up and running with the binary edition of Ant quickly, follow these steps:
Make sure you have a Java environment installed, See System Requirements for details.
Download Ant. See Binary Edition for details.
Uncompress the downloaded file into a directory.
Set environmental variables JAVA_HOME to your Java environment, ANT_HOME to the directory you uncompressed Ant to, and add ${ANT_HOME}/bin (Unix) or %ANT_HOME%/bin (Windows) to your PATH. See Setup for details.
Optionally, from the ANT_HOME directory run ant -f fetch.xml -Ddest=system to get the library dependencies of most of the Ant tasks that require them. If you don't do this, many of the dependent Ant tasks will not be available. See Optional Tasks for details and other options for the -Ddest parameter.
Optionally, add any desired Antlibs. See Ant Libraries for a list.
Note that the links in the list above will give more details about each of the steps, should you need them. Or you can just continue reading the rest of this document.