Possible Bug in "Upload to Examine"

[patzer_w]

Dear xboard/winboard developers,

may I point out a possible bug in xboard 4.6.0 (compiled under Linux debian 2.6.32-5-686), connected with the "Upload to Examine" feature?

When I mark the following moves
1. e4 c5 2. Nf3 Nc6 3. Bb5 d6 4. O-O Bd7 5. Bxc6 bxc6 6. d4 cxd4 7. Qxd4 Nf6
and select Edit -> Paste Game, the moves are correctly executed on the board. But when, after that, being logged in to FICS (www.freechess.org), I select Action -> Upload to Examine, Black's fifth move is not accepted, most probably due to some ambiguity of the possible moves Bd7xc6 and Pb7xc6.

The server gives the following output:

prompt% Game 505: patzer_w moves: e4
prompt% Game 505: patzer_w moves: c5
prompt% Game 505: patzer_w moves: Nf3
prompt% Game 505: patzer_w moves: Nc6
prompt% Game 505: patzer_w moves: Bb5
prompt% Game 505: patzer_w moves: d6
prompt% Game 505: patzer_w moves: O-O
prompt% Game 505: patzer_w moves: Bd7
prompt% Game 505: patzer_w moves: Bxc6
prompt% Ambiguous move (bxc6).
prompt% Illegal move (d4).
Illegal move (cxd4).
Illegal move (Qxd4).
Game 505: patzer_w moves: Nf6
prompt% Game 505: patzer_w commits the subvariation.

[H.G.Muller]

Hmm, this really looks like a FICS bug to me. It is a bit shocking that FICS does not understand the official SAN for this move. The 'b' is not capitalized, so in case of doubt FICS should assume it is a Pawn move. I know the public ICS code does! How else would you have to enter this move in SAN? Pbxc6???

Of course I could make a work-around by having WinBoard send all moves to the ICS in long algebraic, but it would be preferable if FICS fixed their SAN parser...

[patzer_w]

Thanks for your answer! Using this information, I checked the FICS help files. In http://www.freechess.org/Help/HelpFiles ... oving.html
they say
"Suppose Black wants to move the knight from f6 to e4. The move to enter in algebraic would be Ne4 (or just ne4, since lower and upper case letters are the same for the chess server)."

Later on:
"It is possible, in certain board positions, for both a pawn on the b-file and a bishop to make a capture on the same square. Unfortunately, the server may confuse a 'b' meaning the pawn on the b-file with a 'b' meaning a bishop. In this case, the move 'bc6' may be ambiguous, and the server will not know which piece to move, the b-pawn or the bishop. If this ever happens to you, enter the pawn capture as 'pxc6'."

And again later on
"To avoid problems with ambiguous moves, you can also use computer notation ... which is the next (and last) topic."

Could that be a solution (i. e., b7c6 or d7c6)? To the "end user" it would not matter which notation is used internally ...
Of course, I could also contact the FICS admins. But their help file indicates that they are aware of the problem, and there might be some reason why they have not changed it.

[H.G.Muller]

Well, the point is that FICS move entry is not something 'internally', but that it is possible to connect to FICS with a text interface like Telnet, or use the WinBoard ICS console to type moves (as blind people have to rly on, as they cannot use a mouse). So it is outright ridiculous that it would not understand normal SAN. That server is really going down the drain...

However, I have built in a work-around in WinBoard, no matter how obnoxious this is. Whenever the SAN move starts with bx or Bx it will now print the from-square in stead. (I did not want to use long algebraic in general, because this runs into problems with FRC castlings.) I think I even handles promotions well.

A Windows binary that includes the fix can be found in the 'portable WinBoard' package that I put together, at http://hgm.nubati.net/WinBoard-Portable.zip . You can simply take the winboard.exe from there to replace the one in your current install. Note that this version allows you to drag ini files on top of the exe to start WinBoard with the options specified in the ini file.

[Roger Brown]

SNIP

A Windows binary that includes the fix can be found in the 'portable WinBoard' package that I put together, at http://hgm.nubati.net/WinBoard-Portable.zip . You can simply take the winboard.exe from there to replace the one in your current install. Note that this version allows you to drag ini files on top of the exe to start WinBoard with the options specified in the ini file.

Hello H.G.,

Just wanted to say thanks for the portable Winboard.

Now I am good to go - literally.

Later.

[patzer_w]

...

A Windows binary that includes the fix can be found in the 'portable WinBoard' package that I put together, at http://hgm.nubati.net/WinBoard-Portable.zip . You can simply take the winboard.exe from there to replace the one in your current install. Note that this version allows you to drag ini files on top of the exe to start WinBoard with the options specified in the ini file.

Dear H.G.,
thank you very much for your efforts! May I ask if there is also a solution available for xboard? As I am using Linux (debian 2.6.32-5-686), the winboard.exe does not help much. I would need the corresponding source files, to replace them and recompile it.

[H.G.Muller]

Yes there is! I already pushed the patch to the GNU repository. Click on the 'commit message' for the master branch, and then on the download link that will be near the top of the page that appears.

Beware that when you load a source tar ball from that git repository, you have to start building with the command

./autogen.sh

before the usual

./configure
make
sudo make install

[patzer_w]

Yes there is! I already pushed the patch to the GNU repository.

Thank you very much! I just recompiled it - now it works perfectly ...