When I try to print some function name in minicom for linux-3.10 kernel and x86 board, I get extra spaces in each lineof minicom. I have switched on the Line Wrap in minicom but same problem exists. This does not happen with ARM board. It gets printed correctly in ARM board.
x86_64_start_kernel()
reset_early_page_tables()
The code is for printing each name on the border. Is there any setting to be done in minicom?
In minicom press Ctrl+A Z. This will show the menu. Then press U ("Add Carriage Ret"), and minicom will add the CR symbol to each LF symbol automatically.
PERMANENT SOLUTION
You can execute minicom -s as root, choose Screen and keyboard, then press T - Add carriage return, and Save setup as dfl to turn this option ON systemwide. Or you can save this configuration in a separate Config-file, and then use as minicom -D /dev/ttyUSB0 /etc/minicom/minirc.myconfig.
Related
I have an application that communicates via USB over COM and I usually use Putty to develop. Some of the users will use Teraterm instead and want the user experience to be as similar as possible.
In Putty, I can send a 0x7F which is ASCII "DEL" and when that value is echo'd back from my application, Putty does a backspace+delete (destructive backspace). With Teraterm, Backspace sends 0x08 which is ASCII "BS" (backspace) and, as long as the "Transmit DEL by:" box for Backspace Key is not checked, the key is returned as 0x08 without any delete (non-destructive backspace).
Is there any way to enable configuration of Teraterm to move cursor position back one character and delete that character when it receives the 0x08 command?
This has been a long time with no answer, so hopefully you worked through it. I don't understand if this scripted through the teraterm macro or if you are just manually navigating through teraterm.
But if this is for a script (.ttl) file or just a command within teraterm, and you know what string is being sent that needs this, you can do the following:
wait "[insert string you are looking for here]"
send 8 127
Where 8 means backspace and 127 means delete. Hope that helps. But teraterm will accept multiple ascii codes in one send command. The wait command could also be further rounded out to accept a timer for the wait action before it performs anything. The wait command can also accept up to 10 strings to wait for: https://ttssh2.osdn.jp/manual/en/macro/command/wait.html
You can also find the ASCII code table for teraterm here: https://ttssh2.osdn.jp/manual/en/macro/appendixes/ascii.html
I encountered a problem with my terminal where when I paste text, it is prefixed by 00~ and suffixed with 01~.
For example, I will highlight text and push Command-C. I then push Command-V into the terminal and I see those weird characters pop up at the beginning and end of the text.
For example, I can highlight text and paste it into the terminal. I then see 00~text01~.
The text can be from anywhere, even from the Terminal itself. I do not have any copy/paste plugins installed, this is just the normal Copy/Paste. I am using the default Mac Terminal without any modifications.
I did some searching online, apparently the Paste wraps the text in special characters so that certain applications will see that this is pasted text and will handle it properly. However, the terminal is not handling this correctly, and is therefore not removing the weird characters. Apparently this paste mode is called the "Bracketed Paste Mode" http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Bracketed-Paste-Mode
I found another question that gave a solution on how to solve this issue on a linux machine, but after trying that solution I still have that same problem.
Can someone tell me how I can disable bracketed paste mode for the terminal? Or tell me the right way to get rid of these annoying characters?
What happens when text is pasted
Text has made it into the "system" (e.g. X, MacOS/Aqua) copy buffer from somewhere, maybe from the same terminal. The text is not altered here.
The text is pasted into the terminal; that is, "system" sees to that the terminal (e.g. xterm) receives the unaltered character sequence from the copy buffer. The terminal is aware that this is a paste, not keyboard input.
The terminal sends the char sequence in the buffer to the program running in the foreground (a shell, an editor, whatever). To the program the received data is indistinguishable from user input through the keyboard.
Discussion
This transparency (or opaqueness? whatever) is often a good thing much like the Unix paradigm of transparent pipe plumbing in general. But sometimes programs could deal with the data better if they knew it is pasted. For example an editor like vim could switch off auto indent — after all, the code is likely indented already!
Bracketed paste
Enter bracketed paste. For principal reasons the paradigm of transparent data piping cannot be altered; but the data can be decorated with sequences which would ordinarily not appear in terminal input to mark its start and end. If the terminal is so configured — for the xterm the configuration would be to send ESC [ ? 2 0 0 4 h — the pasted data is bracketed with escape sequences: ESC [ 2 0 0 ~ <buffer contents> ESC [ 2 0 1 ~.
The foreground program receives this "decorated" data, and it's up to to the program to handle it. A naive program treats all of it as user input, which is what you see.
A good discussion of bracketed paste can be found in this article.
Remedies
There are two issues in your case: The terminal ends up unexpectedly in bracketed paste mode; and the receiving program — presumably the shell — does not handle it.
One solution is user83536's: Identify the program which leaves the terminal in that state and call it through a wrapper which simply switches bracketed paste mode off again after the program has ended.
The program probably tried to switch bracketed paste mode off but failed. One reason can be that it sends the wrong escape sequence. Try setting the TERMINAL environment variable to the value best describing your terminal.
Try to switch off bracketed paste in the offending application. In vim one would say set t_BE=. That prevents vim from putting the terminal in bracketed paste mode and when it is set in a session, sends the "end bracketed paste mode" to the terminal.
Embrace bracketed paste. It seems to be a good idea. For the bash and other programs using readline one would put set enable-bracketed-paste on. For vim one could follow the suggestions here.
This may not apply directly to your problem, but I found this symptom to probably, in my case, be caused by my editor-of-choice 'mcedit' (Midnight Commander)
To alleviate the bug problem, I added the following function to my .bashrc file:
### vvv 'function mcedit' is a fix-up for the ~0/~1 paste problem
function mcedit() { command mcedit $# ; printf '\e[?2004l' ; }
Then 'source .bashrc'
Now every time I execute 'mcedit', it automatically adds the 'printf "\e[?2004l"' when I close out to reset the "Bracketed Paste Mode"
Works for me, YMMV.
To disable bracketed paste mode in your terminal, run the following command:
printf '\e[?2004l'
To disable bracketed paste globally, on Linux, add this line to ~/.inputrc :
set enable-bracketed-paste 0
To disable only in the current running Xterm (v 372) (running bash shell version 5.1.16 (probably earlier too, but I don't know)):
% bind 'set enable-bracketed-paste 0'
With either of the above two methods, you can re-enable bracketed paste (in the current Xterm) in the obvious way, namely:
% bind 'set enable-bracketed-paste 1'
I am writing a *nix shell, I want support the key-combination of Ctrl-Enter. And the library I use is GNU readline.
I have spent several hours on it, but can't find the way.
I can bind Enter successfully, like:
========= ~/.inputrc ===============
"\C-M": "sdf"
====================================
When I press Enter, I got "sdf" echoed, just as expected.
I can also bind Esc,Enter successfully(note, here is key serial, not combination), like:
========= ~/.inputrc ===============
"\e\C-M": "sdf"
====================================
When I pressed Esc and then pressed Enter, "sdf" was echoed as expected.
However, the following line can not produce a valid Ctrl-Enter combination:
========= ~/.inputrc ===============
"\C\C-M": "sdf"
====================================
And, "\C-\C-M" doesn't work too.
Here are two related questions:
how to bind the 'Enter key'
How to bind Ctrl-Enter in fish?
Can any one help me ?
You don't mention which terminal emulator you use - which matters, because in the end, it is the terminal that decides what your program reads from it when you press CTRL+ENTER
A way to make this work is (assuming you use xterm):
Make xterm send e.g. CTRL+k when you press CTRL+ENTER, by adding a line in your .Xdefaults:
XTerm.vt100.translations: #override Ctrl<Key>Return: string("\013")
Bind this to whatever you want in .inputrc:
"\C-k": "sdf"
Not very elegant, as this will only work in xterm. But, as far as i can see, the only way to get what you want.
I want to bind C-? to history-search-backward in bash and/or zsh. I tried the following way
bind '"^?": history-search-backward' # bash
bindkey '^?' history-search-backward # zsh
The binding works fine, but at the same time BS (backspace) stops working correctly. The reason is that BS generates the same code as C-? what one can check with C-v BS and C-v C-?. Thus the final result is that both C-? and BS are bound to history-search-backward what is obviously not what I wanted.
So the question is how can I properly bind C-? without affecting BS?
Which string is sent to the shell when pressing a key or key combination is determined by the terminal.
It seems that a lot (most?) terminal emulators by default send ^? (ASCII 0x7f, Delete) when pressing the backspace key. While the actual backspace character would be ^H (ASCII 0x08, Backspace).
If you can change the behaviour of your terminal emulator to send ^H you should be able to maintain the function of the backspace key while still being able to bind ^? to something else.
Terminal emulators the provide a GUI for configuration (gnome-terminal, roxterm, konsole, ...) should have an option for that.
Others (xterm, urxvt, ...) may have appropriate X resources that may be set in ~/.Xdefaults (or - depending on your distribution - ~/.Xresources).
For xterm you need to set:
XTerm.backarrowKeyIsErase: False
For urxvt set
URxvt.backspacekey: ^H
please note that this is the actual ^H (ASCII 0x08) character and not a two character string consisting of ^ and H.
To load these settings either call xrdb -merge ~/.Xdefaults or close and restart your X session. (The settings will only be enabled for new terminals)
I'm using screen to read the text from a serial console. The problem is the output seems to only have newline \n but not carriage return \r, so the display looks like this...
Line1
Line2
Line3
I wonder if there is any patch to fix this issue?
onlcr is for translating outgoing newlines to carriage returns.
stty -F /dev/ttyS0 inlcr will translate incoming newlines to carriage returns. You can run that from another terminal after starting screen to avoid any resetting that screen may do on startup. Unfortunately however, this will only change the problem. You'll then get only returns and no newlines.
What is needed is an option to append a return to an incoming newline so that the terminal receives \n\r, which is what the serial device should have output in the first place. There seems to be an onlret option to do this for outgoing data, but no inlret option as we would seem to need in this case.
I have the exact same problem (using picocom though) and I've been googling off and on for days trying to find the standard fix, but no one seems to have one. There are a number of serial devices out there which only output \n and simply can't be made to output \r\n and I refuse to believe that all of them belong to only two linux users. What gives!?
If you use the miniterm.py program that comes with pyserial it will interpret newlines as crlf. It is not the most fully-featured terminal emulator but for interacting with simple serial devices it gets the job done.
Usage syntax (on OSX):
miniterm.py /dev/tty.usbserial-XXXXXX 115200
Replace XXXXXX with whatever the device comes up on your system as.
Try stty onlcr.
The man page says it will translate newlines to carriage return / newline pairs on output, which seems to be what you need.
In my case worked: stty -F /dev/ttyACM0 -icrnl
Because the serial was implicitly set to translate CR to NL. This command set it back. Notice the minus character preceding icrnl.