* 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-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 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
* 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-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
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).