You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current dream_eml CLI takes a FILE argument, infers the output filename from it, and writes this file in the same directory as the input file.
This has been problematic in the past when I wanted to put my eml files in a separate directory.
The interface also makes it impossible to create a new dune dialect as the preprocessor is expected to write to stdout.
I think a more Unix-y interface for the dream_eml CLI would make its usage a bit more flexible.
What do you think of allowing it to read from stdin and write to stdout? Should these be the default?
The text was updated successfully, but these errors were encountered:
I agree with this in principle and see the advantages. However, eml needs a FILE argument to generate locations in its output that refer to the original source file, i.e. #22 src/foo/bar.eml. That's why the command line is not Unix-y to begin with. Do you really need reading from STDIN, or just writing to STDOUT, like in @tcoopman's PR? An interface where eml always reads from STDIN would be a bit awkward, since it would look like dream_eml FILE.eml < FILE.eml > FILE.ml.
The current
dream_eml
CLI takes aFILE
argument, infers the output filename from it, and writes this file in the same directory as the input file.This has been problematic in the past when I wanted to put my eml files in a separate directory.
The interface also makes it impossible to create a new dune
dialect
as the preprocessor is expected to write to stdout.I think a more Unix-y interface for the
dream_eml
CLI would make its usage a bit more flexible.What do you think of allowing it to read from stdin and write to stdout? Should these be the default?
The text was updated successfully, but these errors were encountered: