|2018-11-08 12:15:43||guillem||set||status: reviewing -> resolved|
|2018-02-09 10:33:17||guillem||set||status: in-progress -> reviewing|
|2018-02-07 17:27:48||guillem||set||status: chatting -> in-progress|
|2018-02-06 16:21:28||guillem||set||assignedto: guillem|
+ easy, translator
title: Print translator output to stdout and not to file -> make translator output file configurable
summary: Dear FastDownward maintainers,
At our research group at the University of Potsdam, we are using FastDownward’s
translator (with --translate) successfully as a very useful preprocessing step
in our planning projects :).
At the time being, FastDownward’s translator produces an output.sas file, which
we later parse in our applications for further processing.
However, printing the translator output to files has multiple drawbacks.
1. We can’t simply pipe FastDownward’s output within our toolchain like this:
fast-downward --translate [<files>] | planning-tool
2. When we run two FastDownward processes simultaneously in the same working
directory, the same file is read and written to by the two processes without
synchronization, resulting in all kinds of issues.
3. The working directory is polluted with files that need to be cleaned up later.
4. FastDownward’s translator fails when run from a directory without write
permissions for the current user.
For this reason, I would like to know whether it would make sense to have
FastDownward print all output to stdout by default instead to files?
I know that there are cases where multiple output files are produced. Perhaps,
it would, thus, be best to have options to redirect output as intended by the user.
For instance, --output=output.sas would print the output to a file, while
--output=- would print to stdout (using a dash is a convention used by many
programs ). And --output-<alternative> would configure the output of some
other stream, for instance, the output after postprocessing.
As explained above, our group could really make use of such a feature. Do you
have plans to implement something along these lines in the future? If you
currently don’t have the resources to implement this, I could certainly lend a
I haven’t seen any issue like this on the issue tracker before, so I apologize
if a similar idea has been proposed before.
 https://unix.stackexchange.com/a/16364 ->
|2017-10-26 10:09:27||malte||set||status: unread -> chatting|
+ malte, patrick.luehne