From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sylvain Chouleur Newsgroups: gmane.emacs.bugs Subject: bug#16582: Bug: tramp shell command doesn't read stdin Date: Sun, 2 Feb 2014 15:27:35 +0100 Message-ID: References: <87k3di97pa.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a11c291e6911c1404f16d369c X-Trace: ger.gmane.org 1391352661 2468 80.91.229.3 (2 Feb 2014 14:51:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Feb 2014 14:51:01 +0000 (UTC) Cc: 16582@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 02 15:51:07 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 1W9yO3-0007Ar-7C for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Feb 2014 15:51:07 +0100 Original-Received: from localhost ([::1]:41563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9yO2-0004qn-T2 for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Feb 2014 09:51:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9yNN-0003gP-Qi for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2014 09:51:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9y1i-0007WK-Ql for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2014 09:28:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9y1i-0007W7-NF for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2014 09:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W9y1i-0003KY-6Z for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2014 09:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Sylvain Chouleur Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Feb 2014 14:28:02 +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.139135128112797 (code B ref 16582); Sun, 02 Feb 2014 14:28:02 +0000 Original-Received: (at 16582) by debbugs.gnu.org; 2 Feb 2014 14:28:01 +0000 Original-Received: from localhost ([127.0.0.1]:45730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9y1g-0003KI-3o for submit@debbugs.gnu.org; Sun, 02 Feb 2014 09:28:01 -0500 Original-Received: from mail-qc0-f173.google.com ([209.85.216.173]:48970) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9y1c-0003K8-Rk for 16582@debbugs.gnu.org; Sun, 02 Feb 2014 09:27:58 -0500 Original-Received: by mail-qc0-f173.google.com with SMTP id i8so9717766qcq.32 for <16582@debbugs.gnu.org>; Sun, 02 Feb 2014 06:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7nbsZ2VSYUh22gyyxXJnWITUKZ0CfeMnhluDj+S5Y18=; b=HDsLjl5R3fannJNeLzic5oAk0FwdSTHZKQOoFgL3fjQSCuQjGiOmygP4oromSXyzxG hF6TFLMEkKNbTlP9pGYmM2V5teupMId/qB+BTX/A8gOgRDk87531Q6vvUN+kQCl0bhaQ bzxygmT0bwyGNKmbK1tIIxe4rxwgV+hcrSQAUfPU/JBbLsn+Db3xir0lS1U5K4SbLbU+ I2LhmQpWXFNtozsH4j0cdh9aI3KDxN98x8VfNoWjaBlFsiSKBVSP80Ga/OMKa0UlStD4 KH7R97PX2CST53v651u+MOw67DIMBn/K4K+jp2P3a7M85rcRPxl0Laxex6J4QCjYIGqE N8Cw== X-Received: by 10.224.34.71 with SMTP id k7mr48438947qad.15.1391351276045; Sun, 02 Feb 2014 06:27:56 -0800 (PST) Original-Received: by 10.96.63.134 with HTTP; Sun, 2 Feb 2014 06:27:35 -0800 (PST) In-Reply-To: <87k3di97pa.fsf@gmx.de> 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:84449 Archived-At: --001a11c291e6911c1404f16d369c Content-Type: multipart/alternative; boundary=001a11c291e6911c0c04f16d369a --001a11c291e6911c0c04f16d369a Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is my proposal (patch in attachment) exec env PS1=.. bash <(cat <<'EOF' heredoc commands EOF ) bash is still reading stdin and long lines seems to work. Try it and let me know if any problems -- Sylvain 2014-01-29 Michael Albinus : > 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. > --001a11c291e6911c0c04f16d369a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Here is my proposal (patch in attac= hment)

exec env PS1=3D.. bash <(cat <<= 9;EOF'
heredoc commands
EOF
)
<= br>
bash is still reading stdin and long lines seems to work.
<= div>Try it and let me know if any problems

--=A0
Sylvain


2014-01-29 Michael Albinus <michael.albinus@gmx.de>:
Sylvain Chouleur <sylvain.= chouleur@gmail.com> 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&#= 39;t
> know if there is really benefit compared to the original solution
> (before <<EOF)
>
> What do you think?

The use case which has triggered the Bug#16045 is rgrep. Run `M-x rgr= ep'
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 int= o
several lines, escaped with "\\\n", doesn't work, because fin= ally 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.

--001a11c291e6911c0c04f16d369a-- --001a11c291e6911c1404f16d369c Content-Type: text/x-patch; charset=US-ASCII; name="0001-Fix-tramp-sh-handle-start-file-process-stdin.patch" Content-Disposition: attachment; filename="0001-Fix-tramp-sh-handle-start-file-process-stdin.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hr6elwlt0 RnJvbSAyYjllMjhlMmU0NTNhMDY4ZWI4ODk4ZmI4M2QxZDcxMDA4ZmRmM2ZmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTeWx2YWluIENob3VsZXVyIDxzeWx2YWluLmNob3VsZXVyQGdt YWlsLmNvbT4KRGF0ZTogRnJpLCAyNCBKYW4gMjAxNCAxNzo0NjowNiArMDEwMApTdWJqZWN0OiBb UEFUQ0hdIEZpeCB0cmFtcC1zaC1oYW5kbGUtc3RhcnQtZmlsZS1wcm9jZXNzIHN0ZGluCgoqIG5l dC90cmFtcC1zaC5lbCAodHJhbXAtc2gtaGFuZGxlLXN0YXJ0LWZpbGUtcHJvY2Vzcyk6ClRoZSBo ZXJlZG9jIHNvbHV0aW9uIHRobyBoYW5kbGUgbG9uZyBjb21tYW5kIGxpbmVzIHByZXZlbnQgdGhl IHVzZXIgdG8KcGFzcyBzb21lIGlucHV0IHRvIHRoZSBwcm9ncmFtIHVzaW5nIHN0ZGluLgpVc2Ug YSBjb3Byb2MgdG8gcGFzcyB0aGUgaGVyZWRvYyBjb21tYW5kIHRvIHRoZSBzaGVsbAphbmQgcHJl c2VydmVkIHN0ZGluIGZvciB1c2VyIGlucHV0LgotLS0KIGxpc3AvbmV0L3RyYW1wLXNoLmVsIHwg NyArKystLS0tCiAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygt KQoKZGlmZiAtLWdpdCBhL2xpc3AvbmV0L3RyYW1wLXNoLmVsIGIvbGlzcC9uZXQvdHJhbXAtc2gu ZWwKaW5kZXggNjVkNWYyN2U5NjdjLi4zZjRmMmJmNzdkN2IgMTAwNjQ0Ci0tLSBhL2xpc3AvbmV0 L3RyYW1wLXNoLmVsCisrKyBiL2xpc3AvbmV0L3RyYW1wLXNoLmVsCkBAIC0yNzA1LDE2ICsyNzA1 LDE1IEBAIHRoZSByZXN1bHQgd2lsbCBiZSBhIGxvY2FsLCBub24tVHJhbXAsIGZpbGVuYW1lLiIK IAkJICAgKGNkciBhcmdzKSkpCiAJICAgKGNvbW1hbmQKIAkgICAgKHdoZW4gKHN0cmluZ3AgcHJv Z3JhbSkKLQkgICAgICAoZm9ybWF0ICJjZCAlczsgZXhlYyAlcyBlbnYgUFMxPSVzICVzIgorCSAg ICAgIChmb3JtYXQgImNkICVzOyBleGVjIGVudiBQUzE9JXMgJXMiCiAJCSAgICAgICh0cmFtcC1z aGVsbC1xdW90ZS1hcmd1bWVudCBsb2NhbG5hbWUpCi0JCSAgICAgIChpZiBoZXJlZG9jICI8PEVP RiIgIiIpCiAJCSAgICAgIDs7IFVzZSBhIGh1bWFuLWZyaWVuZGx5IHByb21wdCwgZm9yIGV4YW1w bGUgZm9yIGBzaGVsbCcuCiAJCSAgICAgICh0cmFtcC1zaGVsbC1xdW90ZS1hcmd1bWVudAogCQkg ICAgICAgKGZvcm1hdCAiJXMgJXMiCiAJCQkgICAgICAgKGZpbGUtcmVtb3RlLXAgZGVmYXVsdC1k aXJlY3RvcnkpCiAJCQkgICAgICAgdHJhbXAtaW5pdGlhbC1lbmQtb2Ytb3V0cHV0KSkKIAkJICAg ICAgKGlmIGhlcmVkb2MKLQkJCSAgKGZvcm1hdCAiJXNcbiVzXG5FT0YiIHByb2dyYW0gKGNhciBh cmdzKSkKKwkJCSAgKGZvcm1hdCAiJXMgPChjYXQgPDwnRU9GJ1xuJXNcbkVPRlxuKSIgcHJvZ3Jh bSAoY2FyIGFyZ3MpKQogCQkJKG1hcGNvbmNhdCAndHJhbXAtc2hlbGwtcXVvdGUtYXJndW1lbnQK IAkJCQkgICAoY29ucyBwcm9ncmFtIGFyZ3MpICIgIikpKSkpCiAJICAgKHRyYW1wLXByb2Nlc3Mt Y29ubmVjdGlvbi10eXBlCkBAIC00NTYxLDcgKzQ1NjAsNyBAQCBmdW5jdGlvbiB3YWl0cyBmb3Ig b3V0cHV0IHVubGVzcyBOT09VVFBVVCBpcyBzZXQuIgogICAgIDs7IGZvbGxvd2luZyBzeW50YXgg Zm9yIGhlcmUtZG9jdW1lbnRzLiAgVGhpcyB3ZSBjYW5ub3QgdGVzdDsgaXQKICAgICA7OyBzaGFs bCBiZSBzZXQgdmlhIGB0cmFtcC1jb25uZWN0aW9uLXByb3BlcnRpZXMnLgogICAgICh3aGVuIChh bmQgKHN0cmluZy1tYXRjaCAiPDwnRU9GJyIgY29tbWFuZCkKLQkgICAgICAgKG5vdCAodHJhbXAt Z2V0LWNvbm5lY3Rpb24tcHJvcGVydHkgdmVjICJidXN5Ym94IiBuaWwpKSkKKwkgICAgICAgKHRy YW1wLWdldC1jb25uZWN0aW9uLXByb3BlcnR5IHZlYyAiYnVzeWJveCIgbmlsKSkKICAgICAgIDs7 IFVuc2V0ICRQUzEgd2hlbiB1c2luZyBoZXJlIGRvY3VtZW50cywgaW4gb3JkZXIgdG8gYXZvaWQK ICAgICAgIDs7IG11bHRpcGxlIHByb21wdHMuCiAgICAgICAoc2V0cSBjb21tYW5kIChjb25jYXQg IihQUzE9IDsgIiBjb21tYW5kICJcbikiKSkpCi0tIAoxLjguNS4yCgo= --001a11c291e6911c1404f16d369c--