Re: bug#13701: 24.2.93; Segmentation fault

[Sebastien Vauban]

Hi Thierry,

I'm replying with things I know are facts, in order for others not to be
confused by the configuration in which problems do appear.

Thierry Volpiatto wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>> Thierry Volpiatto wrote:
>>> Glenn Morris <rgm@gnu.org> writes:
>>>> "Sebastien Vauban" wrote:
>>>>
>>>>> warning: sys_read called when read is in progress
>>>>
>>>> Searching for this message, I found that the only hit is crashes
>>>> previously reported by you in Emacs 24.1 and 24.2:
>>>>
>>>> http://lists.gnu.org/archive/html/help-gnu-emacs/2012-10/msg00021.html
>>>>
>>>> So maybe the issue(s) is not new and is caused by some unusual
>>>> circumstance on your machine.
>>>
>>> The initial problem was the user is setting `shell-file-name' to
>>> "/path/to/bash" on a windows machine where the value is normally
>>> "/path/to/cmdproxy.exe". The result is that all externals programs made to
>>> be used with "cmdproxy.exe" are crashing Emacs. In the case of `helm', the
>>> user is crashing Emacs with the helm-locate command which use the
>>> executable "es.exe" which is part of "everything" program. So I think
>>> these crash are not the fault of Emacs nor helm, but a bad setting of
>>> user.
>>>
>>> So the question is: Sebastien, are you still using shell-file-name==bash
>>> in your config ?
>>
>> The answer is yes:
>>
>>   ╭────
>>   │ shell-file-name is a variable defined in `C source code'.
>>   │ Its value is "c:/cygwin/bin/bash.exe"
>>   ╰────
>>
>> IIRC, I was asked by Eli (or, at the very least, allowed) to set back Bash
>> as my inferior shell.
>>
>> FYI, I'm using that setting since 1999, when I began really working with
>> Emacs, and it did not cause any problems either with Helm (in that time,
>> Anything) for the last years in which I used it (at least, from 2010).
>
> At the beginning of anything, locate was not implemented for windows with
> "everything"

When was that true?  Not anymore in 2010.

> probably helm is working without crash if you use the locate executable of
> your cygwin stuff instead of "everything".

No, never ever. Cygwin's locate is _not_ installed by default. And, in fact,
is not straightforward to get it installed and have it run every day or so.
You need to pass thru a long list of steps, much longer than simply selecting
the package and expecting it to be up and running (and up-to-date).

So, I never did use Cygwin locate at all.

When I say I used Anything back in 2010, it was already with Everything (and
es.exe).

> So I repeat that helm itself is NOT crashing Emacs, but the backend used by
> helm in an unsupported shell IS crashing Emacs.

Yes, when I refer to Helm, I never pinpoint it as being buggy. I refer to its
use, from the user perspective, and something somehow that breaks Emacs when
being used.

>> Problems began appearing with Emacs 24, IIRC.
>
> This is not related to Emacs-24 IMO, same problem would happen in Emacs-23
> in same context.

I really don't remember Emacs crashes with Emacs 23, with that same set of
tools:

- Bash (or Zsh) as my inferior shell in Emacs
- Helm (or Anything) with Everything (es.exe)

That did work, from 2010 to somewhere a couple of months ago.

>> That does not mean I absolutely have to keep that setting, but this is _by
>> far_ my preferred one, as I'm using Cygwin Bash (or Zsh) all around the
>> place, and I want to be able to do the exact same thing from withing Emacs:
>> for example, calling one of my script on a selected region, or things like
>> that.
>
> Probably you should let-bind `shell-file-name' to "bash" or whatever when
> calling your scripts from Emacs and leave the global value to its default
> setting.

By advicing shell-command-on-region and family?

> That say, probably Emacs should detect when calling a process if the
> executable is compatible with value of `shell-file-name' and throw a big old
> error if so before crashing Emacs, don't know if that is possible though.
> (probably it is what Eli want to fix)

I'll let them guide me toward the long-term solution.

Best regards,
  Seb

-- 
Sebastien Vauban