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:


I've found that this works:

sed 's/\\t/\t/g' > /tmp/test.txt << 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
  • 1
    Which distribution, version and bash version do you use?
    – Cyrus
    Jun 9, 2015 at 5:40
  • 1
    I've try cat > file.txt with CTRL-D in the last line in the FreeBSD's csh and everything goes perfectly.
    – Kondybas
    Jun 9, 2015 at 7:15
  • 1
    cat just passes tabs through, like any other character. Here documents also pass tabs through. The problem is either that your script doesn't contain what you think it does or that what you're using to look at the output mangles it. If you need help figuring it out, you need to give us your exact script, not a script with potentially different whitespace. Post the output of base64 <yourscript.sh and of base64 /tmp/test.txt. Jun 11, 2015 at 0:12
  • 1
    Apparently, that's how heredocs work. I haven't found it documented explicitly but heredocs are just a needlessly complex way to do what you're attempting. It had never occurred to me to use them before since cat > file and pasting is so much simpler. That's the standard way it would be done.
    – terdon
    Jun 11, 2015 at 15:58
  • 1
    @Kondybas it's probably worth adding that as an answer since the OP was unaware of it.
    – terdon
    Jun 11, 2015 at 15:59

4 Answers 4


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
[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.
  • Note pscp or psftp (or in Windows 10 up the 'native' scp and sftp ported from OpenSSH) copy the file byte-for-byte -- and a file created with notepad will almost always have CRLF line endings, which when copied to any Unix system frequently cause trouble unless you remember to remove them (for which there are numerous options such as tr -d '\r', sed 's/.$//', dos2unix) Aug 19, 2022 at 1:40
  • (After testing) it's also possible to run bash with --noediting; then tab is not handled specially, and can be used as data in a heredoc. But this takes the entire UI back to the 1980s and makes it barely usable; I don't recommend it. Aug 19, 2022 at 1:52

I'm not entirely sure what problem you're having - on my RHEL install, cat works if I give it tab stops. However as a more general solution perhaps:


 use strict;
 use warnings; 

 while ( <> ) { 

Will take 'input' on either STDIN (catted into) or as filenames (e.g. myscript.pl <filename>) and convert all whitespace to tab stops.

  • 1
    I definitely appreciate this answer, but I'm hopeful there is a simpler solution. Jun 9, 2015 at 12:19

If you would like a more simple solution than perl script, you can use sed, anyway that perl script is simple too.

echo "hello    world" | sed 's/\(\t\+\)/\t/g'

Anyway, using redhat 5 I don't see any problem using cat command

rpm -qf $(which cat)
  • 1
    Thank you so much. Even using echo I am seeing the tabs removed. I am pasting from Windows into Linux via SSH using putty. I am now highly suspicious that that's the issue. However, when I edit the file with vi and paste, the tabs are preserved. Jun 9, 2015 at 12:56

The bash manual explains (on [n]<<[-]word):

If any part of word is 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, ...

while cat >/tmp/test.txt <<'EOF' might do, it does not: TABs are still expanded. As it seems to be the readline library, there is a somewhat easy solution:

user@host:~> bash --noediting
user@host:~> cat >/tmp/test.txt <<EOF

(paste your data now)

user@jhost:~> exit

(leave the extra shell)

Another tool to exchange files between Windows and SSH-enabled UNIX is WinSCP.

  • <<quoted might help, but in fact it doesn't, as can be determined in about 3 seconds Aug 19, 2022 at 1:54
  • I've completed the answer to reflect that. Sorry for not having checked.
    – U. Windl
    Aug 22, 2022 at 9:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .