|
From: | Oleksandr Gavenko |
Subject: | Re: Why call-process removes '{' and '}' chars from arguments??? |
Date: | Thu, 03 Jun 2010 23:33:44 +0300 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 |
On 2010-06-03 18:04, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:46 AM, Oleksandr Gavenko wrote:On 2010.06.03 0:39, Eli Zaretskii wrote:From: Oleksandr Gavenko<gavenkoa@gmail.com> Date: Wed, 02 Jun 2010 23:40:46 +0300 I use Emacs 23.2 under Windows. (call-process "echo.exe" nil (get-buffer "*Messages*") nil "--bla" "{rev}" "}}}xxx{1}xxx{2}xxx{{{" ) put in Message buffer "--bla rev }}}xxx1xxx2xxx" so remove occurrences of "{" and "}". Why???I cannot reproduce this in Emacs 23.2 on MS-Windows. I get the expected result: --bla {rev} }}}xxx{1}xxx{2}xxx{{{ What kind of port of which program is your echo.exe? What happens if you invoke the same command from the shell?Futher info: I wrote simple C prog - printarg.c with: int main(int argc, char **argv) { for (int i = 0; i < argc; i++) printf("\"%s\"\n", argv[i]); return 0; } When I compile it with CC=gcc # resulted executable depend on cygwin1.dll (call-process "printarg.exe" nil (get-buffer "*Messages*") nil "--bla" "{rev}" "}}}xxx{1}xxx{2}xxx{{{" ) return "/home/user/usr/bin/printarg" "--bla" "rev" "}}}xxx1xxx2xxx" When I compile it with CC=i686-pc-cygwin-gcc-3 -mno-cygwin # resulted executable *NOT* depend on cygwin1.dll call-process return "d:\home\usr\bin\printarg.exe" "--bla" "{rev}" "}}}xxx{1}xxx{2}xxx{{{" Also interesting that from Cygwin bash argument successful passed to printarg: bash# ldd `which printarg` ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll cygwin1.dll => /usr/bin/cygwin1.dll ADVAPI32.DLL => /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL RPCRT4.dll => /cygdrive/c/WINDOWS/system32/RPCRT4.dll Secur32.dll => /cygdrive/c/WINDOWS/system32/Secur32.dll cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll bash# printarg {}{}{{{{}}}{}}}{{} {rev} "printarg" "{}{}{{{{}}}{}}}{{}" "{rev}" GNU Emacs 23.2 from ftp.gnu.org - release build with mingw.See <http://cygwin.com/cygwin-ug-net/using-cygwinenv.html> and try setting the CYGWIN environment variable to include "noglob".
That is!!!! Much thanks. I explain that I have. Cygwin distro have Mercurial package inside. 'cygwin.el' allow incorporate Emacs with Cygwin without any pain. But native Windows Emacs can not run scripts (in Cygwin - these are files without ext with usual UNIX #!/bin/bla-bla first string). To be able invoke it from Emacs I wrote .bat wrappers with same base name for needed scripts like: @echo off python /bin/hg %* With CYGWIN env var set to "nodosfilewarning noglob" and wrapper I can use VC mode for Mersurial/Bazaar repos (without 'nodosfilewarning' script output can be damaged by Cygwin warning messages). That work pretty nice if there are no new line char in passed to .bat file args. As I debug 'log-edit-done' it can pass such command line (through 'process-file' in 'vc-do-command') switches for Mercurial: (apply 'process-file "hg" nil t nil '("commit" "-m" "message\nXXX\nYYY\nZZZ\n")) %* in .bat file not proper work - it strip all chars after first new line occurrence. I think in Windows there are no anything scriptable with "$*" like in POSIX sh. So through .bat wrapper I can not commit multiline message and as list of files for commit goes after -m "message\n" - it also forget pass list of files for commit. So if I commit single file - it commit all modified files in repo. To workaround this I create executable which linked with Cygwin runtime and as in BusyBox to 'execvp' passed base name as command and all args without changes. Cygwin 'execvp' first search for 'prog' then for 'prog.exe' so trick worked! So I switch from simple .bat wrapper to special executable. To enable another Cygwin script 'foo' for Emacs I just copy existing executable: $ cp hg.exe foo.exeSome further info accessed at http://www.mail-archive.com/cygwin@cygwin.com/msg109064.html
-- Best regards!
[Prev in Thread] | Current Thread | [Next in Thread] |