Trying to set up ~/bin directory

It's unix, you can do the same 🙂

Stick em in the bin & chmod them the same as Linux.

I tend to use ~/.bash_profile & ~/.bashrc depending on which way the wind blows.

On 10.6.8 I have (I haven't setup 10.9 yet, but its probably the same)…

$ cat .bashrc

# Add path so that remote shells can see tools!

PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/X11/bin

# System-wide .bashrc file for interactive bash(1) shells.

if [ -z "$PS1" ]; then

   return

fi

PS1='\h:\W \u\$ '

# Make bash check its window size after a process completes

shopt -s checkwinsize

The ~/.bash_profile has the PATH appended too & all the aliases for local shells.

You definitely want to avoid adding to /bin - it's Apples & they may squash you with updates. Go for /usr/local/bin if you want global executables.

The /etc files are default versions, copy them to override ~/ if you want to edit them.

bash only reads ~/.bashrc when you open non-login shell. A new Terminal window opens a login shell, so use ~/.bash_profile.

Another way is to add a file with paths to

/etc/paths.d

sudo nano

/etc/paths.d/

In nano, enter the path: /Users/Tony/bin

^O, [enter]

^X

Exit Terminal, Open a new Terminal window, and check with: echo $PATH

nano will look like:

Contents of my .bash_profile:

[[ -s ~/.bashrc ]] && source ~/.bashrc

All the good stuff is in my ~/.bashrc, including the following line:

export PATH=.:~/bin:$PATH

Tony T1 wrote:

Another (easier, better) way is to add a file with paths to

/etc/paths.d

Doesn't that add a single users search path to every user on the system?

Since you have to create bin/ in your home folder the default permissions will allow all other user to read into it. It strikes me as bordering on unexpected behavior?

OS X is multi user, so shouldn't each users environmental variables like search paths be independant?

If you want system level executables isn't that the whole point of storing them in /usr/local? You can simply add that path which ever /etc/file is most appropriate (bashrc, paths.d, bash_profile…).

For the most part I don't think this is an issue, until you try setting it up in a school or true multiuser environment, but I dont think it is best practice. Otherwise I could just drop a script called 'cd' into my ~/bin & annoy every other Terminal user on the system (assuming the search path picks up my ~/bin/cd before the system /usr/bin/cd).

Good point 😊

Better to add the path to: ~/.bash_profile

Thank heavens, I thought I had gone off on a tangent.

🙂

Just remember that it is not Ubuntu. The Mac is a different philosophy. Apple handles all of the system directories. You stay out of those unless you are willing to re-apply your changes after each update. The /etc/paths.d location is a neat trick, but I never use it. I find it better to run everything out of a user account. If you need something to be stand-alone, then make it stand-alone. Don't try to modify the system.

Always use ~ or $HOME. That will work on all platforms and will make your scripts more portable.

I'm sure this has been said elsewhere already, but thanks for making etrecheck.

🙂

It's so handy for getting an overview, if it could go into the App Store it would be perfect, some users refuse to download apps from the web so they don't get help.

I can't direct message you so apologies to the other users in this thread.

(I'm referring to - http://www.etresoft.com/etrecheck - see what your OS is running).

It would be a pain to put all of my scripts in /bin folder and chmod o+w myScript.sh. I also feel like that is bad practice. Any help would be greatly appreciated.

Personally, I don't have a $HOME/bin. I develop scripts in my home folder then install them in /usr/local/bin. If I need to modify a script then I do that in my home folder then install the modified script in /usr/local/bin.

I actually have a $HOME/local/bin. :-)

In a corporate setting, I run into development systems where my home directory is NFS mounted and the systems I connect to have their own NFS mounted /usr/local/bin, so I cannot add stuff to them.

If I want an open source package not provided by the IT group (current versions of Vim, bash, …), I can not use /usr/local/bin, so I need local/bin, local/lib, local/src, … place of my own.

Things get a little more complicated, for executables, as I often bounce between Linux, Solaris SPARC, Solaris x86, and AIX systems. For this situation I have a local/arch/…/bin where my .bash_profile constructs my PATH with the correct 'arch' path for the type of machine I'm running on.

My point is that you can control your $HOME, you can not always control your /etc, nor your /usr/local.

I actually have a $HOME/local/bin. :-)

Well, that's fine. Whatever your requirements demand. I was offering an alternate solution, since path_helper (ugh) adds /usr/local/bin to the PATH variable even if the directory does not exist.

BTW, do you also install MacPorts in your home folder?....}:-)>

BTW, do you also install MacPorts in your home folder?....}:-)>

No. My iMac is a lone island in a corporation full of Windows and Linux workstations, with Solaris and AIX target platforms for a cross platform product. I do not need to export my Mac binaries :-)

Mark Jalbert wrote:

BTW, do you also install MacPorts in your home folder?....}:-)>

People still use MacPorts? I build all my tools myself. Command line tools go into ~/bin. Frameworks go into ~/Library/Frameworks. I even have some things in ~/Applications.

I think the Macports users have moved on to homebrew.

http://brew.sh/

I build myself too, but there are times I wish tools are just an apt-get away.