Open bertsky opened 6 months ago
Same is true for the --mets-server-url
argument: relative paths don't work (not relative to the workspace and not relative to CWD).
(Again, the user expectation is that whatever resolves at startup time from the user's CWD should be kept.)
On the CLI, the user expects that paths are resolved once (on the input side) and from then onwards everything is automatically done relative to the workspace (whenever possible). So if a file path is absolute, then its workspace prefix gets removed regarding METS FLocat. Or if it is relative, then it is relative to the CWD, but gets resolved relative to the workspace.
Unfortunately, that's not what we have implemented yet, esp. if you combine with an overall
-d path/to/workspace
(so CWD is not equal workspace directory).For example, in
add_file
, we currently have: https://github.com/OCR-D/core/blob/299301003688c14a2824d865804f3a69480cdbbd/src/ocrd/cli/workspace.py#L221-L222Meaning, the workspace directory gets added, with no regard to the caller's CWD.
Another example is in
bulk_add
, where we do: https://github.com/OCR-D/core/blob/299301003688c14a2824d865804f3a69480cdbbd/src/ocrd/cli/workspace.py#L375-L381Here, again, no difference is made between CWD and self.directory.
In the latter case (bulk-add), what makes things worse is that the glob pattern gets treated verbatim if empty: https://github.com/OCR-D/core/blob/299301003688c14a2824d865804f3a69480cdbbd/src/ocrd/cli/workspace.py#L333-L335
So if one tries to compensate for the above path resolving issue by passing a glob relative to the workspace, then that itself will break the METS with a verbatim asterisk path entry: