PuTTY – Pasting Text with Tabs into a Here-Document

bashclipboardhere-documentputtyssh

I have a string with tab delimited data that looks like:

h1  h2
a1  b1
a2  b2

I produced it with Notepad on Windows. I created tab delimited data, ensuring that tabs and not spaces are used.

enter image description here

I connect to a Linux server via SSH using PuTTY.
I would like to write the file to /tmp/test.txt and preserve the tabs.
So I run cat <<EOF >/tmp/test.txt. I copy the text from Notepad and paste it into the putty session. Then I enter EOF.

enter image description here

However, that produces a file without tabs having the contents of:

h1h2
a1b1
a2b2

I've found that this works:

sed 's/\\t/\t/g' > /tmp/test.txt << EOF
h1\th2
a1\tb1
a2\tb2
EOF

However, it required that I change my input string to use '\t' instead of actual tabs. What is a more elegant/simple solution that allows me to take a string literal as-is from Windows and write it into a file on the remote Linux machine?

I am SSHed into a Linux server from Windows via putty. The server is:

Distribution: Red Hat Enterprise Linux Server release 6.6 (Santiago)
Bash version: 4.1.2(1)-release (x86_64-redhat-linux-gnu)
cat: coreutils-8.4-37.0.1.el6.x86_64

Best Answer

When you type into a shell, the shell recognizes some characters as commands. For example, the carriage return character (the character sent by the Enter key) causes the shell to execute the command. The tab character causes the shell to perform completion. When you paste something into the PuTTY terminal window, from the shell's point of view, that's the same thing as if you'd typed these characters. So at the point the tab character is pasted, the shell performs completion, it doesn't insert a tab.

The easiest way to copy a file without it being transformed would be to use PuTTY's companion program PSCP or PSFTP to copy the file. This is the simplest way conceptually, but it does have the overhead of running another program, authenticating, choosing a directory, etc.

If you want something inline, you can paste directly into cat, rather than in a here document. Then you'd be pasting into the terminal's line editor, not into the shell's line editor. As the terminal's line editor is very primitive, only a few control characters have a special meaning there, not including tab. Press Ctrl+D at the beginning of a line to terminate the input.

[darkstar /]$ cat >text.txt
Paste
Ctrl+D
[darkstar /]$

I you want to transfer arbitrary data over a medium that interprets control characters, you can encode it into a form that uses only “tame” characters. Base64 is one; it doesn't use any control character and ignores whitespace and newlines. GNU coreutils, which is part of the basic installation on Linux and Cygwin, includes a base64 command. On the sender side, run base64 <file-to-decode, e.g.

On Windows: run base64 c:/path/to/test.txt from a Cygwin terminal
Copy the output.
In the shell in the PuTTY window, type `base64 -d >/tmp/test.txt and press Enter.
Paste the output from base64.
Press Ctrl+D.

Example - mechanics of process substitution

Step #1 - make a fifo, output to it

$ mkfifo /var/tmp/fifo1
$ fmt --width=10 <<<"$(seq 10)" > /var/tmp/fifo1 &
[1] 5492

Step #2 - read the fifo

$ cat /var/tmp/fifo1
1 2 3 4
5 6 7 8
9 10
[1]+  Done                    fmt --width=10 <<< "$(seq 10)" > /var/tmp/fifo1

The use of parens within the HEREDOC also seems OK:

Example - just using a FIFO

Step #1 - output to FIFO

$ fmt --width=10 <<FOO > /var/tmp/fifo1 &
(one)
(two
FOO
[1] 10628

Step #2 - read contents of FIFO

$ cat /var/tmp/fifo1
(one)
(two

The trouble, I believe you're running into is that the process substitution, <(...), doesn't seem to care for the nesting of parens within it.

Example - process sub + HEREDOC don't work

$ cat <(fmt --width=10 <<FOO
(one)
(two
FOO
)
bash: bad substitution: no closing `)' in <(fmt --width=10 <<FOO
(one)
(two
FOO
)
$

Escaping the parens seems to appease it, a little:

Example - escaping parens

$ cat <(fmt --width=10 <<FOO                 
\(one\)
\(two
FOO
)
\(one\)
\(two

But doesn't really give you what you want. Making the parens balanced also seems to appease it:

Example - balancing parens

$ cat <(fmt --width=10 <<FOO
(one)
(two)
FOO
)
(one)
(two)

Whenever I have complex strings, such as this to contend with in Bash, I almost always will construct them first, storing them in a variable, and then use them via the variable, rather than try and craft some tricky one liner that ends up being fragile.

Example - use a variable

$ var=$(fmt --width=10 <<FOO
(one)
(two
FOO
)

Then to print it:

$ echo "$var"
(one)
(two

References

Shell – How to end a here-document that starts with <<\\$fff

The line which ends the here document is

\$fff

From the man bash section on Here Documents:

The format of here-documents is:

          <<[-]word
                  here-document
          delimiter

No parameter and variable expansion, command substitution, arithmetic expansion, or pathname expansion is performed on word. If any characters in word are quoted, the delimiter is the result of quote removal on word, and the lines in the here-document are not expanded. If word is unquoted, all lines of the here-document are subjected to parameter expansion, command substitution, and arithmetic expansion, the character sequence \newline is ignored, and \ must be used to quote the characters \, $, and `.

word does undergo quote removal, so \\$fff is dequoted to \$fff. But, as the manpage says, no variable expansion is done so it stays that way.

The body of a here document might or might not undergo variable expansion and backslash interpretation. In this case, since word contains a quoted character (that is, the backslash), parameter expansion and backslash dequoting are not performed on the text of the here document.

However, the input is compared with the terminating sequence before variable expansion, so it is not necessary to backslash-escape the \ nor the $ in the terminating line.