3

I have two scripts:

  • test_input.sh is a script which is executed through SSH. In this script I ask the user for something in input.
  • test_ssh_connection.sh is a script which connects to localhost and executes the script test_input.sh

In test_ssh_connection.sh I want to redirect the output of test_input.sh to a file, but in test_input.sh I want to display on screen the input prompt, becuase I want to be able to see that prompt.

This is my test_ssh_connection.sh:

echo "Connecting to localhost and executing an input script."
ssh "localhost" "sh test_input.sh" >> "test.txt"

this is test_input.sh:

echo -n "Give me a value: "
read value
echo "You gave me [${value}]."

Actually, this is the content of test.txt after executing test_ssh_connection.sh:

Give me a value: You gave me [asd].

Currently, the prompt Give me a value: is only in test.txt and not in terminal. Instead, what I want is to display it in the terminal and, if it's possibile, I would like to remove it from test.txt.

I've found this question, but it seems that if the subscript is called through ssh >/dev/tty/>$(tty) do not work.

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
Ricky Sixx
  • 133
  • 7
  • Welcome on U&L! Have you tried without the `-t` option to `ssh`? Do you have any specific reason for using it? – fra-san Jun 17 '19 at 09:05
  • @fra-san I've added that option because otherwise I get this error if I use `>/dev/tty` redirection: `test_input.sh: line 1: /dev/tty: No such device or address`. Anyway, I've tried to remove it but the script is still showing the prompt only on the file and not in the terminal. I've updated my question. – Ricky Sixx Jun 17 '19 at 09:13
  • Ok, sorry, I missed that bit. You may use `echo -n "Give me a value: " >&2`, printing messages to the user on standard error. In this test case it should do what you are asking for. – fra-san Jun 17 '19 at 09:22
  • @fra-san yes, it works, but is there another way? I would like to keep stderr for messages that are really **errors** – Ricky Sixx Jun 17 '19 at 14:23
  • 1
    The limitation you face is that `ssh` only provides you with three streams. While you can `exec 4>&1; echo prompt >&4; ...` to have a _local_ script prompt to the terminal while redirecting its stdout to a file, you cannot have `ssh` client pass further file descriptors to the server. The remote script only has stdout and stderr to send data to your local shell. Forcing terminal allocation with `-t` is not a solution because it still doesn't allow you to separate ordinary output and prompts to the user. You may work around this, but I think the good advice is that in Kusalananda's answer. – fra-san Jun 17 '19 at 20:21
  • @fra-san thank you for your help too, I've decided to use the standard error stream as you initially suggested :) – Ricky Sixx Jun 19 '19 at 06:48

1 Answers1

2

Prompts and other interactive messages that are not part of an application's ordinary output are usually written to the standard error stream for this very reason. It is, for example, to the shell's standard error stream that the primary prompt is written.

The read utility in bash will display the prompt on standard error when given with -p:

#!/bin/bash

read -r -p 'Give me a value: ' value
printf 'You gave me [%s].\n' "$value"

With /bin/sh you would do something like

#!/bin/sh

printf 'Give me a value: ' >&2
read -r value
printf 'You gave me [%s].\n' "$value"

The redirection >&2 will redirect the output of printf to standard error.

Related:

Would you want to write directly to the TTY, then use the second of these two variations and redirect the prompt message with >/dev/tty. Note that you will have to use ssh -t to allocate a pseudo-TTY for this to work. Also note that you are breaking a fairly common custom by not using standard error for prompting if you do this.

Kusalananda
  • 320,670
  • 36
  • 633
  • 936
  • I've always thought that the standard error should be used for messages that are errors... but now I realized that I've always thought wrong. – Ricky Sixx Jun 19 '19 at 06:46
  • 2
    @Riccardo If you mispronounce standard error as "standard other", it would more accurately describe its purpose. – Kusalananda Jun 19 '19 at 06:54