1

Let's say I have two programs which play chess: chess_1 and chess_2. They keep track of the board themselves, and take as input opposing moves, and then output their moves. For example, if I wanted to play against chess_1, I would do the following:

I would start the program (assuming I am white)

$ ./chess_1                  # program starts and hangs for input
  <my move>                  # my input
  <the bot's move>           # bot output
  <my next move>             # my input
.... < etc. > .....

And the bot would keep track of the game board. My question is, how can I make chess_1 play against chess_2?

Liam
  • 278
  • 2
  • 8
  • In other words, you means tie stdout of chess1 to stdin of chess2 and vice versa? For a start I would say you should be allowing the move to be specified through stdin rather than via a command line argument. After that, why not just use named pipes? – Wildcard Apr 19 '16 at 01:54
  • @Wildcard I think so. Honestly I know that this information exists out there, but I really had no idea what it was called so I was having a hard time finding it. I'll look for "named pipes". (I also changed i/o to stdin int eh question) – Liam Apr 19 '16 at 01:56
  • 1
    They're also called fifos (for "first in first out"); that may help. The tool to create them is mkfifo but the man page assumes you already know what they are. :) Here's an Introduction to Named Pipes. – Wildcard Apr 19 '16 at 01:57

1 Answers1

1

You did not specify the shell, so, in general, named pipes would be easiest way. However, if your shell supports them, this could be a nice use case for coprocesses.

How do you use the command coproc in Bash?

In a | cmd | b, a feeds data to cmd and b reads its output. Running cmd as a co-process allows the shell to be both a and b.

In bash:

coproc ./chess_1
./chess_2 < "${COPROC[0]}" > "${COPROC[1]}"

The linked post also talks about drawbacks of coprocesses, and has examples of using named pipes (via mkfifo).

muru
  • 72,889