View Ticket
Not logged in
Ticket UUID: 2857ab0995828207effd6ebc4526ca88a53755f7
Title: Introduce commandline switches to avoid user input
Status: Open Type: Feature_Request
Severity: Important Priority:
Subsystem: Resolution: Open
Last Modified: 2011-01-06 22:01:04
Version Found In: all
Description & Comments:
I'm trying to build a C# wrapper around fossil to provide a .NET dll to be used in Windows source control applications like the source control interface of Visual Studio.

While implementing the commands which are available on the fossil command line I've encountered some commands which might require user input.

For example fossil open requires an a, y or n if files of the checkout are already present.

Handling those commands from my code is kind of cumbersome because I have to run the commands asynchronously, parse their output and inject the correct answers at the right places with event handlers for all the commands which need user interaction. It would be much easier if I could define anything on the commandline.

Although it is obviously not possible to have commandline switches for the y or n on individual files, it should be possible to give the a(ll) answer by something like --force on the commandline. It is already done for a number of commands. Generally spoken, it should be possible to set a default answer for all files involved on the commandline whenever user interaction is required.

If this feature request is a candidate for future implementation, I'd compile a list of commands which require user interaction and provide suggestions for a commandline switch.

Btw.: Did you ever think about making fossil available as a library like you did with SQLite?


anonymous claiming to be ikoch added on 2011-01-05 21:55:59 UTC:
I'm still puzzling together the pieces to trace fossils output and inject the appropriate answers. Now an other problem raised its ugly head.

When fossil prompts the user for input, it waits for the answer on the same line as the prompt. It doesn't add a line end terminator after the prompt. The problem is that I need to read the fossil output before I can decide what to do. I do this by registering to events which occur whenever a line has been written to stdout or stderr. Unfortunately the line isn't written completely for prompts, the line end terminator is missing. Because of this, the line is never read, the event is never fired and the answer is never sent to stdin to make fossil happy. Fossil waits forever.

A minor change in user.c would make it possible to read the line. Just add a newline to the format string in the printf statement and anything should work.

void prompt_user(const char *zPrompt, Blob *pIn){
  char *z;
  char zLine[1000];
  blob_zero(pIn);
  printf("%s\n", zPrompt); /* added a newline to terminate the line */
  fflush(stdout);
  z = fgets(zLine, sizeof(zLine), stdin);
  if( z ){
    strip_string(pIn, z);
  }
}
I think except for the input in the user_cmd function it doesn't really matter wether the response is entered on a new line or not and even there it is not really a problem.

anonymous claiming to be viric added on 2011-01-06 22:01:04 UTC:
This can be solved in-fossil with

setvbuf(stdout, (char *) NULL, _IONBF, 0);

Out of fossil, GNU coreutils comes with stdbuf, a script with a LD_PRELOAD that will have that effect.