0

I am using fastlane and snapshot to create screenshots automatically. To facilitate this I need to copy data into the app. In this case a series of folders and documents from one folder into another within a .app container.

So far the Documents folder is being created but no files are ever copied into it. At this point I’m not sure if I’m suppling the path incorrectly or what else I might be doing wrong to lead to this. It may be simply that I’ve got the wrong code to do that since I’m not that familiar with Ruby.

Any suggestions would be greatly appreciated, so tell me, what am I missing?

example_files = "./sample_data/Documents"
folder_name = "Documents"

setup_for_device_change do |lang, device|
  app_path = "/tmp/snapshot/build/SyncSpace.app/"

  FileUtils.mkdir_p(File.join(app_path, folder_name))

  Dir.glob(File.join(example_files, '*')).each do |example_path|
  FileUtils.cp_r(example_path, File.join(app_path, folder_name)) rescue nil # in case the file already exists
  end
end

Update - In the end my problem is that the path I’m using doesn’t work correctly for the files I want to transfer. When I give it a full path from the root level to the folder I need it works. Trying to use a shorter path with just the additional folders over the working directory fails.

So as a follow up, when my working directory is .../fastlane and my data is in .../fastlane/sample_data/Documents then why doesn’t just using ./sample_data/Documents work?

Mark Reid
  • 2,611
  • 3
  • 23
  • 45
  • 1
    There's two options I see: either your glob is not returning anything (thus never getting into the block) or an exception is being raised and swallowed by your `rescue nil`. – dodecaphonic Sep 10 '15 at 13:02
  • I added a few puts lines in there to check and you are right that it’s never entering the block. Am I right in thinking that means it’s not finding files to copy from the start? – Mark Reid Sep 10 '15 at 23:06
  • 1
    Using `puts` is OK for debugging, but it's pretty primitive and is a shotgun approach. I'd highly recommend learned how to use a debugger or Pry or IRB as a debugger. Debuggers let you peek into the running code and see exactly what is happening and trace the logic exactly as the program is written. – the Tin Man Sep 11 '15 at 02:02

1 Answers1

1

Don't use rescue nil. Ever, or at least until you're very aware of what your code could be doing and why you would want to use that. Instead use the normal form of:

begin
  do_something
rescue TheExactExceptionYouWantToHandle => e
  # handle the exception
end

That way you handle what you expect and blow up if it's something you didn't expect.

One of my programming mentors years ago told me

Never test for an error condition you don't know how to handle.

On the surface that sounds silly but experience teaches us we can get into situations where the program does the wrong thing trying to do the right thing. It's better to crash fast and safely and spew out an error, than to drag it out and damage things trying to recover or silently cover the error. Debugging a program that's rescuing improperly can be a major pain and a trailing rescue is a common culprit.

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
  • Thank you for the advice and helping me understand a bit more about what rescue was doing. I had taken it as just being something that was needed rather than really knowing what it was for. In this instance I’m not even getting that far it seems in the code so it didn’t solve the problem. – Mark Reid Sep 10 '15 at 23:08