Bug: bad handling of fixed paths

[vorpalhex]

Passing a fixed path to tweego results in all kinds of weirdness:

> tweego -f jailbird /tmp/temp.twee
error: load ../../../../tmp/temp.twee: open ../../../../tmp/temp.twee: no such file or directory

It looks like https://github.com/tmedwards/tweego/blob/81d1d717d195e95ae6b0765e7a47214bb5534ad6/io.go#L65 may need a call to https://golang.org/pkg/path/#Clean

[tmedwards]

Passing a fixed path to tweego results in all kinds of weirdness:

> tweego -f jailbird /tmp/temp.twee
error: load ../../../../tmp/temp.twee: open ../../../../tmp/temp.twee: no such file or directory

What, precisely, is the bug you're reporting there? Did the file actually exist? Was the relative path from the current working directory to the file incorrect?

It looks like

https://github.com/tmedwards/tweego/blob/81d1d717d195e95ae6b0765e7a47214bb5534ad6/io.go#L65 may need a call to https://golang.org/pkg/path/#Clean

The "path" package is for the manipulation of generic forward slashed paths, like URLs. To manipulate operating system paths, the "path/filepath" package should be used.

Regardless. Path normalization happens elsewhere, so fileReadAllWithEncoding() should not call filepath.Clean(). Absolute paths to user files are generated by filepath.Abs(), which itself calls filepath.Clean(). Relative paths are then generated by filepath.Rel(), since in most instances they're likely to be shorter than the absolute paths.

---

EDIT: The reported error seems odd on first blush. To receive the error you did, the given path has to have passed the filepath collection stage, where path normalization happens, which means the file should have been able to be opened.

[vorpalhex]

 > ls -al /tmp/ | grep temp.twee
-rw-r--r--  1 kyros  wheel     461 May 17 15:23 temp.twee

> cat /tmp/temp.twee
:: StoryData
{
    "ifid": "F84DACAA-11AB-43E3-8AD4-483BDDA4B134"
}
::StoryTitle
A Foo Bar Will Bleed

::Start
Hello There

Aren't you a pretty lady with a fancy tea? A mighty maid with a well packed leaf.

[[Foo]]

::Foo [tag1 tag2 tag3 tag4]

A fancy devil, not a simple foe. A mustache twirling weevil, not a mere poe.

[[Bar]] {"metaprop": "metaval", "metapod":"butterfree"}

::Bar

Opulant Tastes, not a sucker indeed. A delightful tobago, a canadian in need.

> tweego -f paperthin-1 /tmp/temp.twee
error: load ../../../../tmp/temp.twee: open ../../../../tmp/temp.twee: no such file or directory

/tmp/temp.twee does exist, is a normal file (not a symlink), is readable and accessible by other utilities.

The bug I'm reporting is that tweego doesn't accept a fixed path in it's sources list and instead produces back a mess of an error. Expected behavior is that Tweego can open sources specified as fixed paths.

[tmedwards]

The bug I'm reporting is that tweego doesn't accept a fixed path in it's sources list and instead produces back a mess of an error. Expected behavior is that Tweego can open sources specified as fixed paths.

The term is absolute path and Tweego accepts them just fine. The "mess", as you call it, should be the, or at least a, relative path to the file, which should be perfectly accessible via that path.

The problem here is likely that your system has symbolically linked the /tmp directory and/or your home directory—e.g., /home → /usr/home. The end result being that the relative path that Tweego is coming up with ../../../../tmp/temp.twee is at least a level off in the hierarchy from what it should be.

Forcibly attempting to render symbolic links should resolve the issue.

[boyland]

This is perhaps related. I'm using tweego, version 2.1.1+81d1d71 and it seems to ignore symbolic links: I have a .tw file that is a symbolic link to a file "far away", and tweego seems to silently ignore it and then complain that (e.g.) StoryTItle is not defined, when it is defined in the file.