Twice Foiled by CRLF on Linux

I’m just going to get this off my chest.  There is no reason in the world why life has to be this difficult.  These computers were brought into our lives to easy the pain and yet, somehow, they just don’t measure up!  I have been bitten by this one twice.  It’s clearly evident had I blogged about it before now, I could have reclaimed a day of my life back.

So Git has this thing with carriage return/line feed characters and it should all make our lives easier when transitioning between a Linux environment and a Windows environment with our code.  I had given it a cursory look a while back and configured my own machine to, once and for all, prevent the mayhem that arises out of saving files with CRLF (Carriage Return Line Feed) characters onto a Linux Server.  Well, I forgot about it, and it took me nearly a day to figure out why I couldn’t run a simple bash script that calls a simple PHP page that processes a simple set of commands that ultimately is configured for a simple cron job to run every single day.

SYNOPSIS:  When on a Linux server, you cannot run a bash script if that script ends in an CRLF.  It fails miserably.  In my case my script file called:

php /do_important_things.php

The error returned (from having a CRLF at the end) was:

Could not open input file: /do_important_things.php

When you’re walking into an error that says: “Could not open input file”,  and you have no idea why it doesn’t work,  I can guarantee you, CRLF, is not the first thing that pops in your head.  In both instances, this stackoverflow question and answer by chown has proven invaluable to me!

I have since adapted the Git Repository to include a .gitattributes file (as recommended) that states the handling conditions of the line endings.  So this shouldn’t ever happen again…on this repository.

# Set default behavior, in case users don't have core.autocrlf set
* text=auto

# Explicitly declare text files we want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

On the XAMPP War-Path…

Pulling my head out of the Windows stack for a while, not that ASP.NET doesn’t work for me – it does; I’m simply tasked to support another stack.  A world somewhat foreign to me.  The world of Apache, MySQL, and PHP.  Not sure what the X and P surrounding the AMP stand for if that’s any indication to how new I am at this.

So I downloaded XAMPP and installed it on my Windows 7 64bit OS.  I didn’t run anything as a service because I didn’t want to add additional processes to my start-up routine.  So I tried to fire up the Apache service from the XAMPP Control panel (v.3.0.12) and it starts and immediately shuts down.  I have my suspicions that it may be conflicting with my IIS utilizing port 80.  So I step into the config file (httpd.conf) and change the port and now I’m up and running it appears.

image

If you are a XAMPP guru or even a PHP guru, let me know as I’m about to perform the equivalent of swimming across the English Channel and would like a personal floatation device to keep me bouyed in this endeavor.