I have a problem with my Xterm and I can't figure out what is wrong:
I need to enable the option *selectToClipboard in my Xterm to be able to copy text in the terminal.
To do so i firstly tried to "manually" start xterm with the option with the following command: xterm -xrm 'xterm*selectToClipboard: true' which work very well.
Then to enable the option each time xterm is started I put the following line xterm*selectToClipboard: true in my ~/.Xresources and I used the command xrdb -merge ~/.Xresources to update the settings but it doesn't work: Xterm starts but the option isn't enabled and I can't copy text from the terminal whereas all the other options in the Xresources are enabled and work fine.
Does anyone have an idea of what could cause this problem?
X resources are case-sensitive. The xterm manual documents this as
selectToClipboard (class SelectToClipboard)
Tells xterm whether to use the PRIMARY or CLIPBOARD for SELECT
tokens in the selection mechanism. The set-select action can
change this at runtime, allowing the user to work with programs
that handle only one of these mechanisms. The default is
"false", which tells it to use PRIMARY.
The feature was added to xterm in patch #209 (2006). It is not an optional feature. So (assuming you have typed the command-line as given), there are a few possibilities to check:
you could be running an older version of xterm. To check this, run
xterm -v
The -v version option of xterm will have it print a one-line message showing the patch-level along with the configuration for which it was compiled, e.g.,
XTerm(261)
The feature can be set/reset using an escape sequence, as noted in XTerm Control Sequences:
CSI ? Pm h
DEC Private Mode Set (DECSET).
...
Ps = 1 0 4 1 -> Use the CLIPBOARD selection. (This enables
the selectToClipboard resource).
Your shell initialization may have something which sends this sequence.
The xrdb -query is one way to check for resource-settings, but it is not infallible. A better tool would be appres, e.g.,
appres XTerm
appres UXTerm
depending on whether xterm is run with/without the UXTerm application defaults. In contrast to xrdb, appres shows resource settings after taking into account the "app-defaults" files. (It does not see resources applied only to an instance of xterm such as the -xrm option).
tmux has a feature which can interfere with selections (whether to primary or clipboard). That is called set-clipboard, and is commented upon here:
Enabling mouse in tmux conflicts with paste in X [duplicate]
Re: iTerm2 support for set-clipboard
Short answer:
just need to add the line bellow in your /etc/X11/app-defaults/XTerm file
*selectToClipboard: true
Long answer:
If you look at man pages xterm(1):
man xterm
FILES
The actual pathnames given may differ on your system.
...
/etc/X11/app-defaults/XTerm
the xterm default application resources.
/etc/X11/app-defaults/XTerm-color
the xterm color application resources. If your display supports color, use this
*customization: -color
in your .Xdefaults file to automatically use this resource file rather than /etc/X11/app-defaults/XTerm. If you do not do this, xterm uses its compiled-in default resource settings for colors.
...
I did not find any reference to a user configuration file to set XTerm application defaults, except for XTerm-color, so I don't think it exists.
Related
I'm doing some experiments and while I do it I have to turn a board off and on frequently (a program doesn't get killed properly probably with unclosed socket .. I installed signal handler and it worked and now it doesn't..) . Every time I turn on the board, I start vnc window (it starts xfce4 ) and have to open terminals in specific location. Is there any setup method through which the terminals are open automatically in specific locations? Or further with specific number of tabs? (I know how to give xwindow location and size : xwininfo -all. and use -geometry 1000x1000+300+300 for example).
From what I understand, you could add commands to the application autostart menu in Settings > Session and startup and give the command the working directory as an option as follows:
xfce4-terminal --default-working-directory="/home/$USER/Desktop"
The different options available are:
OPTIONS
Option Summary
Here is a summary of all the options, grouped by type. Explanations are in the following sections.
General Options
-h, --help; -V, --version; --disable-server; --color-table; --default-display=display;
--default-working-directory=directory
Window or Tab Separators
--tab; --window
Tab Options
-x, --execute; -e, --command=command; -T, --title=title; --dynamic-title-mode=mode;
--initial-title=title; --working-directory=directory; -H, --hold; --active-tab;
--color-text=color; --color-bg=color
Window Options
--display=display; --drop-down; --geometry=geometry; --role=role; --startup-id=string; -I,
--icon=icon; --fullscreen; --maximize; --minimize; --show-menubar, --hide-menubar;
--show-borders, --hide-borders; --show-toolbar, --hide-toolbar; --show-scrollbar,
--hide-scrollbar; --font=font; --zoom=zoom
Refer to the man page for more settings related to tabs and windows.
man xfce4-terminal
As an example, say that I type part of a name:
$ vi partn <= here I press <tab><tab>
partname partnook partnum <= these are the results
This is standard behaviour in bash and that is fine, but I've been working a lot on PowerShell lately where the default behaviour is that if you press tab, it cycles through the names, completing each name and then pressing tab again will go to the next file, so if I pressed tab one time, I see vi ./partname, then press tab again, I see vi ./partnook, then tab again I see vi ./partnum. I tend to prefer this behaviour as it's less typing (you just hit tab to cycle through until you get the filename or command that you want).
Everything is customisable in Linux of course, so can someone advise how I might change the default bash behaviour to follow the above by default?
To persistently make tab-completion not require two Tab keypresses whenever there are multiple matching completions and to instead cycle through them, in-line:
Option A: If you either already have:
an /etc/inputrc file (applies system-wide, modification requires sudo)
and/or a ~/.inputrc file (user-specific)
and/or
you're planning to customize the Readline library extensively and/or want to make customizations effective for scripts too when they call read -e:
Add line:
"\C-i": menu-complete
to either file, depending on whether you want the setting to be effective for all users or the current user (create the file, if necessary).
Note: Alternatively, you can simply turn off the need to press Tab twice and exhibit the standard behavior instantly, which means showing a multi-column list of all possible completions, and then redisplaying the input line, to allow you to type additional characters to either fully complete the argument or to type enough of it so that the next Tab keypress unambiguously completes:
set show-all-if-ambiguous on
Option B: Alternatively, you may add Readline commands to your user-specific initialization file (~/.bash_profile on macOS, ~/.bashrc on Linux and other Unix-like platforms), by passing them as a single argument to the bind builtin:
bind '"\C-i": menu-complete'
If you prefer the show-all-matches behavior:
bind 'set show-all-if-ambiguous on'
Note that bind commands in ~/.bash_profile / ~/.bashrc take precedence over equivalent commands in either /etc/inputrc or ~/.inputrc.
As implied above, configuring Readline this way will not take effect in scripts that call read -e in order to activate Readline support for reading user input.
I'm using Mac OS 10.13.4.
iTerm2 Version is Build 2.1.1
Vim Version is
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov 29 2017 18:37:46)
Included patches: 1-503, 505-680, 682-1283
Compiled by root#apple.com
And I Installed the Vundle plugin
And when I open vim in iTerm2 with oh-my-zsh, the $p appears at the first line.
It doesn't appear with Terminal.app of Apple?
How to solve this problem?
vim is assuming that iTerm2 is xterm (not a good assumption), and attempting to determine the state of the cursorBlink resource by sending an escape sequence containing $p which iTerm2 does not handle properly (see source-code for vim for the escape sequence, and also where it uses the feature). While vim starts with the TERM setting (i.e., "xterm"), it does make a few checks to exclude things like gnome-terminal as noted in the source code comment. But iTerm2 happens to fool vim in this case. So the result goes to the screen.
In XTerm Control Sequences that is documented like this:
CSI ? Ps$ p
Request DEC private mode (DECRQM). For VT300 and up, reply is
CSI ? Ps; Pm$ y
where Ps is the mode number as in DECSET/DECSET, Pm is the
mode value as in the ANSI DECRQM.
Two private modes are read-only (i.e., 1 3 and 1 4 ), pro-
vided only for reporting their values using this control
sequence. They correspond to the resources cursorBlink and
cursorBlinkXOR.
Although vim is fooled here, the problem is due to iTerm2, for which you've probably set the TERM environment variable to xterm-256color, or something like that. It doesn't match iTerm2's behavior very well (the function keys don't match up, etc). ncurses provides a better one. But out-of-the-box MacOS has a terminal database that's about ten years old, and lacks that entry. To get a good terminal database (i.e., one where you could set TERM to iterm2), you could do that with MacPorts or home-brew.
Running infocmp to get a measure of the differences between the (correct) iterm2 entry and linux, xterm-256color shows that
it's actually closer to nsterm-256color (a correct entry for Terminal.app which Apple doesn't provide) with 38 lines of difference,
next closest linux with 76 lines and
still further away from xterm-256color with 94 lines.
The feature that's missing or mis-implemented in iTerm2 isn't in the terminal description: it's a special feature that vim has to guess about.
As mentioned above, this $p is due to vim sending a control sequence for a cursor blink request. In your .vimrc, you can turn off the cursor blink request by clearing the t_RC terminal option. I wrapped this in a conditional which turns it off only for 256 color terminals.
if &term =~ '256color'
set t_RC=
endif
Setting the terminal explicitly to linux solved it for me:
export TERM=linux
The p means print, which is the command the range is being given to, and yes.. it displays to you what is in that range.
In vim you can look at :help :range and :help :print to find out more about how this works. These types of ranges are also used by sed and other editors.
They probably used the 1,$ terminology in the tutorial to be explicit, but note that you can also use % as its equivalent. Thus, %p will also print all the lines in the file.
I'm using tmux for sometime now,
I use vim for coding, and I've noticed some flaws related to the colorschemes ONLY when I'm using vim with tmux.
Both terminal support 256 colors when I run this: tput colors
When I test my terminal to see if support true colors this is the result:
curl -s https://raw.githubusercontent.com/JohnMorales/dotfiles/master/colors/24-bit-color.sh | bash
the output from the terminal is this:
but when I run this within tmux:
I've checked the result of echo $TERM but both of them return this:
xterm-256color
So I'm really confused about what might be the problem here =\
Any idea?
Thanks a lot!
Perhaps you overlooked this in setting up (one can see that you overlooked Tc):
commit 427b8204268af5548d09b830e101c59daa095df9
Author: nicm <nicm>
Date: Fri Jan 29 11:13:56 2016 +0000
Support for RGB colour, using the extended cell mechanism to avoid
wasting unnecessary space. The 'Tc' flag must be set in the external
TERM entry (using terminal-overrides or a custom terminfo entry), if not
tmux will map to the closest of the 256 or 16 colour palettes.
Mostly from Suraj N Kurapati, based on a diff originally by someone else.
in tmux.conf:
# Enable RGB colour if running in xterm(1)
set-option -sa terminal-overrides ",xterm*:Tc"
in the manpage:
TERMINFO EXTENSIONS
tmux understands some unofficial extensions to terminfo(5):
...
Tc Indicate that the terminal supports the ‘direct colour’ RGB
escape sequence (for example, \e[38;2;255;255;255m).
If supported, this is used for the OSC initialize colour escape
sequence (which may be enabled by adding the ‘initc’ and ‘ccc’
capabilities to the tmux terminfo(5) entry).
Regarding -s versus -g, the manual page says:
set-option [-agoqsuw] [-t target-session | target-window] option value
(alias: set)
Set a window option with -w (equivalent to the
set-window-option command), a server option with -s, otherwise
a session option. If -g is given, the global session or window
option is set. The -u flag unsets an option, so a session
inherits the option from the global options (or with -g,
restores a global option to the default).
The -o flag prevents setting an option that is already set and
the -q flag suppresses errors about unknown or ambiguous
options.
With -a, and if the option expects a string or a style, value
is appended to the existing setting.
As I understand it,
Using -s means that new connections (created by the server) will get this setting, which is useful in shell initialization, while -g makes its changes too late for the shell initialization.
Further reading:
Add TrueColor Support #34
Tmux true color support. #622
Why only 16 (or 256) colors? (ncurses FAQ)
A seemingly new feature in OS X El Capitan (10.11 Beta) is Bash sessions (Terminal sessions). I now have a ~/.bash_sessions directory with history files, and my HISTFILE and HISTIGNORE envars are being overridden. How can I disable all of this functionality?
If you startup a new Bash session manually (i.e. bash -xl), you can see what is run on login.
You'll see the following line in the output:
....
+++ '[' '!' -e /Users/username/.bash_sessions_disable ']'
You can create a .bash_sessions_disable file in your home directory to disable this functionality.
This behavior is defined in /etc/bashrc_Apple_Terminal. It contains documentation comments describing what it does and how to customize it.
You can disable the per-terminal-session command history feature by setting SHELL_SESSION_HISTORY=0 in your ~/.bashrc script, as described here:
You may disable this behavior and share a single history by setting
SHELL_SESSION_HISTORY to 0. There are some common user customizations
that arrange to share new commands among running shells by
manipulating the history at each prompt, and they typically include
'shopt -s histappend'; therefore, if the histappend shell option is
enabled, per-session history is disabled by default. You may
explicitly enable it by setting SHELL_SESSION_HISTORY to 1.
Note that, although you can disable the entire session-state restoration mechanism by creating ~/.bash_sessions_disable, this is unnecessary just to disable the per-session command history feature, and is not recommended.
To summarize, this has to do with Apple's Resume feature. When this feature is enabled, when you quit an app or reboot, the next time the app opens it will open the windows that were previously open.
With regard to Terminal, three things have to be in place for this to happen:
$HOME/.bash_sessions_disable must not be present
System Preferences/General/Close Windows when quitting an app must not be checked.
When rebooting, select Reopen windows.
When you reopen Terminal, it will reopen the same windows and tabs you had before in the same screen positions. Additionally, if you have checked Terminal/Preferences/your-window-type/Windows/Resume/Restore-text-when-reopening-windows, it will restore the text on each screen.
Finally, and this relates specifically to the OP's question, it will restore the history in each window/tab if the following conditions hold:
SHELL_SESSION_HISTORY is unset or set to 1
shopt histappend is not set
HISTTIMEFORMAT is not set
If SHELL_SESSION_HISTORY is explicitly set to 1 in .bashrc, the last two requirements are overridden, that is, shopt histappend or HISTTIMEFORMAT could be set.
Additionally, attention needs to be paid to the HISTSIZE and HISTFILESIZE variables. They should not be too large or too small, and some advise to leave them unset so they take Apple's default values.
Everything so far written about this subject is accurate and useful, and the techniques already mentioned should be used in lieu of this. I'm going to mention a totally nuclear approach, just for the sake of entertaining alternatives, and also to expand further understanding of this subject.
The only reason I acquired this knowledge is simply because I was looking for an alternative solution to needing to create a ~/.bash_sessions_disable file; I would have instead preferred preventing the sessions behaviour from happening by just adding some lines to my existing ~/.bash_profile. Unfortunately, that is not possible without going nuclear, so the official answer is still the best approach.
Summary
When Bash first starts up on MacOS, it will first source /etc/profile, which in turn sources /etc/bashrc. The contents of that file include this line:
[ -r "/etc/bashrc_$TERM_PROGRAM" ] && . "/etc/bashrc_$TERM_PROGRAM"
The $TERM_PROGRAM environment variable is only set by Apple's Terminal app. Printing the value of that variable returns Apple_Terminal. In other words, the /etc/bashrc file is attempting to source a /etc/bashrc_Apple_Terminal file if it both exists and is readable. It's in this file where MacOS does its special Bash session handling to tie into the Resume features of the OS.
After all that, Bash will then source any configurations a user has in their home directory (like ~/.bash_profile or ~/.bashrc). This being stated, there's no way to override all the work done in the /etc/bashrc_Apple_Terminal file on a purely configuration level (vs both configuration and creating a new file) without doing what the others have mentioned, namely, setting $SHELL_SESSION_HISTORY to 0 to eliminate session-based history, and creating a ~/.bash_sessions_disable to prevent the .bash_sessions directory from being created every time Apple's Terminal is started.
Nuclear Approach
The two possible alternatives to eliminate any of this new MacOS functionality would be to either 1) remove that last line from the /etc/bashrc file, or 2) rename or delete the /etc/bashrc_Apple_Terminal to something else.
After doing this, Apple's Terminal app will no longer behave differently than non-Apple terminal emulators.