Uday S Reddy <uDOTsDOTreddy@xxxxxxxxxxxxx> writes:
> blueman wrote:
>> My patch has been tested and works on multiple different types of
>> commands. If you have an example that doesn't work, please post it so I
>> can replicate it...
> Ok, thanks for sharing that. If you are going to act as the developer
> for now, then here it goes.
Thanks - I really do want to help
> The behaviour I am getting is basically that whenever I mark multiple
> messages and run `|s' with cat as the command, Emacs freezes. The
> only way to recover is to forcibly kill the cat process in the task
> manager. Then I see messages like:
> Next command uses marks...
> vm-pipe-messages-to-command: writing to process:
> CCL: Quited., cat
> Next command uses marks...
> vm-pipe-messages-to-command: writing to process: invalid argument,
> in the *Messages* buffer. It doesn't seem to matter what messages I
> try it on.
> When I try it on a single message, it often works.
This is interesting. Because for me "|s" with cat worked even before my
patches. It only failed when I tried either to set the optional variable
DISCARD-OUTPUT or when I tried to use it asynchronously by setting the
NO-WAIT exit handler. These problems were due to a combination of the
"missing" command argument and the missing comma in front of no-wait --
all of which only surfaced when the optional variables were set to
Now it seems like you are having problems with the command itself. This
is actually good since it elminates the complexity of the problem being
with some funky exit handler you were writing ;)
> This is the behaviour I see with my patched version which is on
> launchpad, as well as the patches you posted today.
> If you want me to post something that will help diagnose the problem,
> then you need to tell me what you want to send and where to send it
If you have access to Linux, I would suggest trying there to see whether
this can be attributed to a cygwin problem. I tested mine on the 1.7
version of cygwin which may still be beta and also I was using ntemacs
rather than cygwin emacs so are Windows platforms may be different.
That being said, check what the value of the variable shell-file-name
is. If you are using ntemacs then that gets set by default to
"C:/My Programs/Emacs/bin/cmdproxy.exe" which results in a Windows
shell. I set the shell to "C:/cygwin/bin/bash.exe" and it all works
The difference between vm-pipe-message-to-command and
vm-pipe-messages-to-command is that the first one uses
"call-process-region" while the 2nd one first starts the process using
"start-process" and then sends it input.
As a test try running:
(tart-process "test" "tempbuff" shell-file-name shell-command-switch "cat >
When shell-file-name = "C:/cygwin/bin/bash.exe" the process starts
When shell-file-name = "C:/cygwin/bin/bash.exe" the process fails to start.
> The other problem that I saw with your original patch, to do with the
> command' variable, didn't arise today. But I haven't checked closely
> to see whether the problem code was getting exercised or not.
> There is some merit in the rest of the arguments in your message that
> I will think about.
> I am not 'fixated' on my code. If it is faulty, I am quite happy to
> retract it. It happens all the time! But I think this message was
> the first instance where you have talked about anything going
> wrong. So, thanks for getting to the point!