Best directory to put my own scripts in...??

WhisperiN · 11-07-2009, 04:49 AM

Hello fellows,
I hope my question is not a silly one.

Usually, I write my own shell scripts that do various jobs.. blah blah.

I always wounder about the perfect directory to move the script to after I'm done writing it.
So, I used to move it to /bin

But, in fact, I don't really know what's the different and where is the perfect place to put it in..

Is it /sbin ?
Is it /usr/local/bin
or /usr/local/sbin ?
Or It Doesn't matter at all..!!

And also, what are the differences between those directories..?

Thanks in advance..

tredegar · 11-07-2009, 04:53 AM

sbin is usually for commands that must be run as root, the superuser
/usr/local/bin is a good place for your personal commands / scripts

ghostdog74 · 11-07-2009, 05:16 AM

don't put your personal scripts in any of the common mountpoints like /usr , /etc etc... put them in a designated directory that you created yourself.

tredegar · 11-07-2009, 05:56 AM

Quote:

put them in a designated directory that you created yourself.

If you are going to do that, don't forget to update your $PATH to include the new directory.

catkin · 11-07-2009, 06:01 AM

The Linux Filesystem Hierarchy has good descriptions of what directories are for.

In case it helps, I put:

distro-specific scripts in ~/bin
non-distro-specific scripts in ~/d/bin (~/d is a separate file system, containing all personal non-distro-specific files)
experimental, exploratory scripts in ~/d/bin/try
backup script in /opt/MyBackup

WhisperiN · 11-07-2009, 07:49 AM

Quote:

Originally Posted by tredegar

If you are going to do that, don't forget to update your $PATH to include the new directory.

This looks great for me, but would you be so kind to let me know how can I update my $PATH?

Regards..

pcunix · 11-07-2009, 07:53 AM

The problem is that if you choose a decent name for your script, an upgrade might include something with the same name, which will either overwrite your command or at best cause confusion.

I suggest that you put your home grown scripts in your own directory structure: /usr/mystuff/bin or whatever, and further that you NEVER assume that it is in $PATH in calling scripts, but rather call it explicitly: /usr/mystuff/bin/whatever. This prevents the theft of "whatever" by another set of programs, and if some person upgrades the server years from now when you are long gone, and does not notice /usr/mystuff/bin, the calling scripts failure will immediately point them to the remedy. It's fine to have your special place in $PATH; just be sure to be explicit in any other scripts you write.

I wrote that at http://aplawrence.com/Opinion/religion.html a long time ago, but my opinions haven't changed.

I like "/my_monkeys_play_here" , by the way.

pcunix · 11-07-2009, 07:55 AM

Quote:

Originally Posted by WhisperiN

This looks great for me, but would you be so kind to let me know how can I update my $PATH?

Regards..

Find your PATH being set in your startup files (probably .bash_profile).

You can just edit the line, but I prefer to make it easy to spot, so I add a new line:

PATH=$PATH:/my_monkeys_play_here

jlinkels · 11-07-2009, 08:51 AM

The arguments of not putting scripts is /usr/local/bin are valid. Good that people think about it and write it down.

However, even with putting the scripts in another directory anywhere else but in /home/yourname/.... immediately put you in the backup problem anyway. But putting the scripts somewhere below the home directory causes a problem to make them available system-wide.

So far I have been putting my scripts in /usr/local/bin/<projectname> and call them by the full path. But whenever I migrate the system to new hardware I usually miss some of these files. That might have to do with my policy to upgrade servers. I hardly ever upgrade a running production server. I rather do a new install, configure the applications, move the data, bring the old server down and bring the new server up. But it wouldn't be the first time that I forget some files in the /usr/local/bin tree and notice that days afterwards when cron jobs fail or something.

What I also tried for one project (which has a web based user interface) is to put all files related to the project in the /var/www/<project> tree. I consider /var/www volatile, but I have the complete tree on my development system (and subsequently in SVN). This tree includes all scripts, php, tcl, bash, awk etc. Althought the files are used by the project, they can freely be called from anywhere as they are world readable and executable. I must say that this is the best solution so far, but it is not really suitable for single scripts not belonging to a project.

What I have been thinking about also is to put scripts in a designated directory in the file server all my Linux machines connect to. My file server gets backed up, whereas my client machines are not. This directory is not /usr/bin/local/... something for the abovementioned reasons, but somewhere in the user data tree. That path is not included in the $PATH, but why should it? Calling it by the full path name is not difficult if you have file name completion with <tab> and when the command is often used you find it in the history buffer anyway.

jlinkels

WhisperiN · 11-07-2009, 08:59 AM

Quote:

Originally Posted by pcunix

Find your PATH being set in your startup files (probably .bash_profile).

You can just edit the line, but I prefer to make it easy to spot, so I add a new line:

PATH=$PATH:/my_monkeys_play_here

Great..!!

Thanks a lot..

By the way, I liked this:

http://aplawrence.com/Unixart/chmod-777.html

I went hahaha when I did read it..
I gotta confess, your website is a treasure..!!

catkin · 11-07-2009, 09:34 AM

Quote:

Originally Posted by pcunix

Find your PATH being set in your startup files (probably .bash_profile).

You can just edit the line, but I prefer to make it easy to spot, so I add a new line:

PATH=$PATH:/my_monkeys_play_here

Or, being cautious in case there is a directory including whitespace in its name

Code:

PATH="$PATH:/my_monkeys_play_here"

pcunix · 11-07-2009, 11:58 AM

Quote:

Originally Posted by catkin

Or, being cautious in case there is a directory including whitespace in its name

Code:

PATH="$PATH:/my_monkeys_play_here"

Yes, but:

It wouldn't matter if PATH already had spaces in it:

$ foo="A SPACE"
$ foo=$foo:more
$ echo $foo
A SPACE:more

and no sensible person would ever allow such a thing on their system anyway :-)

catkin · 11-07-2009, 12:24 PM

Quote:

Originally Posted by pcunix

Yes, but:

It wouldn't matter if PATH already had spaces in it:

$ foo="A SPACE"
$ foo=$foo:more
$ echo $foo
A SPACE:more

and no sensible person would ever allow such a thing on their system anyway :-)

You are absolutely right (about both it working as expected and "no sensible person would ever allow such a thing on their system anyway"

This shows the same as your post but sets us up for the next code snippet

Code:

c:~$ x='/usr/bin:/usr/local/whereto find things'
c:~$ x=$x:/another_dir
c:~$ echo $x
/usr/bin:/usr/local/whereto find things:/another_dir

I expected that to have the same effect as

Code:

c:~$ x=/usr/bin:/usr/local/whereto find things:/another_dir
find: `things:': No such file or directory

Truely the shell's parsing and substitution order takes a lot of mastering (I figure I forget it faster than I learn it!)

pcunix · 11-07-2009, 12:38 PM

Quote:

Originally Posted by catkin

Truely the shell's parsing and substitution order takes a lot of mastering (I figure I forget it faster than I learn it!)

You are preaching to the choir :-)

Not only do I forget it, but I don't trust anything I remember. I work on so many different operating systems, with so many different shells - and of course there are some major differences between different version levels of even plain old Bash.

I'm very apt to use Bash test operators wrong because I've been doing a lot of Perl recently and vice-versa. I find myself more and more often second-guessing myself: does it really work that way? I better build a test harness and throw some data at it (not that doing that is a bad idea, but I find myself doing it for the simplest and silliest things!)

I therefore tend toward simple and old. People will look at stuff Iwrote and say "Well, you could have...". Yeah, I know, I *could* have. But I couldn't remember if that would work in old Bash or sh on an old Unix box, so I didn't. I wrote it dumb and stupid so it would probably work anywhere.

I guess we are OT :-)

WhisperiN · 11-08-2009, 03:58 AM

Quote:

Originally Posted by jlinkels

Calling it by the full path name is not difficult if you have file name completion with <tab> and when the command is often used you find it in the history buffer anyway.
jlinkels

It's the first time I find about this <tab> thing.. whoowaa..
Thanks for the info..