Bash (Terminal) File and Directory Colors

I do a lot of work within Terminal and not having directory and file coloring drives me nuts after a while. To add colors

cd ~/
vi .bash_profile

add

export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad


reload it by typing (in Terminal)
source ~/.bash_profile

close out Terminal then start a new Terminal session. Do an ls and directories and files should now have color. A more in-depth explanation is listed below in “references”

References

adding file and directory colors to Terminal

The problem with setting up an environment piecemeal is when you sit down to do something, you have to figure out what rabbit hole you’d gone down when you left off. In this case, I remembered installing mysql, but usually the last thing I do when I install mysql is install phpmyadmin because it’s such a handy productivity tool. Well, there was no phpmyadmin on my system, but that could be because Snow Leopard came with PHP 5.3 out of the box which is incompatible with most of the popular PHP web applications out there.

Anyhoo … so I started by checking my $PATH variable and was surprised by the output.

echo $PATH gave me duplicates of /usr/local and /opt/local et. al. and had stuff in it that wasn’t in my ~/.profile

my ~/.profile had the following in it:

export PATH=/usr/local/sbin:/usr/local/mysql/bin:$PATH
##
# Your previous /Users/username/.profile file was backed up as /Users/username/.profile.macports-saved_2009-12-29_at_11:21:58
##
# MacPorts Installer addition on 2009-12-29_at_11:21:58: adding an appropriate PATH variable for use with MacPorts.
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
# Finished adapting your PATH environment variable for use with MacPorts.


and the second entry made by MacPorts was overriding the first entry.

Pretty funky.

TheTao of Path Variables

1. /etc/profile is the default startup script for Bash, which is what I’m using. (If you’re using a different shell, then you may have a different startup script). /etc/profile calls /usr/libexec/path_helper
2. path_helper first calls /etc/path and /etc/manpath which contain the initial path environment variables. /etc/path contains system-wide defaults:
   /usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin


3. path_helper then looks for files in the directories: /etc/paths.d and /etc/manpaths.d and appends the paths found there. On my system, /etc/paths.d and /etc/manpaths.d contain a file named X11 which simply contains the paths for X11.
4. After /etc/profile has called path_helper, it then looks for /etc/.bashrc. I have a bashrc (no “.”), but my bashrc only has stuff in it specifying the bash shell prompt (name-of-my-computer:directory username$)
5. Bash next looks for ~/.bash_profile. This is the file where you’ll set file and directory colors and could also be where you place your Path environment variables. Obviously, ~/ represents your user directory, so your settings will only be valid for your user.
6. Next, bash looks for ~/.bash_login. I don’t have this on my system so it’s ignored in my case
7. next, bash looks for ~/.profile which I did have on my system and is the file that XCode wrote to.

Another file that can contain path variables is ~/.MacOSX/environment.plist. This sets environment variables, including paths, for gui applications. I’m not using it on my system so don’t have anything to say about it.

Recap

So, what that all means is that instead of exporting PATH environment variables to a .profile or .bash_profile in a user account directory, you (or your application) can, instead, make PATHs global by adding text files to the /etc/paths.d and /etc/manpaths.d directories.

If you need to control the order of a path, then try this:
Add a line PATH=”" before the call to path_helper like this in /etc/profile:

if [ -x /usr/libexec/path_helper ]; then
PATH=""
eval `/usr/libexec/path_helper -s`
fi


All that said and done … I’ll continue using ~/.bash_profile because it’s got that warm fuzzy familiarity. Personal preference, as always.

References

man page for path_helper
making use of paths.d
mastering the path_helper

Delete files from the target directory that have been deleted in the source directory
rsync -avz -e ssh --delete remoteuser@remotehost:/remote/dir/ /this/dir/

Note: the ending {/} is important if you don’t want to hose a directory.

Backup a website on a linux box to your windows machine

rsync reads “:” in a filepath as a remote directory, so if you’re trying to rsync to “c://” rsync will be confused. Instead of using windows syntax for filepaths, use the cygwin directory structure.

1. Install cygwin to windows
2. test rsync and ssh are installed by typing from within the cygwin terminal:
   rsync --version
ssh -l username somedomain
3. create a directory in c://cygwin named backups or whatever you want to call it.
4. rsync -avz -e ssh --delete remoteuser@remotehost:/remote/dir/ /cygdrive/c/directoryname Change the directory drive to whatever it should be

references

rsync over ssh

Environment:

Apache 1.3.29

References:

How to Disable SSL v 2 support in Apache

On Aug 10, 2009, Apache released an upgrade that addresses a DOS vulnerability.

server:

/usr/local/apache2/bin/httpd -v
# Server version: Apache/2.2.11 (Unix)
# Server built:   Jan 15 2009 13:39:20

dev server:

/usr/sbin/apache2 -v

Issues

1. caused 401 error for all http requests (worked correctly for https connections) source
2. Seem to be some issues with mac version – It’s unclear whether this is an issue with a pre-compiled mac version or a generic self-compiled (which should be identical to the linux version) source

Dev Server Tests

Ran apt-get update and apt-get upgrade on dev server

ran apt-get upgrade apache2 and message returned says that 2.2.8 is the current version. Which means my dev and my production servers are out of sync. I was surprised to learn that the last contractor from whom I took over server management had installed from source, removing Apache from package management. Not a big deal really, but it was undocumented.

In any case, there doesn’t appear to be a package release for Apache 2.2.13 yet in Ubuntu. Only one of the 4 bugfixes has a security bulletin attached, so I’ve decided to wait a few weeks to see if anything new transpires in the security bulletins. In general, I prefer to wait on updating production servers until a new release has been out long enough for bugfixes to be released.

Redesigning your own website is a little different from redesigning someone else’s. It’s easy to get bogged down in minor details and obsess over all the little things that no one else really cares about. I think our own challenges with this redesign were not so different from the challenges some of our clients face.

• Hurdle 1: To rebrand or not to rebrand otherwise known as “Do we have all the pieces? Are they the right pieces?”.
  Our business name is hard for people to pronounce and spell and few people know what “semiotics” is. Semiotics isn’t a good candidate topic for an elevator pitch. Our discussions about redesign became cyclical discussions about rebranding. We finally decided that the name does actually describe what we do and we could live with it a little longer.
  Moving On.
• Hurdle 2: Design for Visitors vs. Design for Ourselves
  That’s a no-brainer in any redesign process …. websites exist for visitors to use. But, when designing your own website there are no external checks and balances. Without a reporting schedule, it takes self discipline to stick to priorities. At one point during this process, I started obsessing over microformats and whether microformats were appropriate to non-blog pages that aren’t reviews …. interesting but not high on the priorities list and I’ll wager that very few of our visitors care about microformats. Those that do care didn’t look until they read this.
• Hurdle 3: Decoupling the end product from the need to make it a fun learning process (in other words … get a handle on the NADD)
  This is another reason web developers don’t get around to updating their own sites. We explore newish technologies and techniques and give ourselves permission to do so by declaring we’re “rebuilding the dusty old website finally”.
  What ends up happening is the new technology or technique is underwhelming, or it’s overkill, or it takes forever to learn and then the best practices change so frequently we can’t keep up, the trend changes before we finish and we’re too embarrassed to go live with a now-outdated trend that looks like every other I-read-about-that-yesterday website, or it plain doesn’t work. It’s never really good enough … and the challenge is get call it “good enough” without scratching your eyes out
  Really, the core of our website is just have a few pages and a blog.