There seems to be a couple bugs in goxsh or maybe in MtGox (but requiring a workaround).
The command history has a problem with long commands like "cancel sell 23444--2334-222222etc". It doesn't fully remove the text as you up arrow past the command leaving garbage behind on subsequent commands. From my reading of the code it seems this is in the Python readline module. Or perhaps the rl_completer code. I don't have enough python-power to fix it.
The feature that allows entering a $USD and calculates how many BTC should be bought to match the $USD price will often enter invalid orders. This appears to be something in the precision/rounding code. I tried adding "rounding=ROUND_DOWN" but that didn't help - I still get invalid orders that don't execute (and cost me money in missed trades).
You won't know they don't exec until the price moves there and the order fails or partially fails. Then MtGox shows it as an invalid X order. I suspect maybe changing the precision to usd instead of btc would help here or perhaps just subtract 0.00001 from the USD amount before calculating.
For now I'm just using a calculator to figure it manually and try to enter a safe btc amount.
buy $41.4636 3.9302
results in below after the trade tries to execute,
Kind | BTC | ID
| USD | Date (status)
============================================================
buy | 0.87640578 | 579b7a7e-f3bb-4756-87c9-3e1fba46f550
| 3.93020000 | 2011-10-12 18:57:56 (open)
------------------------------------------------------------
buy | 0.00000007 | X579b7a7e-f3bb-4756-87c9-3e1fba46f550
| 3.93020000 | 2011-10-12 18:57:56 (invalid)
------------------------------------------------------------
The problem may be at the MtGox end and related to partial fills leaving a fragment behind that no longer calculates to the remaining funds available. In the few cases I've seen this cocur I think it was when partial fills took place.