--verify with relative filename does not work

[matthijskooijman]

It seems that specifying a relative filename to the sketch does not work with --verify. I suspect this worked before and was broken in the recent refactor to remove GUI dependencies from the CLI invocation.

To reproduce, just call arduino with a plain filename (it does not matter if the file/sketch exists or not), like:

$ arduino --verify foo.ino
Picked up JAVA_TOOL_OPTIONS:
Loading configuration...
Initializing packages...
Preparing boards...
Verifying...
java.lang.NullPointerException
        at processing.app.helpers.FileUtils.listFiles(FileUtils.java:348)
        at processing.app.Sketch.listSketchFiles(Sketch.java:108)
        at processing.app.Sketch.<init>(Sketch.java:54)
        at processing.app.Base.<init>(Base.java:381)
        at processing.app.Base.main(Base.java:140)

Note that the above has the following patch applied, since the --verify handling code currently eats up exceptions without showing them (which also makes things fail without error when a full path to a non-existent sketch is passed). This should also be fixed.

--- a/app/src/processing/app/Base.java
         outputFile = new Compiler(sketch).build(progress -> {}, false);
       } catch (Exception e) {

         // Error during build
-        System.exit(1);
+        throw(e);
       }

Furthermore, passing a full filename works:

$ arduino --verify $(pwd)/foo.ino
(output hidden)

Without --verify, a relative pathname works as expected and loads the sketch in the GUI without complaints:

$ arduino foo.ino

[brandoncurtis]

Can confirm that this is a problem in 1.8.0 and 1.8.1 on Debian Jessie and Ubuntu 16.04, that it breaks arduino --upload, that it fails silently, and that passing a full path still works. This problem doesn't appear in 1.6.13. Adding CLI uploading to the unit tests could prevent regressions like this one.