use unqualified command paths

[pyther]

This change resolves issue #50 during the first puppet run if cups is not installed. Some investigation into this issue revealed that lib/puppet/prividers/printer/cups.rb gets processed prior to any configuration.

When cups is not installed, commands cupsenable, cupsdisable, cupsaccept, and cupsreject are never set resulting, in the error Could not evaluate: undefined method 'cupsenable' for # as you can see in the below code snippet.

  [ "/usr/sbin/cupsenable",
    "/usr/bin/cupsenable",
    "/usr/sbin/enable",
    "/usr/bin/enable"].each do |cups_command|
    if File.exists?(cups_command)
      commands :cupsenable => cups_command
      break
    end

Essentially during a puppet run the following happens:

• parse lib/puppet/prividers/printer/cups.rb
• install cups
• install printer (fails because cups.rb was parsed before cups was installed)

By using unqualified binary paths we rely on the system path and therefore don't have worry if the binary is in /usr/bin or /usr/sbin.

From the puppet documentation

The binary can be fully qualified, in which case that specific path is required, or it can be unqualified, in which case Puppet will find the binary in the shell path and use that. If the binary cannot be found, then the provider is considered unsuitable.

With this patch, if the user does not have cups installed and does not include cups they will get this error message Error: Could not find a suitable provider for printer, however puppet will complete the run without aborting.

[pyther]

I forgot to mention, I looked at cups from RHEL6.1 and Fedora Core 6 both cups packages provide cups{enable,disable,accept,reject} which symlink to the binaries enable,disable,reject,accept.

[mosen]

Sounds good. I think the multiple binary names came about previously because of something like IllumOS or SmartOS (or solaris). There was one distribution which only included a non-symlinked enable/disable.