> Hah, there's a lot of stuff in main which i did not yet have a closer
> look at ;-) and i'm not really familiar with the code. But (as a quick
> shot) how about checking emacs_socket in addition to connected:
>
> if (connected || emacs_socket != INVALID_SOCKET) {
> exit(exitval);
> else
> exit(EXIT_FAILURE);
>
> Maybe even forgetting about connected at all...
I've bow compiled a version with the fix above. It's working in first
tests. I'll do some further testing and let you know how it goes. I can
also email the compiled binaries (emacsclient/emacsclientw) to anyone
who's interested.
>
> Not sure though if this would work for all cases (or at all). If you
> want i can have a closer look. But then i would probably also like to
> set up a dev env to compile emacs on windows. Any good tips how to
> start? I already have msys/mingw running and have been using it to port
> some other stuff to windows ...
>
> /Kai
>
>> Hm, you are right ... ;-)
>>
>> Did you find out how to fix it?
>>
>>
>> On Tue, Oct 13, 2009 at 1:03 AM, Kai Tetzlaff <kai.tetzl...@gmx.de> wrote:
>>> Gary Oberbrunner wrote:
>>>> emacsclientw exits with a random exit status when called from a win32
>>>> window app (such as emacs itself). The reason is an uninitialized
>>>> variable in w32_teardown_window in w32emacsclient.h. I suspect if "ret"
>>>> is initialized to zero (exit status success) in this function it would
>>>> just work. I don't have mingw so I can't compile it here myself, sorry.
>>>>
>>>> This is on emacs 23.1.50, also happens on the latest CVS test version.
>>>> I'm using the EmacsW32 patched version on XP, but don't think that matters
>>>> either.
>>>>
>>>> The symptom is easy to reproduce. In a shell window inside emacs (I use
>>>> cygwin zsh, but any shell will work), run
>>>> emacsclient foo || echo BAD
>>>> then C-x # to close the server buffer, and then look back in the shell
>>>> window:
>>>> % emacsclientw foo || echo BAD
>>>> Waiting for Emacs...
>>>> BAD
>>>> %
>>>>
>>>> (I'm sure you already know that "emacsclient", the non-windows version, is
>>>> totally broken, gives "Unknown&_command:&"... but emacsclientw is fine so
>>>> it doesn't really matter.)
>>>>
>>>> Here's the affected code:
>>>> ===========
>>>> int
>>>> w32_teardown_window (int connected)
>>>> {
>>>> int ret; <<<<<<<<<<====== FIX HERE to int ret=0;
>>>> if (w32_window_app ())
>>>> {
>>>> w32_check_not_synced();
>>>> w32_wait_threads_fin(connected);
>>>> ret = W32_SYNC_get_g_exit_value();
>>>> DeleteCriticalSection(&g_cs.cs);
>>>> return ret;
>>>> }
>>>> else
>>>> ret = g_exit_value;
>>>> return ret;
>>>> }
>>>> ============
>>>>
>>>>
>>> I've also been running into this. Now, when looking at the code of what
>>> i believe should be the patched version of emacsclient.c, the main
>>> function looks like this:
>>>
>>> int
>>> main (argc, argv)
>>> int argc;
>>> char **argv;
>>> {
>>> int i, rl, needlf = 0;
>>> char *cwd, *str;
>>> char string[BUFSIZ+1];
>>> int connected = 0;
>>>
>>> ...
>>>
>>> if ((emacs_socket = set_socket ( alternate_editor ||
>>> (start_timeout_int > 0) , &islocal)) == INVALID_SOCKET)
>>> {
>>> ...
>>> connected = 1;
>>> }
>>>
>>> ...
>>>
>>> int exitval = finish_messages (connected);
>>>
>>> if (connected)
>>> exit(exitval);
>>> else
>>> exit(EXIT_FAILURE);
>>> }
>>>
>>> I.e. if connected is not set to a non-zero value somewhere after it gets
>>> initialized, main will always exit with EXIT_FAILURE.
>>>
>>> The only place in main which sets connected is the if block included
>>> above. This block is only entered if set_socket returns INVALID_SOCKET
>>> which seems to be the case only if the server has not been started yet.
>>> So if you use emacsclient to send files to the server when it is already
>>> running, it will always seem to be failing.
>>>
>>> BR,
>>> Kai
>>>
>>>
>>>
>>>
>>
>
>
>
>
