From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#16582: Bug: tramp shell command doesn't read stdin Date: Wed, 29 Jan 2014 15:35:45 +0100 Message-ID: <87k3di97pa.fsf@gmx.de> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391006177 15989 80.91.229.3 (29 Jan 2014 14:36:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jan 2014 14:36:17 +0000 (UTC) Cc: 16582@debbugs.gnu.org To: Sylvain Chouleur Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 29 15:36:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W8WFa-0005k1-Rk for geb-bug-gnu-emacs@m.gmane.org; Wed, 29 Jan 2014 15:36:23 +0100 Original-Received: from localhost ([::1]:42831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8WFa-0005ml-BB for geb-bug-gnu-emacs@m.gmane.org; Wed, 29 Jan 2014 09:36:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8WFN-0005YU-Mj for bug-gnu-emacs@gnu.org; Wed, 29 Jan 2014 09:36:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8WFG-0003LY-CC for bug-gnu-emacs@gnu.org; Wed, 29 Jan 2014 09:36:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8WFG-0003LT-9J for bug-gnu-emacs@gnu.org; Wed, 29 Jan 2014 09:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W8WFF-0008Fu-Tf for bug-gnu-emacs@gnu.org; Wed, 29 Jan 2014 09:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Jan 2014 14:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16582 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16582-submit@debbugs.gnu.org id=B16582.139100615531720 (code B ref 16582); Wed, 29 Jan 2014 14:36:01 +0000 Original-Received: (at 16582) by debbugs.gnu.org; 29 Jan 2014 14:35:55 +0000 Original-Received: from localhost ([127.0.0.1]:40017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8WF8-0008FY-5t for submit@debbugs.gnu.org; Wed, 29 Jan 2014 09:35:54 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:53034) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8WF4-0008FN-HI for 16582@debbugs.gnu.org; Wed, 29 Jan 2014 09:35:51 -0500 Original-Received: from detlef.gmx.de ([93.209.80.17]) by mail.gmx.com (mrgmx003) with ESMTPS (Nemesis) id 0MU1MP-1Vhwof2tu5-00Qkh4 for <16582@debbugs.gnu.org>; Wed, 29 Jan 2014 15:35:49 +0100 In-Reply-To: (Sylvain Chouleur's message of "Tue, 28 Jan 2014 23:40:06 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:hACJPWWNd+Ky8Lo9wm1S4p6qtaVMTGULwIVOtNGI88cWki47P5B NMSfeHb1dypPrbqRWvaY74Amq226bqx9f/90+mDdz7HIi2A9YpUCuZnejQ3LPALOM8sHMCo T1fX6PzU+P/ZhOPpsSnUsVLRqJC/7/0KRK2WiqOH9wndLygyqkuE3GqYgkP8yShmD4tq1QW v6ys6w0QQ7o8j/6rCh8eA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:84218 Archived-At: Sylvain Chouleur writes: > Hi, Hi Sylvain, > I don't understand what was this problem of long command lines > (Bug#16045): I've tried to execute shell comands with huge command > lines and all were successfull. > To keep the approach of splitting the lines, I would suggest something > like that: > exec /bin/bash -c " > commands > on > multiple lines > " > > But this needs to backslash all shell specific characters, and I don't > know if there is really benefit compared to the original solution > (before < > What do you think? The use case which has triggered the Bug#16045 is rgrep. Run `M-x rgrep' on a remote directory. This issues a command like this (in one line!): find . -type d \( -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 \! -type d \( -name .\#\* -o -name \*.o -o -name \*\~ -o -name \*.bin -o -name \*.lbin -o -name \*.so -o -name \*.a -o -name \*.ln -o -name \*.blg -o -name \*.bbl -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 \*.dfsl -o -name \*.pfsl -o -name \*.d64fsl -o -name \*.p64fsl -o -name \*.lx64fsl -o -name \*.lx32fsl -o -name \*.dx64fsl -o -name \*.dx32fsl -o -name \*.fx64fsl -o -name \*.fx32fsl -o -name \*.sx64fsl -o -name \*.sx32fsl -o -name \*.wx64fsl -o -name \*.wx32fsl -o -name \*.fasl -o -name \*.ufsl -o -name \*.fsl -o -name \*.dxl -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 \( -name \* -o -name .\* \) -exec grep -i -nH -e emacs {} + It didn't work with the previous Tramp command invocation, I could reproduce it locally. The changed command invocation, using a here-document, allows to execute the command. I understand your problem, and I would like to keep the previous command invocation method, but I don't know how to do. Breaking the command into several lines, escaped with "\\\n", doesn't work, because finally the shell interpreter removes those line breaks, and it is confronted with the long line, again. If somebody has a better idea, I would be happy to implement. Best regards, Michael. PS: Sorry for the late reply. I've seen your message on the Tramp ML as well, but I'm too busy just now for answering in short time.