Where shall I put my scripts?

C

crusoe

Guest
Hello, I'm new to linux. I have read the FHS, but still confused with something. One is where shall i put my shell scripts? under /usr/local/bin or create a bin/ directory under my home and put my scripts here?

My understand of /usr is user shared bla bla, but it still contains system wide files. FHS says "/usr should be shareable between various FHS-compliant hosts and must not be written to." Does hosts here means different users? Can I put my files or install app under /usr?
 


Hello, I'm new to linux. I have read the FHS, but still confused with something. One is where shall i put my shell scripts? under /usr/local/bin or create a bin/ directory under my home and put my scripts here?

My understand of /usr is user shared bla bla, but it still contains system wide files. FHS says "/usr should be shareable between various FHS-compliant hosts and must not be written to." Does hosts here means different users? Can I put my files or install app under /usr?

You can place your scripts under /usr/bin/

Games belong in /usr/games/

You asked in the correct thread. It takes time before someone who knows the answer logins in. General rule of forums - no thread bumping.
 
You can place your scripts under /usr/bin/

Games belong in /usr/games/

You asked in the correct thread. It takes time before someone who knows the answer logins in. General rule of forums - no thread bumping.

It helps a lot, I want to know the best way / conventions to do these stuff and make my system clean. Thanks for your reply:)
 
If you are writing scripts for your own use (not for general use by any/all potential users of your computer) then put them in a directory in home, and change your bash .profile (or the profile/rc/etc of whatever shell you are using) to add that directory to your path. That way, you can use them from any directory, without having to specify the path, since it's in your default $PATH
 
It's best to never put anything under /usr (except for /usr/local) because that could conflict with your distro's files. Each Linux distro guarantees that none of it's packages have conflicting filenames, but they can't prevent conflicts with you. (A host is always a computer or virtual computer, never a user.)

The disadvantage of /usr/local/bin is that by default, it's contents are owned by root. So you have to use su or sudo to edit files there. A minor advantage is also that by default, it's contents are owned by root. So that nothing you run as a regular user can modify or corrupt scripts there.

My preference is to put almost all my own scripts in $HOME/bin. My $HOME/.bashrc file makes sure that directory is first in my PATH.
 
It's best to never put anything under /usr (except for /usr/local) because that could conflict with your distro's files. Each Linux distro guarantees that none of it's packages have conflicting filenames, but they can't prevent conflicts with you. (A host is always a computer or virtual computer, never a user.)

The disadvantage of /usr/local/bin is that by default, it's contents are owned by root. So you have to use su or sudo to edit files there. A minor advantage is also that by default, it's contents are owned by root. So that nothing you run as a regular user can modify or corrupt scripts there.

My preference is to put almost all my own scripts in $HOME/bin. My $HOME/.bashrc file makes sure that directory is first in my PATH.
you are right, I found there are thousands scripts in /usr/bin. FHS says "/usr/bin : Most user commands", there the user still means computer?
 
The /usr/local structure is the best place for any user installed files - as a general rule distribution files should not touch it. If you build anything from source with autotools or cmake, /usr/local should be the target rather than /usr

There is also /opt but /usr/local is preferable (in fact I've never really seen the point in /opt, but I expect there is one)

/usr/bin contains distribution files (i.e. files which belong to packages and may be overwritten by them when you use the package manager to install/remove/upgrade).

The idea of having user scripts in your ~ directory seems a bit 'unclean' to me. Once created, you don't really want those scripts to be edited or changed by someone at user level. If scripts in your ~ will require elevated privileges, it's certainly a bad idea. If you don't want certain users to execute those scripts, you can easily create a 'myscripts' user group and only allow those in the group to execute.

If they're just scripts for working within ~, i.e. for organising downloaded photos, etc, then it's not really an issue.
 
Well, if you don't want other users editing or running the scripts, set permissions to 700. Problem solved.
 
The /usr/local structure is the best place for any user installed files - as a general rule distribution files should not touch it. If you build anything from source with autotools or cmake, /usr/local should be the target rather than /usr

There is also /opt but /usr/local is preferable (in fact I've never really seen the point in /opt, but I expect there is one)

/usr/bin contains distribution files (i.e. files which belong to packages and may be overwritten by them when you use the package manager to install/remove/upgrade).

The idea of having user scripts in your ~ directory seems a bit 'unclean' to me. Once created, you don't really want those scripts to be edited or changed by someone at user level. If scripts in your ~ will require elevated privileges, it's certainly a bad idea. If you don't want certain users to execute those scripts, you can easily create a 'myscripts' user group and only allow those in the group to execute.

If they're just scripts for working within ~, i.e. for organising downloaded photos, etc, then it's not really an issue.

You make me finally figure out the difference between these stuff, not only how but why. Thanks.
 
FHS says "/usr/bin : Most user commands", there the user still means computer?
It means user as opposed to superuser (administrator). For example, you'll find the fsck command in /usr/sbin, not in /usr/bin , because it's not a command mere users should execute. Of course, on a single-user PC, the point is moot.

The idea of having user scripts in your ~ directory seems a bit 'unclean' to me. ... If you don't want certain users to execute those scripts, ...
I'm assuming we're talking about Linux installed on a PC that will have only one user or only users that trust each other (like a family).
 
I like to put in my scripts in /opt/scripts directory. After I have them there I do an rsync to an NFS share as a backup should something happen to my system.

Kovax
 
It means user as opposed to superuser (administrator). For example, you'll find the fsck command in /usr/sbin, not in /usr/bin , because it's not a command mere users should execute. Of course, on a single-user PC, the point is moot..

Actually, the point isn't moot. The point for making certain commands super-user only is several-fold. First, privilege separation goes a long way towards keeping malicious software in check. If commands that can affect software are root-only, then it's harder for a trojan to access them. Second, making these commands root-only should be a signal to you to think twice before using.

(fsck is of course a special case, being somewhat like using a circular saw without a blade guard - don't run it on a mounted file system.)
 
Where I work we standardized on /usr/local/bin/scripts. That way any script that we create/use is always in the same place. Here soon that will become an NFS mount and it will be even easier.
 

Members online


Top