* bug#16045: 24.3.50; rgrep can't work
@ 2013-12-04 5:57 zijianyue
2013-12-04 17:24 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: zijianyue @ 2013-12-04 5:57 UTC (permalink / raw)
To: 16045
[-- Attachment #1: Type: text/plain, Size: 7189 bytes --]
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@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)
[-- Attachment #2: Type: text/html, Size: 14112 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-04 5:57 bug#16045: 24.3.50; rgrep can't work zijianyue
@ 2013-12-04 17:24 ` Eli Zaretskii
2013-12-04 19:10 ` Stefan Monnier
2013-12-05 15:14 ` Michael Albinus
0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2013-12-04 17:24 UTC (permalink / raw)
To: Michael Albinus, zijianyue; +Cc: 16045
> Date: Wed, 4 Dec 2013 13:57:45 +0800
> From: zijianyue <zijianyue@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@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 "))))))
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-04 17:24 ` Eli Zaretskii
@ 2013-12-04 19:10 ` Stefan Monnier
2013-12-04 19:36 ` Eli Zaretskii
2013-12-05 15:10 ` Michael Albinus
2013-12-05 15:14 ` Michael Albinus
1 sibling, 2 replies; 19+ messages in thread
From: Stefan Monnier @ 2013-12-04 19:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045, Michael Albinus
> @@ -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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-04 19:10 ` Stefan Monnier
@ 2013-12-04 19:36 ` Eli Zaretskii
2013-12-04 20:52 ` Stefan Monnier
2013-12-05 15:10 ` Michael Albinus
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2013-12-04 19:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: zijianyue, 16045, michael.albinus
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Michael Albinus <michael.albinus@gmx.de>, zijianyue <zijianyue@163.com>, 16045@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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-04 19:36 ` Eli Zaretskii
@ 2013-12-04 20:52 ` Stefan Monnier
0 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2013-12-04 20:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045, michael.albinus
> You mean, the fix that created this problem, yes?
Yes, the extra "\\\n" thingies.
Stefan
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-04 19:10 ` Stefan Monnier
2013-12-04 19:36 ` Eli Zaretskii
@ 2013-12-05 15:10 ` Michael Albinus
2013-12-05 17:55 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Michael Albinus @ 2013-12-05 15:10 UTC (permalink / raw)
To: Stefan Monnier; +Cc: zijianyue, 16045
Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-04 17:24 ` Eli Zaretskii
2013-12-04 19:10 ` Stefan Monnier
@ 2013-12-05 15:14 ` Michael Albinus
1 sibling, 0 replies; 19+ messages in thread
From: Michael Albinus @ 2013-12-05 15:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-05 15:10 ` Michael Albinus
@ 2013-12-05 17:55 ` Eli Zaretskii
2013-12-05 19:58 ` Michael Albinus
2013-12-06 9:12 ` Andreas Schwab
0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2013-12-05 17:55 UTC (permalink / raw)
To: Michael Albinus; +Cc: zijianyue, 16045
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, zijianyue <zijianyue@163.com>, 16045@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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-05 17:55 ` Eli Zaretskii
@ 2013-12-05 19:58 ` Michael Albinus
2013-12-05 20:23 ` Eli Zaretskii
2013-12-05 21:09 ` Stefan Monnier
2013-12-06 9:12 ` Andreas Schwab
1 sibling, 2 replies; 19+ messages in thread
From: Michael Albinus @ 2013-12-05 19:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>, zijianyue <zijianyue@163.com>,
>> 16045@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-05 19:58 ` Michael Albinus
@ 2013-12-05 20:23 ` Eli Zaretskii
2013-12-05 20:50 ` Michael Albinus
2013-12-05 21:09 ` Stefan Monnier
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2013-12-05 20:23 UTC (permalink / raw)
To: Michael Albinus; +Cc: zijianyue, 16045
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@iro.umontreal.ca, zijianyue@163.com, 16045@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-05 20:23 ` Eli Zaretskii
@ 2013-12-05 20:50 ` Michael Albinus
0 siblings, 0 replies; 19+ messages in thread
From: Michael Albinus @ 2013-12-05 20:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-05 19:58 ` Michael Albinus
2013-12-05 20:23 ` Eli Zaretskii
@ 2013-12-05 21:09 ` Stefan Monnier
2013-12-06 15:39 ` Michael Albinus
1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2013-12-05 21:09 UTC (permalink / raw)
To: Michael Albinus; +Cc: zijianyue, 16045
>> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-05 17:55 ` Eli Zaretskii
2013-12-05 19:58 ` Michael Albinus
@ 2013-12-06 9:12 ` Andreas Schwab
2013-12-06 9:16 ` Andreas Schwab
1 sibling, 1 reply; 19+ messages in thread
From: Andreas Schwab @ 2013-12-06 9:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045, Michael Albinus
Eli Zaretskii <eliz@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-06 9:12 ` Andreas Schwab
@ 2013-12-06 9:16 ` Andreas Schwab
0 siblings, 0 replies; 19+ messages in thread
From: Andreas Schwab @ 2013-12-06 9:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045, Michael Albinus
Andreas Schwab <schwab@linux-m68k.org> writes:
> Eli Zaretskii <eliz@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-05 21:09 ` Stefan Monnier
@ 2013-12-06 15:39 ` Michael Albinus
2013-12-06 15:58 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Michael Albinus @ 2013-12-06 15:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: zijianyue, 16045
Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-06 15:39 ` Michael Albinus
@ 2013-12-06 15:58 ` Eli Zaretskii
2013-12-06 16:15 ` Michael Albinus
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2013-12-06 15:58 UTC (permalink / raw)
To: Michael Albinus; +Cc: zijianyue, 16045
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, zijianyue@163.com, 16045@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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-06 15:58 ` Eli Zaretskii
@ 2013-12-06 16:15 ` Michael Albinus
2013-12-09 5:23 ` bug#16045: 回复: " zijianyue
0 siblings, 1 reply; 19+ messages in thread
From: Michael Albinus @ 2013-12-06 16:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: zijianyue, 16045
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 回复: Re: bug#16045: 24.3.50; rgrep can't work
2013-12-06 16:15 ` Michael Albinus
@ 2013-12-09 5:23 ` zijianyue
2013-12-09 7:20 ` Michael Albinus
0 siblings, 1 reply; 19+ messages in thread
From: zijianyue @ 2013-12-09 5:23 UTC (permalink / raw)
To: Michael Albinus, Eli Zaretskii; +Cc: 16045
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
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@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.
[-- Attachment #2: Type: text/html, Size: 2934 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#16045: 24.3.50; rgrep can't work
2013-12-09 5:23 ` bug#16045: 回复: " zijianyue
@ 2013-12-09 7:20 ` Michael Albinus
0 siblings, 0 replies; 19+ messages in thread
From: Michael Albinus @ 2013-12-09 7:20 UTC (permalink / raw)
To: zijianyue; +Cc: 16045
zijianyue <zijianyue@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-12-09 7:20 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-04 5:57 bug#16045: 24.3.50; rgrep can't work zijianyue
2013-12-04 17:24 ` Eli Zaretskii
2013-12-04 19:10 ` Stefan Monnier
2013-12-04 19:36 ` Eli Zaretskii
2013-12-04 20:52 ` Stefan Monnier
2013-12-05 15:10 ` Michael Albinus
2013-12-05 17:55 ` Eli Zaretskii
2013-12-05 19:58 ` Michael Albinus
2013-12-05 20:23 ` Eli Zaretskii
2013-12-05 20:50 ` Michael Albinus
2013-12-05 21:09 ` Stefan Monnier
2013-12-06 15:39 ` Michael Albinus
2013-12-06 15:58 ` Eli Zaretskii
2013-12-06 16:15 ` Michael Albinus
2013-12-09 5:23 ` bug#16045: 回复: " zijianyue
2013-12-09 7:20 ` Michael Albinus
2013-12-06 9:12 ` Andreas Schwab
2013-12-06 9:16 ` Andreas Schwab
2013-12-05 15:14 ` Michael Albinus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).