bug#7785: rgrep is broken on woe32

bug#7785: rgrep is broken on woe32

[Sam Steingold]

GNU Emacs 23.2.1 (i386-mingw-nt5.2.3790)
 of 2010-05-08 on G41R2F1
--with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include

(custom-set-variables
 '(grep-find-use-xargs 'gnu)
 '(grep-use-null-device nil))


(rgrep "ff-" ".emacs" "d:/.../" nil)

=======================================
-*- mode: grep; default-directory: "d:/.../" -*-
Grep started at Tue Jan 04 18:42:28

c:/gnu/cygwin/bin/find . \( -path  -o -path \*/attic -o -path \*/junk
-o -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o
-path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o
-path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \) -prune -o \(
-name .\#\* -o -name \*.bc -o -name \*.exe -o -name \*.cmxa -o -name
\*.cmx -o -name \*.cmo -o -name \*.cmi -o -name \*.cma -o -name
\*.spit -o -name \*.spot -o -name \*.omc -o -name \*.data -o -name
\*.old -o -name \*.tmp -o -name \*.annot -o -name \*.p -o -name \*.err
-o -name \*.o -o -name \*\~ -o -name \*.bin -o -name \*.bak -o -name
\*.obj -o -name \*.map -o -name \*.ico -o -name \*.pif -o -name \*.lnk
-o -name \*.a -o -name \*.ln -o -name \*.blg -o -name \*.bbl -o -name
\*.dll -o -name \*.drv -o -name \*.vxd -o -name \*.386 -o -name \*.elc
-o -name \*.lof -o -name \*.glo -o -name \*.idx -o -name \*.lot -o
-name \*.fmt -o -name \*.tfm -o -name \*.class -o -name \*.fas -o
-name \*.lib -o -name \*.mem -o -name \*.x86f -o -name \*.sparcf -o
-name \*.fasl -o -name \*.ufsl -o -name \*.fsl -o -name \*.dxl -o
-name \*.pfsl -o -name \*.dfsl -o -name \*.p64fsl -o -name \*.d64fsl
-o -name \*.dx64fsl -o -name \*.lo -o -name \*.la -o -name \*.gmo -o
-name \*.mo -o -name \*.toc -o -name \*.aux -o -name \*.cp -o -name
\*.fn -o -name \*.ky -o -name \*.pg -o -name \*.tp -o -name \*.vr -o
-name \*.cps -o -name \*.fns -o -name \*.kys -o -name \*.pgs -o -name
\*.tps -o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \) -prune -o
-type f \( -iname .emacs \) -print0 | xargs -0 -e grep -i -nH ff-
/usr/bin/find: invalid expression; I was expecting to find a ')'
somewhere but did not see one.

Grep finished with no matches found at Tue Jan 04 18:42:28
=======================================

when I paste the above command into a cygwin shell window, it works
just fine (finds what I need).
i.e., the () in the command are actually well balanced.


-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Óscar Fuentes]

Sam Steingold <sds@gnu.org> writes:

[snip]

> /usr/bin/find: invalid expression; I was expecting to find a ')'
> somewhere but did not see one.
>
> Grep finished with no matches found at Tue Jan 04 18:42:28
> =======================================
>
> when I paste the above command into a cygwin shell window, it works
> just fine (finds what I need).
> i.e., the () in the command are actually well balanced.

This looks like the string length restriction in cmdproxy.exe reported
in

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6674#74

It was patched, as indicated on the subsequent messages on that thread.

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 05 Jan 2011 02:05:27 +0100
> Cc: 7785@debbugs.gnu.org
> 
> Sam Steingold <sds@gnu.org> writes:
> 
> [snip]
> 
> > /usr/bin/find: invalid expression; I was expecting to find a ')'
> > somewhere but did not see one.
> >
> > Grep finished with no matches found at Tue Jan 04 18:42:28
> > =======================================
> >
> > when I paste the above command into a cygwin shell window, it works
> > just fine (finds what I need).
> > i.e., the () in the command are actually well balanced.
> 
> This looks like the string length restriction in cmdproxy.exe reported
> in
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6674#74
> 
> It was patched, as indicated on the subsequent messages on that thread.

Indeed.  Sam, please use the latest pretest of Emacs 23.3, where this
problem should be fixed.

Closing the bug.

bug#7785: rgrep is broken on woe32

[Sam Steingold]

I see the exact same  same error with the current bzr tip

bug#7785: rgrep is broken on woe32

[Sam Steingold]

when I edit the command line manually so that it is shorter than 1024 chars,
the error message becomes extra bizarre:



-*- mode: grep; default-directory: "d:/.../" -*-
Grep started at Wed Jan 05 15:27:21

c:/gnu/cygwin/bin/find . \( -path  -o -path \*/attic -o -path \*/junk
-o -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o
-path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o
-path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \) -prune -o \(
-name .\#\* -o -name \*.bc -o -name \*.exe -o -name \*.cmxa -o -name
\*.cmx -o -name \*.cmo -o -name \*.cmi -o -name \*.cma -o -name
\*.spit -o -name \*.spot -o -name \*.omc -o -name \*.data -o -name
\*.tp -o -name \*.vr -o -name \*.cps -o -name \*.fns -o -name \*.kys
-o -name \*.pgs -o -name \*.tps -o -name \*.vrs -o -name \*.pyc -o
-name \*.pyo \) -prune -o  -type f \( -iname \*.cc -o -iname
\*.\[ch\]xx -o -iname \*.\[ch\]pp -o -iname \*.\[CHh\] -o -iname \*.CC
-o -iname \*.HH -o -iname \*.\[ch\]\+\+ \) -print0 | xargs -0 -e grep
-i -nH gettempdir
'c:' is not recognized as an internal or external command,
operable program or batch file.

Grep exited abnormally with code 255 at Wed Jan 05 15:27:21




-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Óscar Fuentes]

Sam Steingold <sds@gnu.org> writes:

> when I edit the command line manually so that it is shorter than 1024 chars,
> the error message becomes extra bizarre:

[snip]

Maybe you are mixing Cygwin's find with gnuwin32 grep ?

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Wed, 5 Jan 2011 15:28:48 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 7785@debbugs.gnu.org
> 
> 'c:' is not recognized as an internal or external command,
> operable program or batch file.

This message comes from cmd.exe, the native Windows shell.  Since you
probably have a setup where the Cygwin Bash should have been called, I
suspect some snafu with setting up Emacs for Cygwin.  Can you try the
same with native Windows ports of find, xargs, and grep, and in
"emacs -Q"?

Also, what does this mean:

-*- mode: grep; default-directory: "d:/.../" -*-
                                    ^^^^^^^
Could it be that this is the culprit?

FWIW, I just tried that with Emacs 23.2.91, the latest pretest, and
with the trunk of Emacs 24 built a few days ago, and the same command
as you invoked works for me, except that the last argument is not
"d:/.../", but a valid directory.  But my Findutils are native Windows
programs, and the shell is the native Windows shell.

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Wed, Jan 5, 2011 at 3:50 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Sam Steingold <sds@gnu.org> writes:
>
>> when I edit the command line manually so that it is shorter than 1024 chars,
>> the error message becomes extra bizarre:
>
> [snip]
>
> Maybe you are mixing Cygwin's find with gnuwin32 grep ?
>

no, I am not.
here is the same error with the full paths:

-*- mode: grep; default-directory: "d:/.../" -*-
Grep started at Wed Jan 05 16:18:46

c:/gnu/gnuwin32/bin/find . \( -path  -o -path \*/attic -o -path
\*/junk -o -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path
\*/MCVS -o -path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path
\*/.bzr -o -path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \)
-prune -o \( -name .\#\* -o -name \*.bc -o -name \*.exe -o -name
\*.cmxa -o -name \*.cmx -o -name \*.cmo -o -name \*.cmi -o -name
\*.cma -o -name \*.spit -o -name \*.spot -o -name \*.omc -o -name
\*.data -o -name \*.old -o -name \*.tmp -o -name \*.annot -o -name
\*.p -o -name \*.err -o -name \*.o -o -name \*\~ -o -name \*.bin -o
-name \*.bak -o -name \*.obj -o -name \*.map -o -name \*.ico -o -name
\*.pif -o -name \*.lnk -o -name \*.a -o -name \*.ln -o -name \*.blg -o
-name \*.bbl -o -name \*.dll -o -name \*.drv -o -name \*.vxd -o -name
\*.386 -o -name \*.elc -o -name \*.lof -o -name \*.glo -o -name \*.idx
-o -name \*.lot -o -name \*.fmt -o -name \*.tfm -o -name \*.class -o
-name \*.fas -o -name \*.lib -o -name \*.mem -o -name \*.x86f -o -name
\*.sparcf -o -name \*.fasl -o -name \*.ufsl -o -name \*.fsl -o -name
\*.dxl -o -name \*.pfsl -o -name \*.dfsl -o -name \*.p64fsl -o -name
\*.d64fsl -o -name \*.dx64fsl -o -name \*.lo -o -name \*.la -o -name
\*.gmo -o -name \*.mo -o -name \*.toc -o -name \*.aux -o -name \*.cp
-o -name \*.fn -o -name \*.ky -o -name \*.pg -o -name \*.tp -o -name
\*.vr -o -name \*.cps -o -name \*.fns -o -name \*.kys -o -name \*.pgs
-o -name \*.tps -o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \)
-prune -o  -type f \( -iname \*.cc -o -iname \*.\[ch\]xx -o -iname
\*.\[ch\]pp -o -iname \*.\[CHh\] -o -iname \*.CC -o -iname \*.HH -o
-iname \*.\[ch\]\+\+ \) -print0 | c:/gnu/gnuwin32/bin/xargs -0 -e
c:/gnu/gnuwin32/bin/grep -i -nH gettempdir
'c:' is not recognized as an internal or external command,
operable program or batch file.

Grep exited abnormally with code 255 at Wed Jan 05 16:18:47





-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Wed, 5 Jan 2011 16:20:13 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 7785@debbugs.gnu.org
> 
> c:/gnu/gnuwin32/bin/find . \( -path  -o -path \*/attic -o -path
> ...
> \*.\[ch\]pp -o -iname \*.\[CHh\] -o -iname \*.CC -o -iname \*.HH -o
> -iname \*.\[ch\]\+\+ \) -print0 | c:/gnu/gnuwin32/bin/xargs -0 -e
> c:/gnu/gnuwin32/bin/grep -i -nH gettempdir
> 'c:' is not recognized as an internal or external command,
> operable program or batch file.

So are you using find/grep/xargs from GnuWin32 or from Cygwin?  Or is
the error the same regardless?

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Wed, 5 Jan 2011 16:20:13 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 7785@debbugs.gnu.org
> 
> -iname \*.\[ch\]\+\+ \) -print0 | c:/gnu/gnuwin32/bin/xargs -0 -e
> c:/gnu/gnuwin32/bin/grep -i -nH gettempdir
> 'c:' is not recognized as an internal or external command,
> operable program or batch file.

I think forward slashes are not supported in the pipe parts after the
first `|'.  Only the first command gets its slashes mirrored.  Can you
try adding "c:\gnu\gnuwin32\bin" to your PATH (Emacs will need to be
restarted afterwards)?

If that doesn't help, can you try with GnuWin32 ports, but configure
rgrep not to use xargs?

bug#7785: rgrep is broken on woe32

[Óscar Fuentes]

Sam Steingold <sds@gnu.org> writes:

>> Maybe you are mixing Cygwin's find with gnuwin32 grep ?
>>
>
> no, I am not.
> here is the same error with the full paths:

[snip]

Maybe it is related to this:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6784

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Wed, Jan 5, 2011 at 5:29 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
> Maybe it is related to this:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6784
>

definitely. is that bug going to be fixed?

-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Wed, Jan 5, 2011 at 4:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 5 Jan 2011 15:28:48 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, 7785@debbugs.gnu.org
>>
>> 'c:' is not recognized as an internal or external command,
>> operable program or batch file.
>
> This message comes from cmd.exe, the native Windows shell.  Since you
> probably have a setup where the Cygwin Bash should have been called, I
> suspect some snafu with setting up Emacs for Cygwin.  Can you try the
> same with native Windows ports of find, xargs, and grep, and in
> "emacs -Q"?

this works just fine, like on linux:
PATH=/cygdrive/c/gnu/gnuwin32/bin:$PATH emacs -q

moreover,
emacs -q
and moving gnuwin dir to the beginning of exec-path with
(let ((gw "c:/gnu/gnuwin32/bin"))
  (setq exec-path (cons gw (delete gw exec-path))))
also works fine.

however, without "-q" I get various errors, mostly
"FIND: Parameter format not correct"
despite exec-paths starting with gnuwin32.
this is obviously my problem now; however, I would appreciate it if
you could help me out.


> Also, what does this mean:
>
> -*- mode: grep; default-directory: "d:/.../" -*-
>                                    ^^^^^^^
> Could it be that this is the culprit?

no, I am merely removing the long directory name from the pasted buffer content.

-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Sam Steingold]

additional points of information:
exec-path is not always used for subprocesses
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7793)
so I have to modify process-environment too:
after fixing exec-path:

  (let ((tail process-environment))
    (while tail
      (when (string-match "^PATH=" (car tail))
        (setcar tail (concat "PATH="
                             (mapconcat (lambda (s)
                                          (subst-char-in-string ?/ ?\\ s))
                                        exec-path ";")))
        (setq tail nil))        ; done
      (setq tail (cdr tail))))

now:

==========================================================
-*- mode: grep; default-directory: "c:/" -*-
Grep started at Wed Jan 05 18:44:10

find . \( -path  -o -path \*/attic -o -path \*/junk -o -path \*/SCCS
-o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o -path \*/.svn -o
-path \*/.git -o -path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o
-path \*/_darcs -o -path \*/\{arch\} \) -prune -o \( -name .\#\* -o
-name \*.bc -o -name \*.exe -o -name \*.cmxa -o -name \*.cmx -o -name
\*.cmo -o -name \*.cmi -o -name \*.cma -o -name \*.spit -o -name
\*.spot -o -name \*.omc -o -name \*.data -o -name \*.old -o -name
\*.tmp -o -name \*.annot -o -name \*.p -o -name \*.err -o -name \*.o
-o -name \*\~ -o -name \*.bin -o -name \*.bak -o -name \*.obj -o -name
\*.map -o -name \*.ico -o -name \*.pif -o -name \*.lnk -o -name \*.a
-o -name \*.ln -o -name \*.blg -o -name \*.bbl -o -name \*.dll -o
-name \*.drv -o -name \*.vxd -o -name \*.386 -o -name \*.elc -o -name
\*.lof -o -name \*.glo -o -name \*.idx -o -name \*.lot -o -name \*.fmt
-o -name \*.tfm -o -name \*.class -o -name \*.fas -o -name \*.lib -o
-name \*.mem -o -name \*.x86f -o -name \*.sparcf -o -name \*.fasl -o
-name \*.ufsl -o -name \*.fsl -o -name \*.dxl -o -name \*.pfsl -o
-name \*.dfsl -o -name \*.p64fsl -o -name \*.d64fsl -o -name
\*.dx64fsl -o -name \*.lo -o -name \*.la -o -name \*.gmo -o -name
\*.mo -o -name \*.toc -o -name \*.aux -o -name \*.cp -o -name \*.fn -o
-name \*.ky -o -name \*.pg -o -name \*.tp -o -name \*.vr -o -name
\*.cps -o -name \*.fns -o -name \*.kys -o -name \*.pgs -o -name \*.tps
-o -name \*.vrs -o -name \*.pyc -o -name \*.pyo \) -prune -o  -type f
\( -iname \*.el \) -print0 | xargs -0 -e grep -i -nH gnu.org
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]

Grep finished (matches found) at Wed Jan 05 18:44:10
==========================================================

the error message is obviously from gnu find, but I don't see what is
wrong with the command line.

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Wed, Jan 5, 2011 at 6:49 PM, Sam Steingold <sds@gnu.org> wrote:
>
>  (let ((tail process-environment))
>    (while tail
>      (when (string-match "^PATH=" (car tail))
>        (setcar tail (concat "PATH="
>                             (mapconcat (lambda (s)
>                                          (subst-char-in-string ?/ ?\\ s))
>                                        exec-path ";")))
>        (setq tail nil))        ; done
>      (setq tail (cdr tail))))

replaced with
  (setenv "PATH"
          (mapconcat (lambda (s) (subst-char-in-string ?/ ?\\ s))
                     exec-path ";"))

same error:

> find: paths must precede expression
> Usage: find [-H] [-L] [-P] [path...] [expression]

-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Wed, 5 Jan 2011 17:45:42 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
> 
> this works just fine, like on linux:
> PATH=/cygdrive/c/gnu/gnuwin32/bin:$PATH emacs -q
> 
> moreover,
> emacs -q
> and moving gnuwin dir to the beginning of exec-path with
> (let ((gw "c:/gnu/gnuwin32/bin"))
>   (setq exec-path (cons gw (delete gw exec-path))))
> also works fine.
> 
> however, without "-q" I get various errors, mostly
> "FIND: Parameter format not correct"
> despite exec-paths starting with gnuwin32.
> this is obviously my problem now; however, I would appreciate it if
> you could help me out.

If this is still relevant (i.e. you still don't know which of your
customizations break what works with "emacs -q"), then can you bisect
your .emacs to see the reason? or post here the whole file?

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Wed, 5 Jan 2011 18:49:54 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
> 
> so I have to modify process-environment too:
> after fixing exec-path:

I suggest to fix PATH outside Emacs instead.  I wrote in bug#7793 why.

> \( -iname \*.el \) -print0 | xargs -0 -e grep -i -nH gnu.org
> find: paths must precede expression
> Usage: find [-H] [-L] [-P] [path...] [expression]
> 
> Grep finished (matches found) at Wed Jan 05 18:44:10
> ==========================================================
> 
> the error message is obviously from gnu find, but I don't see what is
> wrong with the command line.

Which find/xargs/grep are these -- Cygwin's or GnuWin32's?

Also, you said just a couple of messages ago, that rgrep did work for
you in "emacs -q".  So is the only difference between that and this
whatever you have on your .emacs?  Or am I missing something else?

There's something else I don't understand.  The style of shell quoting
you show, viz.

  find . \( -path  -o -path \*/attic -o -path \*/junk -o -path \*/SCCS
  -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o -path \*/.svn -o
  -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o

is different from what I see on my Windows box:

  find . "(" -path  -o -path "*/attic" -o -path "*/junk" -o -path "*/SCCS"
  -o -path "*/RCS" -o -path "*/CVS" -o -path "*/MCVS" -o -path "*/.svn" -o
  -path "*/.git" -o -path "*/.hg" -o -path "*/.bzr" -o -path "*/_MTN" -o

That is, Emacs is supposed to use double quotes on Windows, because
Windows programs (except Cygwin) don't understand quoting with a
backslash.  Do you see the former style of quoting in "emacs -Q" as
well?

bug#6784: bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
> 	RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,T_DKIM_INVALID autolearn=ham version=3.3.1
> Date: Wed, 5 Jan 2011 17:43:15 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 7785@debbugs.gnu.org
> 
> On Wed, Jan 5, 2011 at 5:29 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> >
> > Maybe it is related to this:
> >
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6784
> >
> 
> definitely. is that bug going to be fixed?

The discussions in that bug report concluded that the program file
name after the pipe needs to be quoted, in order for it to work with
file names that use forward- and back-slashes alike.  I can solve that
problem for rgrep (and for other similar commands) by tweaking the
templates used by grep.el, so as to quote the %s after the pipe
character `|'.  Would that be an okay solution?

The other alternative I thought about, to fix this inside cmdproxy,
has a disadvantage that the command semantics cannot be easily
determined at such a low level.  The first word after the `|' might
not always be a name of an executable file, or it could already be
quoted in some ingenious ways, or it might be a part of a quoted pipe
that is intended to survive unaltered, to be passed to some other
program and not executed as a shell pipeline.  Even if we teach
cmdproxy about all of these use-cases and write/debug code to handle
each and every one of them, we will certainly miss some.  We will also
force this quoting on commands typed interactively, so users lose the
fire escape they can use now to quote or not to quote.

As a general principle, I believe that the level which conses the
command line is where such decision should be made, because that level
surely knows the context, and knows _exactly_ where are the parts that
need quoting.

The disadvantage is, of course, that similar solutions will have to be
implemented for each Emacs command that launches a shell pipeline.
But I don't believe there are many of those.

Comments?

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Thu, Jan 6, 2011 at 5:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 5 Jan 2011 18:49:54 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
>>
>> so I have to modify process-environment too:
>> after fixing exec-path:
>
> I suggest to fix PATH outside Emacs instead.  I wrote in bug#7793 why.

is it safe to prepend gnuwin path before the system windows paths
globally for all programs?
my toolchain is not limited to the gnu world, I am afraid of breaking,
e.g., ms visual studio...

>> \( -iname \*.el \) -print0 | xargs -0 -e grep -i -nH gnu.org
>> find: paths must precede expression
>> Usage: find [-H] [-L] [-P] [path...] [expression]
>>
>> Grep finished (matches found) at Wed Jan 05 18:44:10
>> ==========================================================
>>
>> the error message is obviously from gnu find, but I don't see what is
>> wrong with the command line.
>
> Which find/xargs/grep are these -- Cygwin's or GnuWin32's?

it should be gnuwin.

> Also, you said just a couple of messages ago, that rgrep did work for
> you in "emacs -q".  So is the only difference between that and this
> whatever you have on your .emacs?  Or am I missing something else?

1. "emacs -Q" started from bash shell:

(getenv "PATH")
"C:\\gnu\\cygwin\\usr\\local\\bin;C:\\gnu\\cygwin\\bin;C:\\gnu\\cygwin\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;C:\\gnu\\gnuwin32\\bin;C:\\gnu\\cygwin\\bin;D:\\bin;C:\\Program
Files (x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"

find . "(" -path "*/SCCS" -o -path "*/RCS" -o -path "*/CVS" -o -path
"*/MCVS" -o -path "*/.svn" -o -path "*/.git" -o -path "*/.hg" .....
-exec grep -i -nH "asdf" {} NUL ";"

grep: NUL: No such file or directory
grep: NUL: No such file or directory
grep: NUL: No such file or directory
grep: NUL: No such file or directory
grep: NUL: No such file or directory

i.e., cygwin tools are used, which sucks because of NULs but at least
things sort of work.

2. emacs started from cygwin bash shell, the only thing in .emacs:
  (let ((gw "c:/gnu/gnuwin32/bin"))
    (setq exec-path (cons gw (delete gw exec-path))))
  (setenv "PATH"
          (mapconcat (lambda (s) (subst-char-in-string ?/ ?\\ s))
                     exec-path ";"))

(getenv "PATH")
"c:\\gnu\\gnuwin32\\bin;c:\\gnu\\cygwin\\usr\\local\\bin;C:\\gnu\\cygwin\\bin;C:\\gnu\\cygwin\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;C:\\gnu\\gnuwin32\\bin;C:\\gnu\\cygwin\\bin;D:\\bin;C:\\Program
Files (x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin;c:\\sds\\src\\emacs\\trunk\\bin"


find . "(" -path "*/SCCS" -o -path "*/RCS" -o -path "*/CVS"
-o.....-name "*.kys" -o -name "*.pgs" -o -name "*.tps" -o -name
"*.vrs" -o -name "*.pyc" -o -name "*.pyo" ")" -prune -o  -type f "("
-iname "*" -o -iname ".*" ")" -print0 | xargs -0 -e grep -i -nH "sfdg"
xargs: grep: No such file or directory
grep: ./src/clisp/current/src/config: No such file or directory
find: write error: Invalid argument

i.e., apparently, gnuwin tools are used, but nothing works.

3. emacs started with the above .emacs from the desktop shortcut

(getenv "PATH")
"c:\\gnu\\gnuwin32\\bin;c:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program Files
(x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin;c:\\sds\\src\\emacs\\trunk\\bin"


find . "(" -path "*/SCCS" -o -path "*/RCS" -o -path "*/CVS" ..... -o
-name "*.pyo" ")" -prune -o  -type f "(" -iname "*" -o -iname ".*" ")"
-print0 | xargs -0 -e grep -i -nH "adsf"
xargs: grep: No such file or directory
grep: ./src/clisp/curr: No such file or directory
find: write error: Invalid argument

i.e., same problems as before.

4. emacs started from desktop with my full huge .emacs but without PATH tweaking

(getenv "PATH")
"C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;c:\\gnu\\gnuwin32\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program
Files (x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"

c:/gnu/gnuwin32/bin/find . \( -path  -o -path \*/attic ..... -o -iname
Makefile\* -o -iname \*.xml \) -print0 | c:/gnu/gnuwin32/bin/xargs -0
-e c:/gnu/gnuwin32/bin/grep -i -nH sadf
'c:' is not recognized as an internal or external command,
operable program or batch file.

5. same as 4 but without setting find-program et al
FIND: Parameter format not correct

6. emacs started from desktop with my full huge .emacs with PATH
tweaking without setting find-program et al:

(getenv "PATH")
"c:\\gnu\\gnuwin32\\bin;c:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program Files
(x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin;c:\\sds\\src\\emacs\\trunk\\bin"

find . \( -path  -o -path \*/attic -o -path .....-iname \*.in -o
-iname Makefile\* -o -iname \*.xml \) -print0 | xargs -0 -e grep -i
-nH asdf
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]

7. emacs -Q started from desktop:

(getenv "PATH")
"C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;c:\\gnu\\gnuwin32\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program
Files (x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"

find . "(" -path "*/SCCS" ... -name "*.pyc" -o -name "*.pyo" ")"
-prune -o  -type f "(" -iname "*" -o -iname ".*" ")" -exec grep -i -nH
"rg	" {} NUL ";"
FIND: Parameter format not correct


-- 
Sam Steingold <http://sds.podval.org>

bug#6784: bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Thu, Jan 6, 2011 at 7:09 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 5 Jan 2011 17:43:15 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 7785@debbugs.gnu.org
>>
>> On Wed, Jan 5, 2011 at 5:29 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6784
>> definitely. is that bug going to be fixed?
> ... Would that be an okay solution?

any solution which fixes my problem is OK :-)

> Comments?

the problems you describe seem to boil down to re-implementing cmd in cmdproxy.
this begs the question, why does emacs have to provide cmdproxy?
why not use cmd provided by windows?

-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Thu, Jan 6, 2011 at 10:17 AM, Sam Steingold <sds@gnu.org> wrote:
> On Thu, Jan 6, 2011 at 5:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Wed, 5 Jan 2011 18:49:54 -0500
>>> From: Sam Steingold <sds@gnu.org>
>>> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
>>>
>>> so I have to modify process-environment too:
>>> after fixing exec-path:
>>
>> I suggest to fix PATH outside Emacs instead.  I wrote in bug#7793 why.
>
> is it safe to prepend gnuwin path before the system windows paths
> globally for all programs?
> my toolchain is not limited to the gnu world, I am afraid of breaking,
> e.g., ms visual studio...
>
> 1. "emacs -Q" started from bash shell:
> broken...
> 2. emacs started from cygwin bash shell, the only thing in .emacs:
> broken...
> 3. emacs started with the above .emacs from the desktop shortcut
> broken...
> 4. emacs started from desktop with my full huge .emacs but without PATH tweaking
> broken....
> 5. same as 4 but without setting find-program et al
> broken....
> 6. emacs started from desktop with my full huge .emacs with PATH
> tweaking without setting find-program et al:
> broken....
> 7. emacs -Q started from desktop:
> broken

8. emacs -Q started from desktop with gnuwin put as the first element
of PATH globally:

(getenv "PATH")
"c:\\gnu\\gnuwin32\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program Files
(x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"

find . "(" -path "*/SCCS" -o -path "*/RCS"...-o -name "*.pyo" ")"
-prune -o  -type f "(" -iname "*" -o -iname ".*" ")" -print0 | xargs
-0 -e grep -i -nH "asdf"
xargs: grep: No such file or directory
./src/clisp/current/src/ChangeLog:29:	* modules/asdf/asdf.lisp: update
to upstream "2.011"
./src/clisp/current/src/ChangeLog:512:	bundle ASDF2 as a module
./src/clisp/current/src/ChangeLog:513:	* Makefile.devel (update-asdf):
new .PHONY target
./src/clisp/current/src/ChangeLog:515:	* modules/asdf: add (based on asdf 2.008)
./src/clisp/current/src/ChangeLog:516:	* makemake.in, unix/INSTALL:
mention asdf in the docs
./src/clisp/current/src/ChangeLog:590:	(require): use the above, now
one can hook asdf into clisp
grep: ./src/clisp/c: No such file or directory
find: write error: Invalid argument

sort of works, except these bugs in output:
1. "xargs: grep: No such file or directory"
2. "grep: ./src/clisp/c: No such file or directory"
3. "find: write error: Invalid argument"

9. same as above but without "-Q":
find . \( -path  -o -path \*/attic ...-o  -type f \( -iname
\*.\[cdfh\] -o -iname \*.lisp -o -iname \*.tst -o -iname \*.m4 -o
-iname \*.in -o -iname Makefile\* -o -iname \*.xml \) -print0 | xargs
-0 -e grep -i -nH asdf
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]



-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Thu, 6 Jan 2011 10:17:17 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
> 
> > I suggest to fix PATH outside Emacs instead.  I wrote in bug#7793 why.
> 
> is it safe to prepend gnuwin path before the system windows paths
> globally for all programs?

Yes, in my experience.

> my toolchain is not limited to the gnu world, I am afraid of breaking,
> e.g., ms visual studio...

I have VS installed on one of my machines that I use daily, and I have
yet to see even a single problem.  In general, programs that come with
VS don't include namesakes of GNU tools.

> > Also, you said just a couple of messages ago, that rgrep did work for
> > you in "emacs -q".  So is the only difference between that and this
> > whatever you have on your .emacs?  Or am I missing something else?
> 
> 1. "emacs -Q" started from bash shell:

It looks like now nothing works, is that right?  Then what was this
about:

> this works just fine, like on linux:
> PATH=/cygdrive/c/gnu/gnuwin32/bin:$PATH emacs -q
> 
> moreover,
> emacs -q
> and moving gnuwin dir to the beginning of exec-path with
> (let ((gw "c:/gnu/gnuwin32/bin"))
>   (setq exec-path (cons gw (delete gw exec-path))))
> also works fine.

?  What is different between these 2 "working" instances and what you
tried now?

> (getenv "PATH")
> "C:\\gnu\\cygwin\\usr\\local\\bin;C:\\gnu\\cygwin\\bin;C:\\gnu\\cygwin\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
> Files\\TortoiseSVN\\bin;C:\\gnu\\gnuwin32\\bin;C:\\gnu\\cygwin\\bin;D:\\bin;C:\\Program
> Files (x86)\\TortoiseHg\\;C:\\Program Files
> (x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"
> 
> find . "(" -path "*/SCCS" -o -path "*/RCS" -o -path "*/CVS" -o -path
> "*/MCVS" -o -path "*/.svn" -o -path "*/.git" -o -path "*/.hg" .....
> -exec grep -i -nH "asdf" {} NUL ";"
> 
> grep: NUL: No such file or directory
> grep: NUL: No such file or directory
> grep: NUL: No such file or directory
> grep: NUL: No such file or directory
> grep: NUL: No such file or directory
> 
> i.e., cygwin tools are used, which sucks because of NULs but at least
> things sort of work.

Does this problem go away if you set grep-use-null-device to
"/dev/null"?  You could also customize null-device, if you always use
the Cygwin shell.

> find . "(" -path "*/SCCS" -o -path "*/RCS" -o -path "*/CVS"
> -o.....-name "*.kys" -o -name "*.pgs" -o -name "*.tps" -o -name
> "*.vrs" -o -name "*.pyc" -o -name "*.pyo" ")" -prune -o  -type f "("
> -iname "*" -o -iname ".*" ")" -print0 | xargs -0 -e grep -i -nH "sfdg"
> xargs: grep: No such file or directory
> grep: ./src/clisp/current/src/config: No such file or directory
> find: write error: Invalid argument
> 
> i.e., apparently, gnuwin tools are used, but nothing works.

I suspect that the shell picks up xargs from Cygwin or something.
Could you try forcing it to use the GnuWin32 binary, or at least
verifying that a GnuWin32 binaries of all the 3 programs get invoked?

> 4. emacs started from desktop with my full huge .emacs but without PATH tweaking
> 
> (getenv "PATH")
> "C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
> Files\\TortoiseSVN\\bin;c:\\gnu\\gnuwin32\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program
> Files (x86)\\TortoiseHg\\;C:\\Program Files
> (x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"
> 
> c:/gnu/gnuwin32/bin/find . \( -path  -o -path \*/attic ..... -o -iname
> Makefile\* -o -iname \*.xml \) -print0 | c:/gnu/gnuwin32/bin/xargs -0
> -e c:/gnu/gnuwin32/bin/grep -i -nH sadf
> 'c:' is not recognized as an internal or external command,
> operable program or batch file.

This is because "c:/gnu/gnuwin32/bin/xargs", which is after the pipe
symbol, is not quoted.  So this is something I do understand.

> 5. same as 4 but without setting find-program et al
> FIND: Parameter format not correct

Also, understood: it picks find.exe from C:/WINDOWS/system32, which is
first on PATH.

> 6. emacs started from desktop with my full huge .emacs with PATH
> tweaking without setting find-program et al:
> 
> (getenv "PATH")
> "c:\\gnu\\gnuwin32\\bin;c:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
> Files\\TortoiseSVN\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program Files
> (x86)\\TortoiseHg\\;C:\\Program Files
> (x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin;c:\\sds\\src\\emacs\\trunk\\bin"
> 
> find . \( -path  -o -path \*/attic -o -path .....-iname \*.in -o
> -iname Makefile\* -o -iname \*.xml \) -print0 | xargs -0 -e grep -i
> -nH asdf
> find: paths must precede expression
> Usage: find [-H] [-L] [-P] [path...] [expression]

This somehow uses the wrong quoting style.  Can you look into
shell-quote-argument and see why?

> 7. emacs -Q started from desktop:
> 
> (getenv "PATH")
> "C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
> Files\\TortoiseSVN\\bin;c:\\gnu\\gnuwin32\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program
> Files (x86)\\TortoiseHg\\;C:\\Program Files
> (x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"
> 
> find . "(" -path "*/SCCS" ... -name "*.pyc" -o -name "*.pyo" ")"
> -prune -o  -type f "(" -iname "*" -o -iname ".*" ")" -exec grep -i -nH
> "rg	" {} NUL ";"
> FIND: Parameter format not correct

Again, the MS find.exe, because of PATH.

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Thu, Jan 6, 2011 at 5:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> There's something else I don't understand.  The style of shell quoting
> you show, viz.
>
>  find . \( -path  -o -path \*/attic -o -path \*/junk -o -path \*/SCCS
>  -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o -path \*/.svn -o
>  -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o
>
> is different from what I see on my Windows box:
>
>  find . "(" -path  -o -path "*/attic" -o -path "*/junk" -o -path "*/SCCS"
>  -o -path "*/RCS" -o -path "*/CVS" -o -path "*/MCVS" -o -path "*/.svn" -o
>  -path "*/.git" -o -path "*/.hg" -o -path "*/.bzr" -o -path "*/_MTN" -o
>
> That is, Emacs is supposed to use double quotes on Windows, because
> Windows programs (except Cygwin) don't understand quoting with a
> backslash.  Do you see the former style of quoting in "emacs -Q" as
> well?

the problem is with w32-fns.el.
I set explicit-shell-file-name to "bash" because whenever I start an
explicit interactive shell,
I want it to be bash and not the windows crap.
however, this has nothing to do with the shell used to interpret
individual commands
like M-! and M-x rgrep.
specifically, since explicit-shell-file-name is "bash", w32-shell-name
returns "bash"
and thus w32-shell-dos-semantics returns nil and shell-quote-argument
thus uses backslashes.
I think this is wrong.
I propose this patch:

=== modified file 'lisp/w32-fns.el'
--- lisp/w32-fns.el	2010-10-24 22:04:45 +0000
+++ lisp/w32-fns.el	2011-01-06 15:58:02 +0000
@@ -57,7 +57,7 @@ That includes all Windows systems except

 (defun w32-shell-name ()
   "Return the name of the shell being used."
-  (or (bound-and-true-p explicit-shell-file-name)
+  (or (bound-and-true-p shell-file-name)
       (getenv "ESHELL")
       (getenv "SHELL")
       (and (w32-using-nt) "cmd.exe")


is it OK to commit?


with this patch and my full .emacs with PATH tweaking and without
find-program setting:

find . "(" -path  -o ...  -type f "(" -iname "*.[cdfh]" -o -iname
"*.lisp" -o -iname "*.tst" -o -iname "*.m4" -o -iname "*.in" -o -iname
"Makefile*" -o -iname "*.xml" ")" -print0 | xargs -0 -e grep -i -nH
"asdf"
xargs: grep: No such file or directory


i.e., it still does not work, despite:

(getenv "PATH")
"c:\\gnu\\gnuwin32\\bin;c:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\gnu\\clisp-2.49;C:\\Program
Files\\TortoiseSVN\\bin;C:\\Program Files
(x86)\\TortoiseHg\\;C:\\Program Files
(x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin;c:\\sds\\src\\emacs\\trunk\\bin"
(executable-find "grep")
"c:/gnu/gnuwin32/bin/grep.exe"
and M-! grep RET working.

-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Thu, 6 Jan 2011 10:25:42 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org, 6784@debbugs.gnu.org
> 
> the problems you describe seem to boil down to re-implementing cmd in cmdproxy.
> this begs the question, why does emacs have to provide cmdproxy?
> why not use cmd provided by windows?

cmdproxy does not reimplement cmd.  It is really just a proxy to cmd,
designed to fix a few idiosyncrasies, and that's it.  When cmdproxy
concludes that a shell is needed, it invokes cmd (or some other
shell).  This part of the commentary at the beginning of cmdproxy.c
should tell the story:

   Accepts subset of Unix sh(1) command-line options, for compatibility
   with elisp code written for Unix.  When possible, executes external
   programs directly (a common use of /bin/sh by Emacs), otherwise
   invokes the user-specified command processor to handle built-in shell
   commands, batch files and interactive mode.

   The main function is simply to process the "-c string" option in the
   way /bin/sh does, since the standard Windows command shells use the
   convention that everything after "/c" (the Windows equivalent of
   "-c") is the input string.

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Thu, 6 Jan 2011 10:46:58 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
> 
> of PATH globally:
> 
> (getenv "PATH")
> "c:\\gnu\\gnuwin32\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
> Files\\TortoiseSVN\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program Files
> (x86)\\TortoiseHg\\;C:\\Program Files
> (x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"
> 
> find . "(" -path "*/SCCS" -o -path "*/RCS"...-o -name "*.pyo" ")"
> -prune -o  -type f "(" -iname "*" -o -iname ".*" ")" -print0 | xargs
> -0 -e grep -i -nH "asdf"
> xargs: grep: No such file or directory
> ./src/clisp/current/src/ChangeLog:29:	* modules/asdf/asdf.lisp: update
> to upstream "2.011"
> ./src/clisp/current/src/ChangeLog:512:	bundle ASDF2 as a module
> ./src/clisp/current/src/ChangeLog:513:	* Makefile.devel (update-asdf):
> new .PHONY target
> ./src/clisp/current/src/ChangeLog:515:	* modules/asdf: add (based on asdf 2.008)
> ./src/clisp/current/src/ChangeLog:516:	* makemake.in, unix/INSTALL:
> mention asdf in the docs
> ./src/clisp/current/src/ChangeLog:590:	(require): use the above, now
> one can hook asdf into clisp
> grep: ./src/clisp/c: No such file or directory
> find: write error: Invalid argument

Does this command work from the Windows shell, if you tweak PATH to
have the gnuwin32 directory be at the beginning?

> sort of works, except these bugs in output:
> 1. "xargs: grep: No such file or directory"
> 2. "grep: ./src/clisp/c: No such file or directory"
> 3. "find: write error: Invalid argument"

The last one is simply a consequence of the fact that xargs exits
prematurely (due to the other errors) and the pipe is closed on the
reader side, which makes the writer (find) unhappy.  But the other 2
errors are puzzling...

bug#7785: rgrep is broken on woe32

[Sam Steingold]

thanks for the explanations.

On Thu, Jan 6, 2011 at 11:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 6 Jan 2011 10:17:17 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
>>
>> > I suggest to fix PATH outside Emacs instead.  I wrote in bug#7793 why.
>>
>> is it safe to prepend gnuwin path before the system windows paths
>> globally for all programs?
>
> Yes, in my experience.

thanks, I will keep that in mind.
I will not do that for now since so far my tweaking of exec-path +
setenv seems to produce the same results.
however, I will keep in mind both your deprecation of this practice
and your experience above
and will follow your suggestion if my method breaks.
thanks.

> It looks like now nothing works, is that right?  Then what was this
> about:
>
>> this works just fine, like on linux:
>> PATH=/cygdrive/c/gnu/gnuwin32/bin:$PATH emacs -q
>>
>> moreover,
>> emacs -q
>> and moving gnuwin dir to the beginning of exec-path with
>> (let ((gw "c:/gnu/gnuwin32/bin"))
>>   (setq exec-path (cons gw (delete gw exec-path))))
>> also works fine.
>
> ?  What is different between these 2 "working" instances and what you
> tried now?

OOPS. these no longer work. both produce this:

-*- mode: grep; default-directory: "~/" -*-
Grep started at Thu Jan 06 11:45:35

find . "(" -path "*/SCCS" -o -path "*/RCS"/..... -o -name "*.pyo" ")"
-prune -o  -type f "(" -iname "*" -o -iname ".*" ")" -print0 | xargs
-0 -e grep -i -nH "exec-path"
xargs: grep: No such file or directory
grep: ./src/clisp/c: No such file or directory
find: write error: Invalid argument

Grep finished (matches found) at Thu Jan 06 11:45:37

I am totally lost...

> I suspect that the shell picks up xargs from Cygwin or something.
> Could you try forcing it to use the GnuWin32 binary, or at least
> verifying that a GnuWin32 binaries of all the 3 programs get invoked?

all 3 programs live in the same dir, whether gnuwin or cygwin.
I don't see how they can come from different places.

>> 4. emacs started from desktop with my full huge .emacs but without PATH tweaking
>> 'c:' is not recognized as an internal or external command,
>> operable program or batch file.
>
> This is because "c:/gnu/gnuwin32/bin/xargs", which is after the pipe
> symbol, is not quoted.  So this is something I do understand.

yes, that other cmdproxy issue - any change it will be addressed any time soon?

>> FIND: Parameter format not correct
> Also, understood: it picks find.exe from C:/WINDOWS/system32, which is
> first on PATH.

sure. I omitted all the other details because this one was obvious :-)

>> 6. emacs started from desktop with my full huge .emacs with PATH
>> tweaking without setting find-program et al:
>> find . \( -path  -o -path \*/attic -o -path .....-iname \*.in -o
>> find: paths must precede expression
>
> This somehow uses the wrong quoting style.  Can you look into
> shell-quote-argument and see why?

I sent you the patch in another message in this bug.

thanks again for your time and compassion...
-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Thu, Jan 6, 2011 at 11:20 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 6 Jan 2011 10:46:58 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
>>
>> of PATH globally:
>>
>> (getenv "PATH")
>> "c:\\gnu\\gnuwin32\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\gnu\\clisp-2.49;C:\\Program
>> Files\\TortoiseSVN\\bin;c:\\gnu\\cygwin\\bin;d:\\bin;C:\\Program Files
>> (x86)\\TortoiseHg\\;C:\\Program Files
>> (x86)\\Bazaar;C:\\gnu\\GnuTLS-2.10.1\\bin"
>>
>> find . "(" -path "*/SCCS" -o -path "*/RCS"...-o -name "*.pyo" ")"
>> -prune -o  -type f "(" -iname "*" -o -iname ".*" ")" -print0 | xargs
>> -0 -e grep -i -nH "asdf"
>> xargs: grep: No such file or directory
>> ./src/clisp/current/src/ChangeLog:29: * modules/asdf/asdf.lisp: update
>> to upstream "2.011"
>> ./src/clisp/current/src/ChangeLog:512:        bundle ASDF2 as a module
>> ./src/clisp/current/src/ChangeLog:513:        * Makefile.devel (update-asdf):
>> new .PHONY target
>> ./src/clisp/current/src/ChangeLog:515:        * modules/asdf: add (based on asdf 2.008)
>> ./src/clisp/current/src/ChangeLog:516:        * makemake.in, unix/INSTALL:
>> mention asdf in the docs
>> ./src/clisp/current/src/ChangeLog:590:        (require): use the above, now
>> one can hook asdf into clisp
>> grep: ./src/clisp/c: No such file or directory
>> find: write error: Invalid argument
>
> Does this command work from the Windows shell, if you tweak PATH to
> have the gnuwin32 directory be at the beginning?

yes, the same way.
I started cmd; prepended gnuwin to path, started emacs -Q from the
cmd; got the above in rgrep, then copied the command into the cmd and
got the exact same output there,
EXCEPT that neither emacs nor cmd contain the
"grep: ./src/clisp/c: No such file or directory"
error (the other two:
"xargs: grep: No such file or directory"
and
"find: write error: Invalid argument"
are present both in emacs and cmd).


-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Thu, 6 Jan 2011 12:09:12 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
> 
> >> find . "(" -path "*/SCCS" -o -path "*/RCS"...-o -name "*.pyo" ")"
> >> -prune -o  -type f "(" -iname "*" -o -iname ".*" ")" -print0 | xargs
> >> -0 -e grep -i -nH "asdf"
> >> xargs: grep: No such file or directory
> >> ./src/clisp/current/src/ChangeLog:29: * modules/asdf/asdf.lisp: update
> >> to upstream "2.011"
> >> ./src/clisp/current/src/ChangeLog:512:        bundle ASDF2 as a module
> >> ./src/clisp/current/src/ChangeLog:513:        * Makefile.devel (update-asdf):
> >> new .PHONY target
> >> ./src/clisp/current/src/ChangeLog:515:        * modules/asdf: add (based on asdf 2.008)
> >> ./src/clisp/current/src/ChangeLog:516:        * makemake.in, unix/INSTALL:
> >> mention asdf in the docs
> >> ./src/clisp/current/src/ChangeLog:590:        (require): use the above, now
> >> one can hook asdf into clisp
> >> grep: ./src/clisp/c: No such file or directory
> >> find: write error: Invalid argument
> >
> > Does this command work from the Windows shell, if you tweak PATH to
> > have the gnuwin32 directory be at the beginning?
> 
> yes, the same way.
> I started cmd; prepended gnuwin to path, started emacs -Q from the
> cmd; got the above in rgrep, then copied the command into the cmd and
> got the exact same output there,
> EXCEPT that neither emacs nor cmd contain the
> "grep: ./src/clisp/c: No such file or directory"

So at least this error is somehow related to the fact that you invoke
Emacs from the Cygwin bash.  Can you see what are the differences in
process-environment between the invocations from bash and from cmd?

> error (the other two:
> "xargs: grep: No such file or directory"
> and
> "find: write error: Invalid argument"
> are present both in emacs and cmd).

So this is no longer just an Emacs problem, it seems.

What happens if you repeat this experiment, but this time give an
explicit absolute file name for each program, find, xargs, and grep?
(I'd like to be sure we know what binaries are involved.)  To avoid
hassles with quoting, please use backslashes in the file names.

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Thu, 6 Jan 2011 11:51:05 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org
> 
> >> this works just fine, like on linux:
> >> PATH=/cygdrive/c/gnu/gnuwin32/bin:$PATH emacs -q
> >>
> >> moreover,
> >> emacs -q
> >> and moving gnuwin dir to the beginning of exec-path with
> >> (let ((gw "c:/gnu/gnuwin32/bin"))
> >>   (setq exec-path (cons gw (delete gw exec-path))))
> >> also works fine.
> >
> > ?  What is different between these 2 "working" instances and what you
> > tried now?
> 
> OOPS. these no longer work. both produce this:

Something's changed.  Perhaps you could remember whether you changed
something in between.

> >> 'c:' is not recognized as an internal or external command,
> >> operable program or batch file.
> >
> > This is because "c:/gnu/gnuwin32/bin/xargs", which is after the pipe
> > symbol, is not quoted.  So this is something I do understand.
> 
> yes, that other cmdproxy issue - any change it will be addressed any time soon?

I'd like to hear from Stefan or Chong before I make that change.  In
the meantime, you can do that in your sandbox: just edit the templates
used by grep.el to quote the %s after the pipe symbol.

> thanks again for your time and compassion...

You are welcome, and sorry you are having all this trouble.

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Thu, Jan 6, 2011 at 1:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> What happens if you repeat this experiment, but this time give an
> explicit absolute file name for each program, find, xargs, and grep?
> (I'd like to be sure we know what binaries are involved.)  To avoid
> hassles with quoting, please use backslashes in the file names.

when I apply my w32-fns patch, I see this:

-*- mode: grep; default-directory: "~/" -*-
Grep started at Thu Jan 06 15:46:06

c:\gnu\gnuwin32\bin\find . "(" -path  -o -path......o -name "*.tps" -o
-name "*.vrs" -o -name "*.pyc" -o -name "*.pyo" ")" -prune -o  -type f
"(" -iname "*.[cdfh]" -o -iname "*.lisp" -o -iname "*.tst" -o -iname
"*.m4" -o -iname "*.in" -o -iname "Makefile*" -o -iname "*.xml" ")"
-print0 | c:\gnu\gnuwin32\bin\xargs -0 -e c:\gnu\gnuwin32\bin\grep -i
-nH "asdf"
c:\gnu\gnuwin32\bin\xargs: c:\gnu\gnuwin32\bin\grep: Invalid argument

Grep finished (matches found) at Thu Jan 06 15:46:09



-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Thu, 6 Jan 2011 15:55:40 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: 7785@debbugs.gnu.org
> 
> On Thu, Jan 6, 2011 at 1:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > What happens if you repeat this experiment, but this time give an
> > explicit absolute file name for each program, find, xargs, and grep?
> > (I'd like to be sure we know what binaries are involved.)  To avoid
> > hassles with quoting, please use backslashes in the file names.
> 
> when I apply my w32-fns patch, I see this:
> 
> -*- mode: grep; default-directory: "~/" -*-
> Grep started at Thu Jan 06 15:46:06
> 
> c:\gnu\gnuwin32\bin\find . "(" -path  -o -path......o -name "*.tps" -o
> -name "*.vrs" -o -name "*.pyc" -o -name "*.pyo" ")" -prune -o  -type f
> "(" -iname "*.[cdfh]" -o -iname "*.lisp" -o -iname "*.tst" -o -iname
> "*.m4" -o -iname "*.in" -o -iname "Makefile*" -o -iname "*.xml" ")"
> -print0 | c:\gnu\gnuwin32\bin\xargs -0 -e c:\gnu\gnuwin32\bin\grep -i
> -nH "asdf"
> c:\gnu\gnuwin32\bin\xargs: c:\gnu\gnuwin32\bin\grep: Invalid argument
> 
> Grep finished (matches found) at Thu Jan 06 15:46:09

And if you try the same command from the cmd prompt outside Emacs?

Also, what does "c:\gnu\gnuwin32\bin\xargs --version" say?

bug#7785: rgrep is broken on woe32

[Sam Steingold]

On Thu, Jan 6, 2011 at 4:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> And if you try the same command from the cmd prompt outside Emacs?

works just fine:

C:\sds>c:\gnu\gnuwin32\bin\find . -name "ChangeLog" -print0 |
c:\gnu\gnuwin32\bin\xargs -0 -e c:\gnu\gnuwin32\bin\grep -i -nH "asdf"
./src/cl/clocc/src/defsystem-3.x/ChangeLog:10:  Added
RUN-SHELL-COMMAND (modified from UFFI and ASDF to make it
./src/cl/clocc/src/defsystem-3.x/ChangeLog:466:   MK3, following the
ideas in ASDF.  If the DEFSYSTEM form is
./src/cl/clocc/src/defsystem-3.x/ChangeLog:532:   Controller can
depend on defsystem versions 3 & 4 as well as asdf
./src/clisp/current/src/ChangeLog:29:   * modules/asdf/asdf.lisp:
update to upstream "2.011"
./src/clisp/current/src/ChangeLog:512:  bundle ASDF2 as a module
./src/clisp/current/src/ChangeLog:513:  * Makefile.devel
(update-asdf): new .PHONY target
./src/clisp/current/src/ChangeLog:515:  * modules/asdf: add (based on
asdf 2.008)
./src/clisp/current/src/ChangeLog:516:  * makemake.in, unix/INSTALL:
mention asdf in the docs
./src/clisp/current/src/ChangeLog:590:  (require): use the above, now
one can hook asdf into clisp

C:\sds>




> Also, what does "c:\gnu\gnuwin32\bin\xargs --version" say?

GNU xargs version 4.2.20

-- 
Sam Steingold <http://sds.podval.org>

bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Thu, 6 Jan 2011 16:11:49 -0500
> From: Sam Steingold <sds@gnu.org>
> Cc: 7785@debbugs.gnu.org
> 
> On Thu, Jan 6, 2011 at 4:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > And if you try the same command from the cmd prompt outside Emacs?
> 
> works just fine:

Please show all the differences between the environment variables in
cmd (type "set RET") on the one hand, and in process-environment under
the configuration when this happened, OTOH:

> when I apply my w32-fns patch, I see this:
> 
> -*- mode: grep; default-directory: "~/" -*-
> Grep started at Thu Jan 06 15:46:06
> 
> c:\gnu\gnuwin32\bin\find . "(" -path  -o -path......o -name "*.tps" -o
> -name "*.vrs" -o -name "*.pyc" -o -name "*.pyo" ")" -prune -o  -type f
> "(" -iname "*.[cdfh]" -o -iname "*.lisp" -o -iname "*.tst" -o -iname
> "*.m4" -o -iname "*.in" -o -iname "Makefile*" -o -iname "*.xml" ")"
> -print0 | c:\gnu\gnuwin32\bin\xargs -0 -e c:\gnu\gnuwin32\bin\grep -i
> -nH "asdf"
> c:\gnu\gnuwin32\bin\xargs: c:\gnu\gnuwin32\bin\grep: Invalid argument
> 
> Grep finished (matches found) at Thu Jan 06 15:46:09

bug#7785: rgrep is broken on woe32

[Sam Steingold]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Fri, Jan 7, 2011 at 2:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 6 Jan 2011 16:11:49 -0500
>> From: Sam Steingold <sds@gnu.org>
>> Cc: 7785@debbugs.gnu.org
>>
>> On Thu, Jan 6, 2011 at 4:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > And if you try the same command from the cmd prompt outside Emacs?
>>
>> works just fine:
>
> Please show all the differences between the environment variables in
> cmd (type "set RET") on the one hand,
> and in process-environment under
> the configuration when this happened, OTOH:

attached.

-- 
Sam Steingold <http://sds.podval.org>

[-- Attachment #2: env-emacs --]
[-- Type: application/octet-stream, Size: 1843 bytes --]

__COMPAT_LAYER=LUA
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\sds\Application Data
CLIENTNAME=Console
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramFiles=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=SDS
COMSPEC=C:\WINDOWS\system32\cmd.exe
emacs_dir=C:/sds/src/emacs/trunk
EMACSDATA=C:/sds/src/emacs/trunk/etc
EMACSDOC=C:/sds/src/emacs/trunk/etc
EMACSLOADPATH=C:/sds/src/emacs/trunk/site-lisp;C:/sds/src/emacs/trunk/../site-lisp;C:/sds/src/emacs/trunk/lisp;C:/sds/src/emacs/trunk/leim
EMACSPATH=C:/sds/src/emacs/trunk/bin
FP_NO_HOST_CHECK=NO
HOME=c:/sds
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\sds
INCLUDE=c:\dev\include
LANG=C
LIB=c:\dev\lib
LOGONSERVER=\\SDS
NUMBER_OF_PROCESSORS=8
OS=Windows_NT
PATH=c:\gnu\gnuwin32\bin;c:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\gnu\gnuwin32\bin;c:\gnu\cygwin\bin;d:\bin;C:\gnu\clisp-2.49;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\TortoiseHg\;C:\Program Files (x86)\Bazaar;C:\gnu\GnuTLS-2.10.1\bin;c:\sds\src\emacs\trunk\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
PROCESSOR_IDENTIFIER=EM64T Family 6 Model 26 Stepping 5, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1a05
ProgramFiles(x86)=C:\Program Files (x86)
ProgramFiles=C:\Program Files (x86)
ProgramW6432=C:\Program Files
SESSIONNAME=Console
SHELL=C:/sds/src/emacs/trunk/bin/cmdproxy.exe
SSH_AUTH_SOCK=/tmp/ssh-UFdOcD2896/agent.2896
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\WINDOWS\TEMP\
TERM=dumb
TMP=C:\WINDOWS\TEMP\
TMPDIR=C:\WINDOWS\TEMP\
USERDOMAIN=SDS
USERNAME=sds
USERPROFILE=C:\Documents and Settings\sds
VS80COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\
windir=C:\WINDOWS

[-- Attachment #3: env-cmd --]
[-- Type: application/octet-stream, Size: 1257 bytes --]

ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\sds\Application Data
CLIENTNAME=Console
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
COMPUTERNAME=SDS
ComSpec=C:\WINDOWS\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOME=c:/sds
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\sds
INCLUDE=c:\dev\include
LIB=c:\dev\lib
LOGONSERVER=\\SDS
NUMBER_OF_PROCESSORS=8
OS=Windows_NT
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\gnu\gnuwin32\bin;c:\gnu\cygwin\bin;d:\bin;C:\gnu\clisp-2.49;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\TortoiseHg\;C:\Program Files (x86)\Bazaar;C:\gnu\GnuTLS-2.10.1\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=EM64T Family 6 Model 26 Stepping 5, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1a05
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
PROMPT=$P$G
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\WINDOWS\TEMP\
TMP=C:\WINDOWS\TEMP\
USERDOMAIN=SDS
USERNAME=sds
USERPROFILE=C:\Documents and Settings\sds
VS80COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\
windir=C:\WINDOWS

[-- Attachment #4: env-diff --]
[-- Type: application/octet-stream, Size: 2318 bytes --]

--- env-cmd	2011-01-07 10:14:25.545500000 -0500
+++ env-emacs	2011-01-07 10:10:40.951750000 -0500
@@ -1,33 +1,46 @@
+__COMPAT_LAYER=LUA
 ALLUSERSPROFILE=C:\Documents and Settings\All Users
 APPDATA=C:\Documents and Settings\sds\Application Data
 CLIENTNAME=Console
-CommonProgramFiles=C:\Program Files\Common Files
 CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
+CommonProgramFiles=C:\Program Files (x86)\Common Files
+CommonProgramW6432=C:\Program Files\Common Files
 COMPUTERNAME=SDS
-ComSpec=C:\WINDOWS\system32\cmd.exe
+COMSPEC=C:\WINDOWS\system32\cmd.exe
+emacs_dir=C:/sds/src/emacs/trunk
+EMACSDATA=C:/sds/src/emacs/trunk/etc
+EMACSDOC=C:/sds/src/emacs/trunk/etc
+EMACSLOADPATH=C:/sds/src/emacs/trunk/site-lisp;C:/sds/src/emacs/trunk/../site-lisp;C:/sds/src/emacs/trunk/lisp;C:/sds/src/emacs/trunk/leim
+EMACSPATH=C:/sds/src/emacs/trunk/bin
 FP_NO_HOST_CHECK=NO
 HOME=c:/sds
 HOMEDRIVE=C:
 HOMEPATH=\Documents and Settings\sds
 INCLUDE=c:\dev\include
+LANG=C
 LIB=c:\dev\lib
 LOGONSERVER=\\SDS
 NUMBER_OF_PROCESSORS=8
 OS=Windows_NT
-Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\gnu\gnuwin32\bin;c:\gnu\cygwin\bin;d:\bin;C:\gnu\clisp-2.49;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\TortoiseHg\;C:\Program Files (x86)\Bazaar;C:\gnu\GnuTLS-2.10.1\bin
+PATH=c:\gnu\gnuwin32\bin;c:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\gnu\gnuwin32\bin;c:\gnu\cygwin\bin;d:\bin;C:\gnu\clisp-2.49;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\TortoiseHg\;C:\Program Files (x86)\Bazaar;C:\gnu\GnuTLS-2.10.1\bin;c:\sds\src\emacs\trunk\bin
 PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
-PROCESSOR_ARCHITECTURE=AMD64
+PROCESSOR_ARCHITECTURE=x86
+PROCESSOR_ARCHITEW6432=AMD64
 PROCESSOR_IDENTIFIER=EM64T Family 6 Model 26 Stepping 5, GenuineIntel
 PROCESSOR_LEVEL=6
 PROCESSOR_REVISION=1a05
-ProgramFiles=C:\Program Files
 ProgramFiles(x86)=C:\Program Files (x86)
-PROMPT=$P$G
+ProgramFiles=C:\Program Files (x86)
+ProgramW6432=C:\Program Files
 SESSIONNAME=Console
+SHELL=C:/sds/src/emacs/trunk/bin/cmdproxy.exe
+SSH_AUTH_SOCK=/tmp/ssh-UFdOcD2896/agent.2896
 SystemDrive=C:
 SystemRoot=C:\WINDOWS
 TEMP=C:\WINDOWS\TEMP\
+TERM=dumb
 TMP=C:\WINDOWS\TEMP\
+TMPDIR=C:\WINDOWS\TEMP\
 USERDOMAIN=SDS
 USERNAME=sds
 USERPROFILE=C:\Documents and Settings\sds

bug#7785: rgrep is broken on woe32

[Sam Steingold]

YAY!!!!!
the following solves my problem for now (I don't know what will happen
tomorrow though :-)

(when sds-winnt
  (setq find-program ;(concat sds-gnuwin-home "bin\\find")
        (w32-convert-standard-filename (concat sds-cygwin-home "bin\\find"))
        xargs-program ;(concat sds-gnuwin-home "bin\\xargs")
        (w32-convert-standard-filename (concat sds-cygwin-home "bin\\xargs"))
        grep-program ;(concat sds-gnuwin-home "bin\\grep")
        (w32-convert-standard-filename (concat sds-cygwin-home "bin\\grep"))
        grep-find-use-xargs 'gnu
        grep-use-null-device nil))

please close this bug; I will reopen it if I ever get stuck again :-(

(Eli, thanks a lot for your patience, I will not be trying anything
else for this as long as the above solution works).

bug#6784: bug#7785: rgrep is broken on woe32

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> The discussions in that bug report concluded that the program file
> name after the pipe needs to be quoted, in order for it to work with
> file names that use forward- and back-slashes alike.  I can solve that
> problem for rgrep (and for other similar commands) by tweaking the
> templates used by grep.el, so as to quote the %s after the pipe
> character `|'.  Would that be an okay solution?

I think this is an acceptable solution, and agree that changing cmdproxy
to handle this intelligently sounds like a nightmare.

> The disadvantage is, of course, that similar solutions will have to be
> implemented for each Emacs command that launches a shell pipeline.

Let's just fix these individually as the problems are reported.

bug#7785: bug#6784: bug#7785: rgrep is broken on woe32

[Laimonas Vėbra]

Chong Yidong wrote:
> Eli Zaretskii<eliz@gnu.org>  writes:
>
>> The discussions in that bug report concluded that the program file
>> name after the pipe needs to be quoted, in order for it to work with
>> file names that use forward- and back-slashes alike.  I can solve that
>> problem for rgrep (and for other similar commands) by tweaking the
>> templates used by grep.el, so as to quote the %s after the pipe
>> character `|'.  Would that be an okay solution?
>
> I think this is an acceptable solution, and agree that changing cmdproxy
> to handle this intelligently sounds like a nightmare.

As long as cmdproxy is meant to pass commands (and in principle; acting 
as a proxy and dealing with various shells and with different their 
behaviours, requirements) to the particular shell (cmd.exe), it's best 
to fix this bug in a cmdproxy, because this bug is only the „problem“ of 
the cmd.exe.

bug#7785: bug#6784: bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Sam Steingold <sds@gnu.org>, 7785@debbugs.gnu.org, 6784@debbugs.gnu.org
> Date: Sat, 08 Jan 2011 16:00:43 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The discussions in that bug report concluded that the program file
> > name after the pipe needs to be quoted, in order for it to work with
> > file names that use forward- and back-slashes alike.  I can solve that
> > problem for rgrep (and for other similar commands) by tweaking the
> > templates used by grep.el, so as to quote the %s after the pipe
> > character `|'.  Would that be an okay solution?
> 
> I think this is an acceptable solution, and agree that changing cmdproxy
> to handle this intelligently sounds like a nightmare.

Okay, fixed in grep.el (revno 100367 on the emacs-23 branch).

> > The disadvantage is, of course, that similar solutions will have to be
> > implemented for each Emacs command that launches a shell pipeline.
> 
> Let's just fix these individually as the problems are reported.

I found only 2 more instances of this that need to be fixed.  One of
them is in jka-compr.el, where it calls `dd' in a pipe.  I fixed that
one.  The other one is in tramp.el, which uses shell pipelines a lot;
however, the only ones that need to be fixed are those that invoke
_local_ programs, not remote programs, as the latter will not be on a
Windows machine.  Michael, could you please take care of that (on the
emacs-23 branch)?  I gather that you have your master repository, so
doing it from there would be less hassle for you, and you know the
semantics of each pipeline better than I do.  Thanks.

bug#7785: bug#6784: bug#7785: rgrep is broken on woe32

[Eli Zaretskii]

> Date: Sun, 09 Jan 2011 00:13:09 +0200
> From: Laimonas Vėbra <laimonas.vebra@gmail.com>
> Cc: ofv@wanadoo.es, 7785@debbugs.gnu.org, Sam Steingold <sds@gnu.org>
> 
> As long as cmdproxy is meant to pass commands (and in principle; acting 
> as a proxy and dealing with various shells and with different their 
> behaviours, requirements) to the particular shell (cmd.exe), it's best 
> to fix this bug in a cmdproxy, because this bug is only the „problem“ of 
> the cmd.exe.

That's true, but quoting a file name with ".." can never do any
trouble to any reasonable shell, can it?  Even cmd.exe doesn't mind if
we quote a program file name with backslashes.

Parsing quotes and treating them correctly is a large portion of what
cmd.exe does when it processes a command line.  If we are going to
invest the non-trivial effort required for that, I'd rather we emulate
cmd.exe entirely in cmdproxy, because doing that would allow us to
resolve several other issues that are currently misfeatures or that
need kludgey workarounds.  If someone wants to bite the bullet and
submit patches for that, they will be most welcome (for the trunk).
But in order to fix this problem safely on the release branch that
will enter a feature freeze in 2 weeks or so, we cannot introduce
invasive changes like that.

bug#7785: bug#6784: bug#7785: rgrep is broken on woe32

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Michael, could you please take care of that (on the emacs-23 branch)?
> I gather that you have your master repository, so doing it from there
> would be less hassle for you, and you know the semantics of each
> pipeline better than I do.  Thanks.

I'll do next days.

Best regards, Michael.

bug#6784: bug#7785: rgrep is broken on woe32

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Michael, could you please take care of that (on the emacs-23 branch)?
> I gather that you have your master repository, so doing it from there
> would be less hassle for you, and you know the semantics of each
> pipeline better than I do.  Thanks.

I've found 3 places to patch in tramp.el, fixed in the emacs-23
branch. Under GNU/Linux I could not observe any regression. However, I
cannot test under Windows - could somebody, please, check it with a new
build? It shall be sufficient to open a large (>10kB) remote file,
using the plink method.

Best regards, Michael.