Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider a more Unix-y interface for dream_eml #227

Closed
tmattio opened this issue Jun 10, 2022 · 1 comment
Closed

Consider a more Unix-y interface for dream_eml #227

tmattio opened this issue Jun 10, 2022 · 1 comment

Comments

@tmattio
Copy link
Contributor

tmattio commented Jun 10, 2022

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?

@aantron
Copy link
Owner

aantron commented Mar 3, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants