GNU bug report logs - #16045
24.3.50; rgrep can't work

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16045 in the body.
You can then email your comments to 16045 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: zijianyue <zijianyue <at> 163.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; rgrep can't work
Date: Wed, 4 Dec 2013 13:57:45 +0800

[Message part 1 (text/plain, inline)]

  Hello,rgrep worked well before I use this version 24.3.50.
  Now,rgrep always found nothing in emacs,lgrep works well.I don't know why.

--text follows this line--
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-02 on LEG570
Bzr revision: 115341 eggert <at> cs.ucla.edu-20131201170918-zobbqo4z1bzowild
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Important settings:
  value of $EMACSDATA: E:/emacs/share/emacs/24.3.50/etc
  value of $EMACSDOC: E:/emacs/share/emacs/24.3.50/etc
  value of $EMACSLOADPATH: e:/emacs/share/emacs/24.3.50/site-lisp;e:/emacs/share/emacs/site-lisp;E:/emacs/share/emacs/24.3.50/lisp;E:/emacs/share/emacs/24.3.50/leim
  value of $EMACSPATH: E:/emacs/libexec/emacs/24.3.50/i686-pc-mingw32
  value of $LANG: CHS
  locale-coding-system: cp936
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  recent-jump-small-mode: t
  diff-auto-refine-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  which-function-mode: t
  show-paren-mode: t
  global-linum-mode: t
  linum-mode: t
  global-auto-revert-mode: t
  desktop-save-mode: t
  cua-mode: t
  global-ede-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  semantic-mode: t
  tooltip-mode: t
  electric-pair-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<backspace> u s e SPC t h i s SPC w e <backspace> <backspace> 
v e r s i o n <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> d 
<end> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <backspace> e d <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <left> <backspace> <end> <left> <left> 
<left> <left> <left> <left> <right> <right> <right> 
<right> <right> <right> SPC 2 4 . 3 . 5 0 , <backspace> 
. N <backspace> <return> N o w , r e <backspace> g 
r e p SPC f o u <backspace> <backspace> <backspace> 
r e t u <backspace> <backspace> <backspace> <backspace> 
a l w a y s SPC f o u n d SPC n o t h i n g SPC i n 
SPC e m a c s SPC <backspace> , l r e <backspace> <backspace> 
g r e p SPC w o r k s SPC w e l l . I SPC d o n ' t 
SPC k n o w SPC w h y <lwindow> <down-mouse-1> <mouse-1> 
. C-c C-c y m a k <tab> <backspace> <tab> <return> 
<down-mouse-1> <mouse-1> <wheel-up> <double-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <wheel-down> <double-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
<wheel-up> <double-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <wheel-up> <double-wheel-up> <down-mouse-1> 
<mouse-1> <wheel-down> <double-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <wheel-up> 
<double-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<wheel-up> <wheel-up> <help-echo> <help-echo> <menu-bar> 
<buffer> C-b <help-echo> <wheel-down> <double-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <wheel-down> 
<wheel-down> <double-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <help-echo> <down-mouse-1> <mouse-1> 
<help-echo> <down-mouse-1> <drag-mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
Wrote c:/Documents and Settings/Administrator/Application Data/.emacs [2 times]
Sending...
Mark set [2 times]
Sending via mail...
Sending...done
byte-code: Beginning of buffer [6 times]
byte-code: End of buffer [4 times]
byte-code: Beginning of buffer [6 times]
byte-code: End of buffer [4 times]
byte-code: Beginning of buffer [5 times]

Load-path shadows:
e:/emacs/share/emacs/site-lisp/yasnippet/extras/imported/html-mode/.yas-setup hides e:/emacs/share/emacs/site-lisp/yasnippet/extras/imported/objc-mode/.yas-setup
e:/emacs/share/emacs/site-lisp/yasnippet/extras/imported/html-mode/.yas-setup hides e:/emacs/share/emacs/site-lisp/yasnippet/extras/imported/rails-mode/.yas-setup
e:/emacs/share/emacs/site-lisp/yasnippet/extras/imported/html-mode/.yas-setup hides e:/emacs/share/emacs/site-lisp/yasnippet/extras/imported/ruby-mode/.yas-setup

Features:
(mailalias mailclient browse-url pp ede/cpp-root cus-edit help-mode
shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils add-log recent-jump-small recent-jump ring fsvn
fsvn-win mw32cmp mw32script fsvn-admin fsvn-blame fsvn-tortoise
fsvn-proclist fsvn-dired dired-aux fsvn-pub fsvn-magic fsvn-browse
fsvn-parasite fsvn-msgedit fsvn-select fsvn-propview fsvn-logview
fsvn-diff diff-mode easy-mmode diff fsvn-minibuf fsvn-popup fsvn-mode
fsvn-ui advice help-fns fsvn-cmd fsvn-config fsvn-fs fsvn-url fsvn-debug
fsvn-data fsvn-xml xml fsvn-proc fsvn-deps fsvn-env dired
auto-complete-config auto-complete cl-macs popup cl edmacro kmacro redo+
saveplace which-func imenu paren ido linum autorevert filenotify desktop
frameset cua-base cus-start cus-load ede/speedbar ede/files ede ede/base
ede/auto ede/source eieio-speedbar speedbar sb-image dframe eieio-custom
wid-edit cl-loaddefs cl-lib semantic/db-mode semantic/db gv eieio-base
semantic/idle semantic/format ezimage semantic/tag-ls semantic/find
semantic/ctxt semantic/util-modes easymenu semantic/util semantic
semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp
byte-compile cconv eieio-core mode-local cedet server time-date
china-util tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)

[Message part 2 (text/html, inline)]

Message #8 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>, zijianyue <zijianyue <at> 163.com>
Cc: 16045 <at> debbugs.gnu.org
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Wed, 04 Dec 2013 19:24:07 +0200

> Date: Wed, 4 Dec 2013 13:57:45 +0800
> From: zijianyue <zijianyue <at> 163.com>
> 
>   Hello,rgrep worked well before I use this version 24.3.50.
>   Now,rgrep always found nothing in emacs,lgrep works well.I don't know why.

Michael, this is due to this commit of yours (almost a year ago!):

  revno: 111276
  committer: Michael Albinus <michael.albinus <at> gmx.de>
  branch nick: trunk
  timestamp: Thu 2012-12-20 11:15:38 +0000
  message:
    * progmodes/grep.el (rgrep): Escape command line.  Sometimes, it
    is too long for Tramp.  See discussion in
    <http://thread.gmane.org/gmane.emacs.tramp/8233/focus=8244>.

    * progmodes/compile.el (compilation-start): Remove line escape template.

Command lines with newlines are non-portable: Windows shells don't
support them, and don't treat backslashes specially anyway (that's why
we have shell-quote-argument).  So what that change did on Windows is
add literal \r\n strings to the command, making it wrong at best and
un-parsable at worst.

Since the original problem was with Tramp, i.e. with remote files, I
suggest the patch below; it worked for me on Windows.  Please see if
there's anything wrong with it; if not, I will commit.

Btw, I cannot say I like the fact that the command displayed in the
*grep* buffer is different from what is actually passed to the shell.
It makes debugging much harder when some error occurs.  In my case,
'find' displayed several warnings like this:

  find: warning: Filenames usually don't contain slashes (though pathnames do).  That means that '-name .#*\
  ' will probably evaluate to false all the time on this system.  You might find the '-wholename' test more useful, or perhaps '-samefile'.  Alternatively, if you are using GNU grep, you could use 'find ... -print0 | grep -FzZ .#*\
  '.

and I stared at this for several minutes trying to figure out what the
heck was it talking about, since the command displayed in the buffer
had no backslashes at all.  I needed to look at the command line in
GDB to see what is actually being sent.  So I think this is not a good
idea at all.

Here's the patch I suggest:

=== modified file 'lisp/progmodes/grep.el'
--- lisp/progmodes/grep.el	2013-05-24 20:54:38 +0000
+++ lisp/progmodes/grep.el	2013-12-04 17:10:42 +0000
@@ -1005,7 +1005,9 @@ to specify a command to run."
 			      (mapconcat
 			       #'shell-quote-argument
 			       (split-string files)
-			       (concat "\\\n" " -o " find-name-arg " "))
+			       (concat
+				(if (file-remote-p dir) "\\\n")
+				" -o " find-name-arg " "))
 			      " "
 			      (shell-quote-argument ")"))
 		      dir
@@ -1026,7 +1028,9 @@ to specify a command to run."
 						      (concat "*/"
 							      (cdr ignore)))))))
 				     grep-find-ignored-directories
-				     "\\\n -o -path ")
+				     (if (file-remote-p dir)
+					 "\\\n -o -path "
+				       " -o -path "))
 				    " "
 				    (shell-quote-argument ")")
 				    " -prune -o "))
@@ -1044,7 +1048,9 @@ to specify a command to run."
 						     (shell-quote-argument
 						      (cdr ignore))))))
 				     grep-find-ignored-files
-				     "\\\n -o -name ")
+				     (if (file-remote-p dir)
+					 "\\\n -o -name "
+				       " -o -name "))
 				    " "
 				    (shell-quote-argument ")")
 				    " -prune -o "))))))

Message #11 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <zijianyue <at> 163.com>, 16045 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Wed, 04 Dec 2013 14:10:31 -0500

> @@ -1005,7 +1005,9 @@ to specify a command to run."
>  			      (mapconcat
>  			       #'shell-quote-argument
>  			       (split-string files)
> -			       (concat "\\\n" " -o " find-name-arg " "))
> +			       (concat
> +				(if (file-remote-p dir) "\\\n")
> +				" -o " find-name-arg " "))
>  			      " "
>  			      (shell-quote-argument ")"))
>  		      dir

Yuck!  The fix should be in Tramp, not here.


        Stefan

Message #14 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Wed, 04 Dec 2013 21:36:30 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Michael Albinus <michael.albinus <at> gmx.de>,  zijianyue <zijianyue <at> 163.com>,  16045 <at> debbugs.gnu.org
> Date: Wed, 04 Dec 2013 14:10:31 -0500
> 
> > @@ -1005,7 +1005,9 @@ to specify a command to run."
> >  			      (mapconcat
> >  			       #'shell-quote-argument
> >  			       (split-string files)
> > -			       (concat "\\\n" " -o " find-name-arg " "))
> > +			       (concat
> > +				(if (file-remote-p dir) "\\\n")
> > +				" -o " find-name-arg " "))
> >  			      " "
> >  			      (shell-quote-argument ")"))
> >  		      dir
> 
> Yuck!  The fix should be in Tramp, not here.

You mean, the fix that created this problem, yes?

Message #17 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Wed, 04 Dec 2013 15:52:21 -0500

> You mean, the fix that created this problem, yes?

Yes, the extra "\\\n" thingies.


        Stefan

Message #20 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: zijianyue <zijianyue <at> 163.com>, 16045 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 16:10:26 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Yuck!  The fix should be in Tramp, not here.

Hard for Tramp. It gets a long string as argument of
`start-file-process-shell-command', which looks like the example in
<http://thread.gmane.org/gmane.emacs.tramp/8233/focus=8244>. How shall
Tramp parse it? Where does it know from, how long a command line in the
remote shell could be?

>         Stefan

Best regards, Michael.

Message #23 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <zijianyue <at> 163.com>, 16045 <at> debbugs.gnu.org
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 16:14:16 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Since the original problem was with Tramp, i.e. with remote files, I
> suggest the patch below; it worked for me on Windows.  Please see if
> there's anything wrong with it; if not, I will commit.

I haven't tested it yet, but the approach seems OK to me. But let's wait
for the discussion, where the fix shall be: in Tramp, or somewhere else.

> Btw, I cannot say I like the fact that the command displayed in the
> *grep* buffer is different from what is actually passed to the shell.

Then such argument massage shall be performed more visible, and not
silently in the background.

Best regards, Michael.

Message #26 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 19:55:59 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  zijianyue <zijianyue <at> 163.com>,  16045 <at> debbugs.gnu.org
> Date: Thu, 05 Dec 2013 16:10:26 +0100
> 
> Hard for Tramp. It gets a long string as argument of
> `start-file-process-shell-command', which looks like the example in
> <http://thread.gmane.org/gmane.emacs.tramp/8233/focus=8244>. How shall
> Tramp parse it?

Why should it parse it?  Isn't \n\ removed on the remote end before
the shell there interprets it?

> Where does it know from, how long a command line in the remote shell
> could be?

How do you know that in grep.el?

Message #29 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 20:58:58 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, zijianyue <zijianyue <at> 163.com>,
>> 16045 <at> debbugs.gnu.org
>> Date: Thu, 05 Dec 2013 16:10:26 +0100
>> 
>> Hard for Tramp. It gets a long string as argument of
>> `start-file-process-shell-command', which looks like the example in
>> <http://thread.gmane.org/gmane.emacs.tramp/8233/focus=8244>. How shall
>> Tramp parse it?
>
> Why should it parse it?  Isn't \n\ removed on the remote end before
> the shell there interprets it?

I'm not sure, whether it works under any circumstance. For example:

$ cat <<EO\
> F
> xxx\
> yyy
> EO\
> F
> EOF
xxxyyy
EOF
$ 

The heredoc does not understand the first EOF, when written as

EO\
F

Granted, that is malicious example. But it shows we need some knowledge
about the string, and where to add \\n.

>> Where does it know from, how long a command line in the remote shell
>> could be?
>
> How do you know that in grep.el?

grep.el doesn't know it either. But it knows more about the arguments,
and where to add that line break.

Best regards, Michael.

Message #32 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 22:23:46 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: monnier <at> iro.umontreal.ca,  zijianyue <at> 163.com,  16045 <at> debbugs.gnu.org
> Date: Thu, 05 Dec 2013 20:58:58 +0100
> 
> > Why should it parse it?  Isn't \n\ removed on the remote end before
> > the shell there interprets it?
> 
> I'm not sure, whether it works under any circumstance. For example:
> 
> $ cat <<EO\
> > F
> > xxx\
> > yyy
> > EO\
> > F
> > EOF
> xxxyyy
> EOF
> $ 
> 
> The heredoc does not understand the first EOF, when written as

Such commands have short lines anyway, so you would never need to
break them.  So in practice here documents should never be a problem.

Are there any other circumstances where a command cannot be broken in
an arbitrary place?

Anyway, you could break on whitespace, to be on the safe side.

> >> Where does it know from, how long a command line in the remote shell
> >> could be?
> >
> > How do you know that in grep.el?
> 
> grep.el doesn't know it either. But it knows more about the arguments,
> and where to add that line break.

The question was about the remote shell limitations, so knowing about
the arguments doesn't help.

Message #35 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 21:50:10 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Such commands have short lines anyway, so you would never need to
> break them.  So in practice here documents should never be a problem.

I know. I just wanted to demonstrate, that you cannot enter that line
break at any arbitrary point.

> Are there any other circumstances where a command cannot be broken in
> an arbitrary place?

Don't know.

> Anyway, you could break on whitespace, to be on the safe side.

Nope, see here:

$ cat <<EO\ F
> xxx \
> yyy
> EO \
> F
> EO F
xxx \
yyy
EO \
F

Again, a very unfriendly and malicious example. But shit happens.

> The question was about the remote shell limitations, so knowing about
> the arguments doesn't help.

It doesn't help to know the exact limitations. But it helps to know
where a potential line break could be placed.

Best regards, Michael.

Message #38 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 16:09:37 -0500

>> Why should it parse it?  Isn't \n\ removed on the remote end before
>> the shell there interprets it?
> I'm not sure, whether it works under any circumstance.

We can start by aiming for spaces.


        Stefan

Message #41 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Fri, 06 Dec 2013 10:12:17 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Why should it parse it?  Isn't \n\ removed on the remote end before
> the shell there interprets it?

The shell interprets the \n\\ sequence.  Whether it is removed is
dependent on the quoting state.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #44 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Fri, 06 Dec 2013 10:16:44 +0100

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Why should it parse it?  Isn't \n\ removed on the remote end before
>> the shell there interprets it?
>
> The shell interprets the \n\\ sequence.  Whether it is removed is
                           \\\n

> dependent on the quoting state.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #47 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Fri, 06 Dec 2013 16:39:59 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> We can start by aiming for spaces.

I've committed a patch to tramp-sh.el, and I've removed the changes from
grep.el and compile.el from a year ago.

Eli, could you please test on MS Windows? And somebody (besides me)
could test rgrep for a remote directory? We don't have an ert test case
for rgrep yet :-(

I would close the bug afterwards.

>         Stefan

Best regards, Michael.

Message #50 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Fri, 06 Dec 2013 17:58:39 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  zijianyue <at> 163.com,  16045 <at> debbugs.gnu.org
> Date: Fri, 06 Dec 2013 16:39:59 +0100
> 
> Eli, could you please test on MS Windows?

It works, thanks.

> And somebody (besides me) could test rgrep for a remote directory?

It's not enough to test with a remote directory, we need to test it
when it exceeds the line-length limits, no?

Message #53 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Fri, 06 Dec 2013 17:15:28 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> It's not enough to test with a remote directory, we need to test it
> when it exceeds the line-length limits, no?

Yes. According to my tests, the problem happens when you apply rgrep
(loooong parameter list of find), and Tramp uses on the remote side
ksh. For other shells like zsh or bash I haven't seen any problem.

However, Tramp does not care about the remote shell, and starts to
insert "\\\n" every 500 bytes of the command line, looking for the
next space there. Using rgrep for tests shall be sufficient, I believe.

Best regrads, Michael.

Message #56 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: zijianyue <zijianyue <at> 163.com>
To: "Michael Albinus" <michael.albinus <at> gmx.de>, "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 16045 <16045 <at> debbugs.gnu.org>, monnier <monnier <at> iro.umontreal.ca>
Subject: 回复: Re: bug#16045: 24.3.50; rgrep can't work
Date: Mon, 9 Dec 2013 13:23:16 +0800

[Message part 1 (text/plain, inline)]

GREAT！rgrep works well now in the 2013-12-07 version,thanks for your work!!!




zijianyue

From: Michael Albinus
Date: 2013-12-07 00:15
To: Eli Zaretskii
CC: monnier; zijianyue; 16045
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Eli Zaretskii <eliz <at> gnu.org> writes:

> It's not enough to test with a remote directory, we need to test it
> when it exceeds the line-length limits, no?

Yes. According to my tests, the problem happens when you apply rgrep
(loooong parameter list of find), and Tramp uses on the remote side
ksh. For other shells like zsh or bash I haven't seen any problem.

However, Tramp does not care about the remote shell, and starts to
insert "\\\n" every 500 bytes of the command line, looking for the
next space there. Using rgrep for tests shall be sufficient, I believe.

Best regrads, Michael.

[Message part 2 (text/html, inline)]

Message #61 received at 16045-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: zijianyue <zijianyue <at> 163.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16045 <16045-done <at> debbugs.gnu.org>
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Mon, 09 Dec 2013 08:20:16 +0100

zijianyue <zijianyue <at> 163.com> writes:

> GREAT！rgrep works well now in the 2013-12-07 version,thanks for your
> work!!!
> ----------------------------------------------------------------------
> zijianyue

Thanks for confirmation. I'm marking this bug as closed.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.