Not getting CommandNotFound error

[brendon]

Hi there, just thought I'd let you know I was getting a nil return code (and the usual message regarding non-matching return codes) rather than the CommandNotFound. Adding a manual path to find the command (it was pdftk in /usr/local/bin on Mac) via the Paperclip configuration it returned 0 and all was well. I spent a bit of time trying to figure out what was wrong because I wasn't expecting that it couldn't actually find the command :)

Not sure where to look in terms of finding a fix for this that would properly inform the user.

[jyurek]

What version of cocaine were you using, and what Ruby interpreter? That shouldn't really happen.

[brendon]

Oh man, it was so long ago. I was using MRI 1.9.3, probably the latest patch level at the time. Probably also the latest version of Paperclip at the time. So whichever version of cocaine it was specifying at the time also :) Lol, I'm sorry that's not very specific. My git-fu isn't strong enough to figure out what those versions were. I'll have a go at removing that path and seeing if the issue shows itself again now though.

[brendon]

Yep, it still happens:

Command 'pdftk '/Users/....../newsletter_set/front_covers/1/04.09.2014.pdf' '/tmp/57beb4f46c38cd57ae09a55eb31fa9ff20141208-8924-1q9dg8h.pdf' cat output '/tmp/57beb4f46c38cd57ae09a55eb31fa9ff20141208-8924-1q9dg8h20141208-8924-vrii81'' returned . Expected 0

Using cocaine (0.5.4) and here is my paperclip processor:

module Paperclip
  class Stitcher < Processor

    # Stitches a pdf to the front and back of the attachment (assuming it's a PDF).
    # Expects the model instance to provide a front_cover_path and back_cover_path method

    def initialize file, options = {}, attachment = nil
      super

      @file           = file
      @front_cover    = attachment.instance.front_cover
      @back_cover     = attachment.instance.back_cover

      @current_format = File.extname(@file.path)
      @basename       = File.basename(@file.path, @current_format)
    end

    def make
      destination = Tempfile.new(@basename)
      destination.binmode

      unless front_cover_path || back_cover_path
        FileUtils.cp File.expand_path(@file.path), File.expand_path(destination.path)

        return destination
      end

      parameters = []
      parameters << ":front_cover" if front_cover_path
      parameters << ":source"
      parameters << ":back_cover" if back_cover_path
      parameters << 'cat output'
      parameters << ":destination"

      parameters = parameters.flatten.compact.join(" ").strip.squeeze(" ")

      Paperclip.run "pdftk", parameters, :front_cover => front_cover_path,
                                         :source => File.expand_path(@file.path),
                                         :back_cover => back_cover_path,
                                         :destination => File.expand_path(destination.path)

      destination
    end

    def front_cover_path
      File.expand_path(@front_cover.path) if @front_cover.exists?
    end

    def back_cover_path
      File.expand_path(@back_cover.path) if @back_cover.exists?
    end
  end
end

[jyurek]

Ok, so it's calling pdftk and not finding it... do you happen to have more than one in your path? Maybe it's finding another one somehow? What do you have Paperclip.command_path set to?

[brendon]

Aha! I didn't read the docs for which. Using the -a option I see there are two copies.

which -a pdftk
/usr/local/bin/pdftk
/usr/bin/pdftk

The actual files are identical but setting Paperclip.options[:command_path] = "/usr/local/bin/" fixes the problem, so I'm guessing the /usr/bin/pdftk copy is being run otherwise? So strange :)

[jyurek]

Depends on what's in your $PATH, but it sounds like it. If they're identical I don't know why one would work and the other not. But this is starting to make more sense now. :)

[brendon]

In my $PATH /usr/local/bin comes first, so strange that the other is being executed?

Deleting the second file (while also not having the :command_path option results in the error not occurring, so I guess there was something dodgy with that other file. Actually, perhaps it wasn't executable by non-root? To delete it I had to sudo. Would that return a blank code?

[jyurek]

TBH, I have no clue why it would return nil, but at least we sussed out what was going on!

I just checked, and not having the permissions to execute a file still populated $?, so it had an exitstatus. Weird.

[brendon]

Yea, pretty weird. I guess at least this issue will be here in case someone comes up against it in the future. It's an easy fix :)

I tried to restore the file from time capsule but it was giving me grief. Feel free to close this if you want, but I'm happy to continue to investigate the cause if you are.

[jyurek]

Sounds like it's not really that big a deal anymore. Thanks for looking into it!

[brendon]

No worries :) Thanks for your help :)