we want to switch to Putty at work, but we have one big problem: in error situations we have to copy some lines from our logfile (using less/vi and mouse copy & paste). These lines can be 32 KB long and contain several blanks, the blanks need to be preserved. Unfortunately, if the copied content is wrapped because it doesn't fit in one line in the window, Putty seems to replace the trailing blanks with a newline character.
e.g. if we have the line (with trailing spaces that need to be preserved -> you see the trailing spaces if you select the example):
LINE START, WINDOW IS 80 CHARACTERS WIDTH, BUT LINE IS 32KB
SO LINE IS WRAPPED IN THE PUTTY WINDOW
THE TRAILING SPACES NEED TO BE PRESERVED....
BUT USING PUTTYS COPY & PASTE, PUTTY REPLACES SPACE CHARACTERS BY NEWLINE
...LINE END
and we copy & paste, we get (select second example):
LINE START, WINDOW IS 80 CHARACTERS WIDTH, BUT LINE IS 32KB
SO LINE IS WRAPPED IN THE PUTTY WINDOW
THE TRAILING SPACES NEED TO BE PRESERVED....
BUT USING PUTTYS COPY & PASTE, PUTTY REPLACES SPACE CHARACTERS BY NEWLINE
...LINE END
Putty cuts the trailing spaces and inserts a newline character. Can this behaviour be configured/changed in Putty?
Thank you,
Christian
I have used non-breaking spaces to retain trailing whitespace when copying/pasting from PuTTY. My application was ssh-ing into a linux box and copying/pasting some code using the Bourne shell, so I don't know how widely this will work in other environments.
To insert a non-breaking space, hold the Alt key and type 255, then release the Alt key. The following example can be used for testing. For some reason, the code doesn't retain the non-breaking space when I copy/paste directly from this webpage, so you will need to test it this way:
a. Copy/paste the code below into notepad
b. Delete the space in blank=" "
c. Insert a non-breaking space with Alt+255
d. Copy/paste the code into PuTTY
e. Copy/paste the output back into notepad to view results
CODE
# non-breaking space, Alt+255
blank=" "
# regular space
space=" "
echo "
blank:$blank
space:$space
"
Which outputs a trailing space for the $blank var, but not for the $space var.
OUTPUT
blank:
space:
I'm not sure that Putty can do it but in my case (putty working on redhat open client) I converted source files to unix format (dos2unix command).
Now pasting works fine.
Related
I'm just wondering. When I type ; in cmd, it will just ignore it.
I can type ;;;;;;;;;;;;;;; and it will do the same thing but, if I do ;a it will say error.
Why is that?
; is a delimiter.
Delimiters separate one parameter from the next - they split the command line up into words.
More info on https://ss64.com/nt/syntax-esc.html
The semicolon is not ignored by cmd.exe; rather is it even particularly recognised, namely as a token separator, which are used to separate commands from its arguments and arguments from each other. Here are all such characters:
SPACE (code 0x20)
TAB (horizontal tabulator, code 0x09)
, (comma, code 0x2C)
; (semicolon, code 0x3B)
= (equal-to sign, code 0x3D)
VTAB (vertical tabulator, code 0x0B)
FF (form-feed or page-break, code 0x0C)
NBSP (non-breaking space, code 0xFF)
Note that multiple consecutive token separators are collapsed to a single one.
Command prompt does not ignore the character ";", ";" is a delimeter and cmd recognizes it as so so it doesn't "ignore" the character, but reads it similar to a space so nothing appears when you write it alone.
In bash sometimes I have very long commands where I need to edit some words. Right now I use End/Home to move end/start of the command, but what if I have to move say x characters in a line?
I need something like xb/xw of VI, but instead of words I need to move characters.
What about ditching emacs mode and switching to vi mode editing?
set -o vi
and you have all the power of vi-like command line editing, like 3l to go left three characters and 5B to go back 5 words. The Pos 1 key then becomes 0 and End becomes $.
In emacs mode, you can use Meta3Controlb to move back 3 characters, and Meta3Controlf to move forward 3 characters. For multi digit counts, you need to precede each digit with the Meta key (e.g., to move 10 characters back, Meta1Meta0Controlb).
Meta is usually the Alt key, but may be the Esc key instead (on Mac OS X, for instance).
(Yes, vi-command mode makes it easier.)
There is a command, universal-argument, that allows you to type all the digits at once, but it is unbound by default. Bind it with, say,
bind "\C-a":universal-argument
then typing Control-a will enter you into an "argument" mode, prefixing the current line (arg: 4), and allowing you to type digits to change the argument used by the next non-digit character you type. (See universal-argument in the bash man page for the full details.)
You could use the command as below
Command:
cp some_file1 some_file2 some_file3 /root/Desktop
After executing the command do the following
^some_file2^some_file4
and it will execute the command
cp some_file1 some_file4 some_file3 /root/Desktop ;
What happened is the some_file2 is replaced by some_file4 and the command is executed
This is my very simple code, which isn't working, for some reason I can't figure out.
#!/usr/bin/perl
use File::Copy;
$old = "car_lexusisf_gray_30inclination_000azimuth.png";
$new = "C:\Users\Lenovo\Documents\mycomp\simulation\cars\zzzorganizedbyviews\00inclination_000azimuth\lexuscopy.png";
copy ($old, $new) or die "File cannot be copied.";
I get the error that the file can't be copied.
I know there's nothing wrong with the copy command because if I set the value of $new to something simple without a path, it works. But what is wrong in the representation of the path as I've written it above? If I copy and past it into the address bar of windows explorer, it reaches that folder fine.
Tip: print out the paths before you perform the copy. You'll see this:
C:SERSenovodocumentsmycompsimulationrszzzorganizedbyviewsinclination_000azimuthexuscopy.png
Not what we wanted. The backslash is an escape character in Perl, which needs to be escaped itself. If the backslash sequence does not form a valid escape, then it's silently ignored. With escaped backslashes, your string would look like:
"C:\\Users\\Lenovo\\Documents\\mycomp\\simulation\\cars\\zzzorganizedbyviews\\00inclination_000azimuth\\lexuscopy.png";
or just use forward slashes instead – in most cases, Unix-style paths work fine on Windows too.
Here is a list of escapes you accidentally used:
\U uppercases the rest
\L lowercases the rest
\ca is a control character (ASCII 1, the start of heading)
\00 is an octal character, here the NUL byte
\l lowercases the next character.
If no interpolation is intended, use single quotes instead of double quotes.
When I paste a long string (ie, more characters than the width of the terminal window), the terminal doesn't autoscroll and put them in multiple lines.
Instead, it basically wraps onto the same line. In other words, it prints until the end of the current line and then starts printing over the existing characters from the beginning of the same line...
Here's a screenshot. Notice the characters "789abc..." at the beginning of the line.
I'm on 10.8.3 with Terminal 2.3. $TERM is xterm-256color.
A colleague has the exact same machine setup (though different Terminal colors and probably other configs) and he can get it to scroll.
Any ideas?
Thanks!
It sounds like you don't have the nonprinting parts of your PS1 prompt string properly marked. The nonprinting parts (e.g. color change escape sequences) -- and only the nonprinting parts -- need to be marked with \[ ... \] so that the shell can tell they don't take up space on screen (and hence can tell where to wrap). For example, my prompt string is \[\e[0;32m\]\h\[\e[m\]:\W \[\e[0;34m\]\u\[\e[m\]$, which parses out as:
\[\e[0;32m\] - change color to green type (nonprinting, so it's wrapped in \[ ... \])
\h - the hostname (printing)
\[\e[m\] - normal print (no color) (nonprinting, hence wrapped)
:\W - the current directory (and delimiters) (printing)
\[\e[0;34m\] - change to blue type (nonprinting)
\u - the hostname (printing)
\[\e[m\] - normal type (nonprinting)
$ - final delimiter before the actual command
So I have a strange question. I have written a script that re-formats data files. I basically create new files with the right column order, spacing, and such. I then unix2dos these files (the program I am formatting these files for is DIPS for windows, and I assume that the files should be ansi). When I go to open the files in the DIPS Program however an error occurs and the file won't open.
When I create the same kind of data file through the DIPS program and open it in note pad, it matches exactly with the data files I have created with my script.
On the other hand if I open the data files that I have created with my script in Kedit first, save them, and then open them in the DIPS program everything works.
My question is what could saving in Kedit possibly do that unix2dos does not?
(Also if I try using note pad or word pad to save instead of Kedit the file doesn't open in DIPS)
Here is what was created using the diff command in unix
"
1,16c1,16
* This file is generated by Dips for Windows.
* The following 2 lines are the Title of this file.
Cobre Panama
Drill Hole B11106-GT
Number of Traverses: 0
Global Orientation is:
DIP/DIPDIRECTION
0.000000 (Declination)
NO QUANTITY
Number of extra columns are: 0
--
* This file is generated by Dips for Windows.
* The following 2 lines are the Title of this file.
Cobre Panama
Drill Hole B11106-GT
Number of Traverses: 0
Global Orientation is:
DIP/DIPDIRECTION
0.000000 (Declination)
NO QUANTITY
Number of extra columns are: 0
18c18
--
440c440
--
442c442
-1
-1
"
Any help would be appreciated! Thanks!
Okay! Figured it out.
Simply when you unix2dos your file you do not strip any space characters in between the last letter in a line and the line break character. When saving in Kedit you do strip the spaces between the last letter in a line and the line break character.
In my script I had a poor programing practice in which I was writing a string like this;
echo "This is an example string " >> outfile.txt
The character count is 32, and if you could see the break line character (chr(10)) the line would read;
This is an example string
If you unix2dos outfile.txt the line looks the same as above but with a different break line character. However when you place the file into Kedit and save it, now the character count is 25 and the line looks like this;
This is an example string
This occurs because Kedit does not preserve spaces at the end of a line. It places the return or line break character at the last letter or "non space" character in a line.
So programs that read literal input like DIPS (i'm guessing) or more widely used AutoCAD scripting will have a real problem with extra spaces before the return character. Basically in AutoCAD scripting a space in a line is treated as a return character. So if you have ten extra spaces at the end of a line it's treated the same as ten returns instead of the one you probably intended.
OH and if this helped you out or though it was good please give me a vote up!
unix2dos converts the line-break characters at the end of each line, from unix line breaks (10) to dos line breaks (13, 10)
Kedit could possible change the encoding of the file (like from ansi to UTF-8)
You can change the encoding of a file with the iconv utility (on a linux box)