Is there a way to provide standard input in *compilation* buffer for testing programs?

[deleted]

Your real problem is that unit tests shouldn't prompt for any input. How do you enter input if they're running in a CI environment? Your effort would be better spent fixing the unusual test behavior than changing Emacs to support it. The assumption that the commands being run are non-interactive is built pretty deeply into compilation-mode, so changing that is likely to involve fairly deep changes in how it works. You'd probably be better off making a different mode entirely, based on comint-mode, with support for the compilation-mode regexp matching and `compile` / `recompile` style commands to invoke it.

I mean, i get that is doesn't make sense if you are running CI tests, but in this case, i need to test standard input, cause i'm working on cli program, that ask user for input and gives output. I guess i could also just compile my code and run it in terminal every time i compile it. it's a bit cumbersome tho, i wonder if there is a comfortable way to do this in emacs. is comit-mode fit for this? tnx for suggestion btw

> in this case, i need to test standard input, cause i'm working on cli program, that ask user for input and gives output. Then you need your test to do that for you. It sounds (as you put it) cumbersome to have to manually provide input every time you run it, anyway. Does the text expect a specific input and check the output? Do you just… know what the right output is for a given input? What if someone else needs to work on it, how do they learn those things? What do the tests even buy you over running the completely program by hand? You could break up the program into steps like: read input, process input, create output, print output, and have your test call the process input function with known inputs, then check the output against them. Or have it it fork and run the program and handle the I/O that way. My point here is: Fix the tests and you eliminate the root cause, and make the tests both more accurate and easier to run, no matter how or where you run them. If you make a weirdware interactive compilation thing for Emacs, it partially works around the problem when run with one specific setup. It's better to fix the root cause of the problem than half-assedly work around it. > I guess i could also just compile my code and run it in terminal every time i compile it. it's a bit cumbersome tho, i wonder if there is a comfortable way to do this in emacs. is comit-mode fit for this? tnx for suggestion btw Comint is for running interactive programs, and is essentially a line-oriented terminal built in to Emacs. Since your tests are interactive, it's a better tool for running them, as they are now.

I agree with ieure. For exemple, click (python librairie to build cli) provides a way to test and automatically insert user input. Maybe your cli framework provides something similar. If not maybe you can try https://linux.die.net/man/1/expect. It allows to automatically answer to input.

Ok, i'll learn to make better tests. I suppose, it makes more sense than writing inputs by hand. Is there any way you recommend make these test? the only way i know is to use some thing the bash way. i could just create basic text file with all the inputs and direct it with bash something like this './program < inputs.txt', but this method doesn't include checking if outputs are correct.

Noted, tnx.

> Is there any way you recommend make these test? the only way i know is to use some thing the bash way. I have no idea what language you're using for this stuff, so I can't make any recommendations.

Any chance you can get away with "./myfoo < tests/myinput.txt" ? Or use something like 'expect' from the old days, where you'd write a expect script that would 'expect <some prompt>' and then write back 'some response', so you could script an interactive dialog. There are lots of ways of doing that sort of thing, but another option if you're not using a test framework is to have a function char \*get\_my\_input() whatever, and it normally pulls from stdin, but if #define TEST mode could instead pull from a file, say. Shouldnt' take you much effort

`compile`'s second argument is COMINT, which enables interactive input (with prefix argument).

You can press C-u g so that compile lets you edit the command line before starting the compilation again.

C-u M-x compile puts the buffer in comint-mode so you can do whatever, however you can no longer say q to delete the window when the process is finished tho. :( Maybe there's a hook you can abuse? Idk.

[deleted]