It looks like File.getAbsolutePath doesn't automatically resolve based on
the current working directory. I did not know that. Using getAbsolutePath
is still capable of being correct, you just apparently have to specify what
the path is relative to first. I will take action on this when I resolve
the other issues, and write a unit test for this. We'll see what I have to
do to make it work.
On Apr 21, 2014 12:59 PM, "Radu Mereuta" <notifications@github.com> wrote:

> In src/javasources/KTool/src/org/kframework/parser/DefinitionLoader.java:
>
> > @@ -102,7 +102,7 @@ public static Definition parseDefinition(File mainFile, String mainModule, boole
> >
> >              // transfer information from the BasicParser object, to the Definition object
> >              org.kframework.kil.Definition def = new org.kframework.kil.Definition();
> > -            def.setMainFile(mainFile.getCanonicalPath());
> > +            def.setMainFile(mainFile.getAbsolutePath());
>
> File f = new File("..");
> System.out.println(f.getAbsolutePath());
> System.out.println(f.getCanonicalPath());
>
> output:
> D:\work\k\samples\test..
> D:\work\k\samples
>
> So absolute path doesn't resolve relative paths, but canonical does:
> "A canonical pathname is both absolute and unique.... This typically
> involves removing redundant names such as "." and ".." from the pathname,
> resolving symbolic links (on UNIX platforms), and converting drive letters
> to a standard case (on Microsoft Windows platforms)."
>
> I want the ".." and "." to be eliminated. those are hard to follow or easy
> to overlook when viewing error messages.
> Regarding symlinks, well... I agree... you may not want those to be
> resolved. Suggestions?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/kframework/k/pull/395/files#r11817617>
> .
>