GNU bug report logs - #16582
Bug: tramp shell command doesn't read stdin

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 16582 in the body.
You can then email your comments to 16582 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: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Bug: tramp shell command doesn't read stdin
Date: Tue, 28 Jan 2014 23:40:06 +0100

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

 Hi,

there is a regression introduced by this commit:

e43048325611953396186b569447a3754422ddc3
Author: Michael Albinus <michael.albinus <at> gmx.de>
Date:   Fri Dec 6 16:34:06 2013 +0100

    Bug#16045

    * progmodes/compile.el (compilation-start):
    * progmodes/grep.el (rgrep): Revert change of 2012-12-20 (r111276).

    * net/tramp-sh.el (tramp-sh-handle-start-file-process):
    Handle long command lines, lasting from "sh -c ...".  (Bug#16045)


The following syntax used to execute tramp shell command:
exec <<EOF /bin/bash
commands
EOF
prevents users to send inputs to bash using stdin.
For example, the following does not works anymore:

exec <<EOF /bin/bash
read line;
echo $line;
EOF

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 <<EOF)

What do you think?

-- 
Sylvain

PS: I've already posted on tramp-devel mailing list but it seems there is
no activity there.

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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 29 Jan 2014 15:35:45 +0100

Sylvain Chouleur <sylvain.chouleur <at> 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'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 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.

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

From: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Sun, 2 Feb 2014 15:27:35 +0100

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

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 <michael.albinus <at> gmx.de>:

> Sylvain Chouleur <sylvain.chouleur <at> 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'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 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.
>

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

[0001-Fix-tramp-sh-handle-start-file-process-stdin.patch (text/x-patch, attachment)]

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Mon, 03 Feb 2014 13:53:36 +0100

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

Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:

> Hi,

Hi Sylvain,

> Here is my proposal (patch in attachment)
>
> exec env PS1=.. bash <(cat <<'EOF'
> heredoc commands
> EOF
> )

Thanks for this. However, I'm not sure whether all bourne shell
derivates support process substitution <().

What if Tramp uses another heredoc delimeter but 'EOF'? I've appended a
respective patch; could you, please, check?

If it doesn't work for you, please set tramp-verbose to 6, and rerun
your test. I would like to see the Tramp debug buffer then. Explain
also, what you have invoked, and how.

Best regards, Michael.

[diff (text/x-diff, attachment)]

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

From: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Tue, 4 Feb 2014 23:53:26 +0100

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

Hi Michael,

replacing EOF delimiter by a md5sum works well.

The process substitution works only for real bash shells, or zsh.
It does not work with sh or busybox.

So I think we have two solutions here:
 - Support multiple methods, chosen by user configuration:
   -> bash -c "cmd" which doesn't support very long commands
   -> bash <<EOF which doesn't support stdin
   -> bash <(cat <<EOF) which supports all but which doesn't works on basic
shells like sh or busybox (works with bash and zsh)
 - Reproduce method 3 by writting commands in a target's temporary file,
launch the shell with this file in argument, and finally remove the file
from the target.

The last solution have the major drawback to execute extra commands each
time and to have a writable filesystem usable on the target

Cheers,
-- 
Sylvain


2014-02-03 Michael Albinus <michael.albinus <at> gmx.de>:

> Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:
>
> > Hi,
>
> Hi Sylvain,
>
> > Here is my proposal (patch in attachment)
> >
> > exec env PS1=.. bash <(cat <<'EOF'
> > heredoc commands
> > EOF
> > )
>
> Thanks for this. However, I'm not sure whether all bourne shell
> derivates support process substitution <().
>
> What if Tramp uses another heredoc delimeter but 'EOF'? I've appended a
> respective patch; could you, please, check?
>
> If it doesn't work for you, please set tramp-verbose to 6, and rerun
> your test. I would like to see the Tramp debug buffer then. Explain
> also, what you have invoked, and how.
>
> Best regards, Michael.
>
>

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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 05 Feb 2014 09:29:10 +0100

Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:

> Hi Michael,

Hi Sylvain,

> replacing EOF delimiter by a md5sum works well.

Good.

> The process substitution works only for real bash shells, or zsh.
> It does not work with sh or busybox.
>
> So I think we have two solutions here:
> - Support multiple methods, chosen by user configuration:
> -> bash -c "cmd" which doesn't support very long commands
> -> bash <<EOF which doesn't support stdin
> -> bash <(cat <<EOF) which supports all but which doesn't works on
> basic shells like sh or busybox (works with bash and zsh)
> - Reproduce method 3 by writting commands in a target's temporary
> file, launch the shell with this file in argument, and finally remove
> the file from the target.
>
> The last solution have the major drawback to execute extra commands
> each time and to have a writable filesystem usable on the target

I don't get your point. If my patch works well (as you said above), why
do you want to change something else?

If you still have problems with my patch, please give me an exact recipe
what triggers the problem. I cannot reproduce the problem here, sorry.
A Tramp debug buffer, produced with tramp-verbose set to 6, would help.

> Cheers,

Best regards, Michael.

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

From: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 5 Feb 2014 10:44:03 +0100

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

I'm sorry, may be I was not clear:

replacing EOF by another delimiter does not solve anything, it just make
the way tramp uses heredocs more robust because it avoids conflicts with
user commands potentially using the same delimiter.

That said, we still have the original issue of the bz I raised:
by executing tramp shell commands in this way:
exec <<'EOF' bash
<commands>
EOF

we loose the possibility to send user inputs to bash, so commands like
'read' will not work.
That's why I proposed the two approaches to handle your problem (long line
arguments) and my problem (bash stdin)

-- 
Sylvain


2014-02-05 Michael Albinus <michael.albinus <at> gmx.de>:

> Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:
>
> > Hi Michael,
>
> Hi Sylvain,
>
> > replacing EOF delimiter by a md5sum works well.
>
> Good.
>
> > The process substitution works only for real bash shells, or zsh.
> > It does not work with sh or busybox.
> >
> > So I think we have two solutions here:
> > - Support multiple methods, chosen by user configuration:
> > -> bash -c "cmd" which doesn't support very long commands
> > -> bash <<EOF which doesn't support stdin
> > -> bash <(cat <<EOF) which supports all but which doesn't works on
> > basic shells like sh or busybox (works with bash and zsh)
> > - Reproduce method 3 by writting commands in a target's temporary
> > file, launch the shell with this file in argument, and finally remove
> > the file from the target.
> >
> > The last solution have the major drawback to execute extra commands
> > each time and to have a writable filesystem usable on the target
>
> I don't get your point. If my patch works well (as you said above), why
> do you want to change something else?
>
> If you still have problems with my patch, please give me an exact recipe
> what triggers the problem. I cannot reproduce the problem here, sorry.
> A Tramp debug buffer, produced with tramp-verbose set to 6, would help.
>
> > Cheers,
>
> Best regards, Michael.
>

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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 05 Feb 2014 11:27:26 +0100

Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:

> That said, we still have the original issue of the bz I raised:
> by executing tramp shell commands in this way:
> exec <<'EOF' bash
> <commands>
> EOF
>
> we loose the possibility to send user inputs to bash, so commands like
> 'read' will not work.
> That's why I proposed the two approaches to handle your problem (long
> line arguments) and my problem (bash stdin)

Please give me a concrete Lisp example how you invoke this. Otherwise I
cannot debug; my examples do work.

Alternatively, tell me what you have entered, starting with "M-x".

Best regards, Michael.

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

From: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 5 Feb 2014 13:27:17 +0100

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

Go into a tramp buffer, then execute:
(async-shell-command "echo -n \"Type something:\"; read line; echo
line=$line" nil nil)

Your command will print:

Type something:line=

and terminate.
It should have printed

Type something:

waited for your keyboard input and print:

line=<your keyboard input>



2014-02-05 Michael Albinus <michael.albinus <at> gmx.de>:

> Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:
>
> > That said, we still have the original issue of the bz I raised:
> > by executing tramp shell commands in this way:
> > exec <<'EOF' bash
> > <commands>
> > EOF
> >
> > we loose the possibility to send user inputs to bash, so commands like
> > 'read' will not work.
> > That's why I proposed the two approaches to handle your problem (long
> > line arguments) and my problem (bash stdin)
>
> Please give me a concrete Lisp example how you invoke this. Otherwise I
> cannot debug; my examples do work.
>
> Alternatively, tell me what you have entered, starting with "M-x".
>
> Best regards, Michael.
>

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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 05 Feb 2014 15:04:33 +0100

Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:

> Go into a tramp buffer, then execute:
> (async-shell-command "echo -n \"Type something:\"; read line; echo
> line=$line" nil nil)
>
> Your command will print:
>
> Type something:line=
>
> and terminate.

Well, the problem is that the heredoc construct occupies STDIN, which is
not available for the shell command then. I will check what I can do.

Best regards, Michael.

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

From: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 5 Feb 2014 15:44:14 +0100

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

Yes, that is the problem I'm trying to explain since the beginning, I'm
please we have finally agreed on what was the issue :)

I didn't found any other solution than to call the shell like this:
bash <file>

With <file> containing the commands. With that type of call, bash keeps
reading STDIN for user inputs. That's why I've introduced the process
substitution solution


2014-02-05 Michael Albinus <michael.albinus <at> gmx.de>:

> Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:
>
> > Go into a tramp buffer, then execute:
> > (async-shell-command "echo -n \"Type something:\"; read line; echo
> > line=$line" nil nil)
> >
> > Your command will print:
> >
> > Type something:line=
> >
> > and terminate.
>
> Well, the problem is that the heredoc construct occupies STDIN, which is
> not available for the shell command then. I will check what I can do.
>
> Best regards, Michael.
>

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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 05 Feb 2014 16:33:32 +0100

Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:

> Yes, that is the problem I'm trying to explain since the beginning, I'm
> please we have finally agreed on what was the issue :)

What about this one (the new tramp-end-heredoc patch is already in):

--8<---------------cut here---------------start------------->8---
*** /home/albinmic/src/tramp/lisp/tramp-sh.el.~master~	2014-02-05 16:27:23.314546196 +0100
--- /home/albinmic/src/tramp/lisp/tramp-sh.el	2014-02-05 16:24:58.391993324 +0100
***************
*** 2720,2726 ****
  			       (file-remote-p default-directory)
  			       tramp-initial-end-of-output))
  		      (if heredoc
! 			  (format "%s\n%s\n%s"
  				  program (car args) tramp-end-of-heredoc)
  			(mapconcat 'tramp-shell-quote-argument
  				   (cons program args) " ")))))
--- 2720,2726 ----
  			       (file-remote-p default-directory)
  			       tramp-initial-end-of-output))
  		      (if heredoc
! 			  (format "%s\n(\n%s\n) </dev/tty\n%s"
  				  program (car args) tramp-end-of-heredoc)
  			(mapconcat 'tramp-shell-quote-argument
  				   (cons program args) " ")))))
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

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

From: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 16582 <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Wed, 5 Feb 2014 22:01:58 +0100

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

that's great! I didn't think about this one, it works very well.

Thank you a lot

-- 
Sylvain


2014-02-05 Michael Albinus <michael.albinus <at> gmx.de>:

> Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:
>
> > Yes, that is the problem I'm trying to explain since the beginning, I'm
> > please we have finally agreed on what was the issue :)
>
> What about this one (the new tramp-end-heredoc patch is already in):
>
> --8<---------------cut here---------------start------------->8---
> *** /home/albinmic/src/tramp/lisp/tramp-sh.el.~master~  2014-02-05
> 16:27:23.314546196 +0100
> --- /home/albinmic/src/tramp/lisp/tramp-sh.el   2014-02-05
> 16:24:58.391993324 +0100
> ***************
> *** 2720,2726 ****
>                                (file-remote-p default-directory)
>                                tramp-initial-end-of-output))
>                       (if heredoc
> !                         (format "%s\n%s\n%s"
>                                   program (car args) tramp-end-of-heredoc)
>                         (mapconcat 'tramp-shell-quote-argument
>                                    (cons program args) " ")))))
> --- 2720,2726 ----
>                                (file-remote-p default-directory)
>                                tramp-initial-end-of-output))
>                       (if heredoc
> !                         (format "%s\n(\n%s\n) </dev/tty\n%s"
>                                   program (car args) tramp-end-of-heredoc)
>                         (mapconcat 'tramp-shell-quote-argument
>                                    (cons program args) " ")))))
> --8<---------------cut here---------------end--------------->8---
>
> Best regards, Michael.
>

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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Sylvain Chouleur <sylvain.chouleur <at> gmail.com>
Cc: 16582-done <at> debbugs.gnu.org
Subject: Re: bug#16582: Bug: tramp shell command doesn't read stdin
Date: Thu, 06 Feb 2014 09:52:24 +0100

Sylvain Chouleur <sylvain.chouleur <at> gmail.com> writes:

> that's great! I didn't think about this one, it works very well.

I've committed the patch, closing the bug.

Best regards, Michael.

Previous Next

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