bug#16582: Bug: tramp shell command doesn't read stdin

bug#16582: Bug: tramp shell command doesn't read stdin

[Sylvain Chouleur]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

 Hi,

there is a regression introduced by this commit:

e43048325611953396186b569447a3754422ddc3
Author: Michael Albinus <michael.albinus@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.

[-- Attachment #2: Type: text/html, Size: 4618 bytes --]

bug#16582: Bug: tramp shell command doesn't read stdin

[Michael Albinus]

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'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.

bug#16582: Bug: tramp shell command doesn't read stdin

[Sylvain Chouleur]

[-- Attachment #1.1: Type: text/plain, Size: 3138 bytes --]

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@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'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.
>

[-- Attachment #1.2: Type: text/html, Size: 3996 bytes --]

[-- Attachment #2: 0001-Fix-tramp-sh-handle-start-file-process-stdin.patch --]
[-- Type: text/x-patch, Size: 2036 bytes --]

From 2b9e28e2e453a068eb8898fb83d1d71008fdf3ff Mon Sep 17 00:00:00 2001
From: Sylvain Chouleur <sylvain.chouleur@gmail.com>
Date: Fri, 24 Jan 2014 17:46:06 +0100
Subject: [PATCH] Fix tramp-sh-handle-start-file-process stdin

* net/tramp-sh.el (tramp-sh-handle-start-file-process):
The heredoc solution tho handle long command lines prevent the user to
pass some input to the program using stdin.
Use a coproc to pass the heredoc command to the shell
and preserved stdin for user input.
---
 lisp/net/tramp-sh.el | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
index 65d5f27e967c..3f4f2bf77d7b 100644
--- a/lisp/net/tramp-sh.el
+++ b/lisp/net/tramp-sh.el
@@ -2705,16 +2705,15 @@ the result will be a local, non-Tramp, filename."
 		   (cdr args)))
 	   (command
 	    (when (stringp program)
-	      (format "cd %s; exec %s env PS1=%s %s"
+	      (format "cd %s; exec env PS1=%s %s"
 		      (tramp-shell-quote-argument localname)
-		      (if heredoc "<<EOF" "")
 		      ;; Use a human-friendly prompt, for example for `shell'.
 		      (tramp-shell-quote-argument
 		       (format "%s %s"
 			       (file-remote-p default-directory)
 			       tramp-initial-end-of-output))
 		      (if heredoc
-			  (format "%s\n%s\nEOF" program (car args))
+			  (format "%s <(cat <<'EOF'\n%s\nEOF\n)" program (car args))
 			(mapconcat 'tramp-shell-quote-argument
 				   (cons program args) " ")))))
 	   (tramp-process-connection-type
@@ -4561,7 +4560,7 @@ function waits for output unless NOOUTPUT is set."
     ;; following syntax for here-documents.  This we cannot test; it
     ;; shall be set via `tramp-connection-properties'.
     (when (and (string-match "<<'EOF'" command)
-	       (not (tramp-get-connection-property vec "busybox" nil)))
+	       (tramp-get-connection-property vec "busybox" nil))
       ;; Unset $PS1 when using here documents, in order to avoid
       ;; multiple prompts.
       (setq command (concat "(PS1= ; " command "\n)")))
-- 
1.8.5.2

bug#16582: Bug: tramp shell command doesn't read stdin

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 3936 bytes --]

diff --git a/lisp/tramp-sh.el b/lisp/tramp-sh.el
index 65d5f27..67a517a 100644
--- a/lisp/tramp-sh.el
+++ b/lisp/tramp-sh.el
@@ -79,6 +79,9 @@ detected as prompt when being sent on echoing hosts, therefore.")
 (defconst tramp-initial-end-of-output "#$ "
   "Prompt when establishing a connection.")
 
+(defconst tramp-end-of-heredoc (md5 tramp-end-of-output)
+  "String used to recognize end of heredoc strings.")
+
 ;; Initialize `tramp-methods' with the supported methods.
 ;;;###tramp-autoload
 (add-to-list 'tramp-methods
@@ -1443,8 +1446,11 @@ be non-negative integers."
     (if (and (stringp acl-string) (tramp-remote-acl-p v)
 	     (progn
 	       (tramp-send-command
-		v (format "setfacl --set-file=- %s <<'EOF'\n%s\nEOF\n"
-			  (tramp-shell-quote-argument localname) acl-string))
+		v (format "setfacl --set-file=- %s <<'%s'\n%s\n%s\n"
+			  (tramp-shell-quote-argument localname)
+			  tramp-end-of-heredoc
+			  acl-string
+			  tramp-end-of-heredoc))
 	       (tramp-send-command-and-check v nil)))
 	;; Success.
 	(progn
@@ -2707,14 +2713,15 @@ the result will be a local, non-Tramp, filename."
 	    (when (stringp program)
 	      (format "cd %s; exec %s env PS1=%s %s"
 		      (tramp-shell-quote-argument localname)
-		      (if heredoc "<<EOF" "")
+		      (if heredoc (format "<<'%s'" tramp-end-of-heredoc) "")
 		      ;; Use a human-friendly prompt, for example for `shell'.
 		      (tramp-shell-quote-argument
 		       (format "%s %s"
 			       (file-remote-p default-directory)
 			       tramp-initial-end-of-output))
 		      (if heredoc
-			  (format "%s\n%s\nEOF" program (car args))
+			  (format "%s\n%s\n%s"
+				  program (car args) tramp-end-of-heredoc)
 			(mapconcat 'tramp-shell-quote-argument
 				   (cons program args) " ")))))
 	   (tramp-process-connection-type
@@ -3182,9 +3189,11 @@ the result will be a local, non-Tramp, filename."
 		      (tramp-send-command
 		       v
 		       (format
-			(concat rem-dec " <<'EOF'\n%sEOF")
+			(concat rem-dec " <<'%s'\n%s%s")
 			(tramp-shell-quote-argument localname)
-			(buffer-string)))
+			tramp-end-of-heredoc
+			(buffer-string)
+			tramp-end-of-heredoc))
 		      (tramp-barf-unless-okay
 		       v nil
 		       "Couldn't write region to `%s', decode using `%s' failed"
@@ -3302,10 +3311,12 @@ the result will be a local, non-Tramp, filename."
 		 (tramp-send-command-and-read
 		  v
 		  (format
-		   "tramp_vc_registered_read_file_names <<'EOF'\n%s\nEOF\n"
+		   "tramp_vc_registered_read_file_names <<'%s'\n%s\n%s\n"
+		   tramp-end-of-heredoc
 		   (mapconcat 'tramp-shell-quote-argument
 			      tramp-vc-registered-file-names
-			      "\n"))))
+			      "\n")
+		   tramp-end-of-heredoc)))
 
 	      (tramp-set-file-property
 	       v (car elt) (cadr elt) (cadr (cdr elt))))))
@@ -3580,9 +3591,12 @@ This function expects to be in the right *tramp* buffer."
 	 (format (concat "while read d; "
 			 "do if test -x $d/%s -a -f $d/%s; "
 			 "then echo tramp_executable $d/%s; "
-			 "break; fi; done <<'EOF'\n"
-			 "%s\nEOF")
-		 progname progname progname (mapconcat 'identity dirlist "\n")))
+			 "break; fi; done <<'%s'\n"
+			 "%s\n%s")
+		 progname progname progname
+		 tramp-end-of-heredoc
+		 (mapconcat 'identity dirlist "\n")
+		 tramp-end-of-heredoc))
 	(goto-char (point-max))
 	(when (search-backward "tramp_executable " nil t)
 	  (skip-chars-forward "^ ")
@@ -4560,7 +4574,7 @@ function waits for output unless NOOUTPUT is set."
     ;; Some busyboxes tend to close the connection when we use the
     ;; following syntax for here-documents.  This we cannot test; it
     ;; shall be set via `tramp-connection-properties'.
-    (when (and (string-match "<<'EOF'" command)
+    (when (and (string-match (format "<<'%s'" tramp-end-of-heredoc) command)
 	       (not (tramp-get-connection-property vec "busybox" nil)))
       ;; Unset $PS1 when using here documents, in order to avoid
       ;; multiple prompts.

bug#16582: Bug: tramp shell command doesn't read stdin

[Sylvain Chouleur]

[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

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@gmx.de>:

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

[-- Attachment #2: Type: text/html, Size: 2344 bytes --]

bug#16582: Bug: tramp shell command doesn't read stdin

[Michael Albinus]

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

bug#16582: Bug: tramp shell command doesn't read stdin

[Sylvain Chouleur]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

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@gmx.de>:

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

[-- Attachment #2: Type: text/html, Size: 2860 bytes --]

bug#16582: Bug: tramp shell command doesn't read stdin

[Michael Albinus]

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

bug#16582: Bug: tramp shell command doesn't read stdin

[Sylvain Chouleur]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

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@gmx.de>:

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

[-- Attachment #2: Type: text/html, Size: 1829 bytes --]

bug#16582: Bug: tramp shell command doesn't read stdin

[Michael Albinus]

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

bug#16582: Bug: tramp shell command doesn't read stdin

[Sylvain Chouleur]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

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@gmx.de>:

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

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

bug#16582: Bug: tramp shell command doesn't read stdin

[Michael Albinus]

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

bug#16582: Bug: tramp shell command doesn't read stdin

[Sylvain Chouleur]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

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@gmx.de>:

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

[-- Attachment #2: Type: text/html, Size: 2305 bytes --]

bug#16582: Bug: tramp shell command doesn't read stdin

[Michael Albinus]

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