-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.FAQ
683 lines (550 loc) · 32.4 KB
/
README.FAQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
FREQUENTLY ASKED QUESTIONS
How do I know which rxvt-unicode version I'm using?
The version number is displayed with the usage (-h). Also the escape
sequence "ESC [ 8 n" sets the window title to the version number.
I am using Debian GNU/Linux and have a problem...
The Debian GNU/Linux package of rxvt-unicode in sarge contains large
patches that considerably change the behaviour of rxvt-unicode.
Before reporting a bug to the original rxvt-unicode author please
download and install the genuine version
(<http://software.schmorp.de#rxvt-unicode>) and try to reproduce the
problem. If you cannot, chances are that the problems are specific
to Debian GNU/Linux, in which case it should be reported via the
Debian Bug Tracking System (use "reportbug" to report the bug).
For other problems that also affect the Debian package, you can and
probably should use the Debian BTS, too, because, after all, it's
also a bug in the Debian version and it serves as a reminder for
other users that might encounter the same issue.
When I log-in to another system it tells me about missing terminfo data?
The terminal description used by rxvt-unicode is not as widely
available as that for xterm, or even rxvt (for which the same
problem often arises).
The correct solution for this problem is to install the terminfo,
this can be done like this (with ncurses' infocmp):
REMOTE=remotesystem.domain
infocmp rxvt-unicode | ssh $REMOTE "cat >/tmp/ti && tic /tmp/ti"
... or by installing rxvt-unicode normally on the remote system,
If you cannot or do not want to do this, then you can simply set
"TERM=rxvt" or even "TERM=xterm", and live with the small number of
problems arising, which includes wrong keymapping, less and
different colours and some refresh errors in fullscreen
applications. It's a nice quick-and-dirty workaround for rare cases,
though.
If you always want to do this (and are fine with the consequences)
you can either recompile rxvt-unicode with the desired TERM value or
use a resource to set it:
URxvt.termName: rxvt
If you don't plan to use rxvt (quite common...) you could also
replace the rxvt terminfo file with the rxvt-unicode one.
"tic" outputs some error when compiling the terminfo entry.
Most likely it's the empty definition for "enacs=". Just replace it
by "enacs=\E[0@" and try again.
"bash"'s readline does not work correctly under rxvt.
I need a termcap file entry.
One reason you might want this is that some distributions or
operating systems still compile some programs using the
long-obsoleted termcap library (Fedora Core's bash is one example)
and rely on a termcap entry for "rxvt-unicode".
You could use rxvt's termcap entry with resonable results in many
cases. You can also create a termcap entry by using terminfo's
infocmp program like this:
infocmp -C rxvt-unicode
Or you could use this termcap entry, generated by the command above:
rxvt-unicode|rxvt-unicode terminal (X Window System):\
:am:bw:eo:km:mi:ms:xn:xo:\
:co#80:it#8:li#24:lm#0:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\
:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=\E(B:al=\E[L:\
:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\
:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\
:dl=\E[M:do=^J:ec=\E[%dX:ei=\E[4l:ho=\E[H:\
:i1=\E[?47l\E=\E[?1l:ic=\E[@:im=\E[4h:\
:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l:\
:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\
:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\
:kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\EOB:ke=\E[?1l\E>:\
:kh=\E[7~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:\
:mb=\E[5m:md=\E[1m:me=\E[m\017:mr=\E[7m:nd=\E[C:rc=\E8:\
:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
:te=\E[r\E[?1049l:ti=\E[?1049h:ue=\E[24m:up=\E[A:\
:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:\
:vs=\E[?25h:
Why does "ls" no longer have coloured output?
The "ls" in the GNU coreutils unfortunately doesn't use terminfo to
decide wether a terminal has colour, but uses it's own configuration
file. Needless to say, "rxvt-unicode" is not in it's default file
(among with most other terminals supporting colour). Either add:
TERM rxvt-unicode
to "/etc/DIR_COLORS" or simply add:
alias ls='ls --color=auto'
to your ".profile" or ".bashrc".
Why doesn't vim/emacs etc. use the 88 colour mode?
Why doesn't vim/emacs etc. make use of italic?
Why are the secondary screen-related options not working properly?
Make sure you are using "TERM=rxvt-unicode". Some pre-packaged
distributions (most notably Debian GNU/Linux) break rxvt-unicode by
setting "TERM" to "rxvt", which doesn't have these extra features.
Unfortunately, some of these (most notably, again, Debian GNU/Linux)
furthermore fail to even install the "rxvt-unicode" terminfo file,
so you will need to install it on your own (See the question When I
log-in to another system it tells me about missing terminfo data? on
how to do this).
My numerical keypad acts weird and generates differing output?
Some Debian GNUL/Linux users seem to have this problem, although no
specific details were reported so far. It is possible that this is
caused by the wrong "TERM" setting, although the details of wether
and how this can happen are unknown, as "TERM=rxvt" should offer a
compatible keymap. See the answer to the previous question, and
please report if that helped.
Rxvt-unicode does not seem to understand the selected encoding?
Unicode does not seem to work?
If you encounter strange problems like typing an accented character
but getting two unrelated other characters or similar, or if program
output is subtly garbled, then you should check your locale
settings.
Rxvt-unicode must be started with the same "LC_CTYPE" setting as the
programs. Often rxvt-unicode is started in the "C" locale, while the
login script running within the rxvt-unicode window changes the
locale to something else, e.g. "en_GB.UTF-8". Needless to say, this
is not going to work.
The best thing is to fix your startup environment, as you will
likely run into other problems. If nothing works you can try this in
your .profile.
printf '\e]701;%s\007' "$LC_CTYPE"
If this doesn't work, then maybe you use a "LC_CTYPE" specification
not supported on your systems. Some systems have a "locale" command
which displays this (also, "perl -e0" can be used to check locale
settings, as it will complain loudly if it cannot set the locale).
If it displays something like:
locale: Cannot set LC_CTYPE to default locale: ...
Then the locale you specified is not supported on your system.
If nothing works and you are sure that everything is set correctly
then you will need to remember a little known fact: Some programs
just don't support locales :(
Why do some characters look so much different than others?
How does rxvt-unicode choose fonts?
Most fonts do not contain the full range of Unicode, which is fine.
Chances are that the font you (or the admin/package maintainer of
your system/os) have specified does not cover all the characters you
want to display.
rxvt-unicode makes a best-effort try at finding a replacement font.
Often the result is fine, but sometimes the chosen font looks
bad/ugly/wrong. Some fonts have totally strange characters that
don't resemble the correct glyph at all, and rxvt-unicode lacks the
artificial intelligence to detect that a specific glyph is wrong: it
has to believe the font that the characters it claims to contain
indeed look correct.
In that case, select a font of your taste and add it to the font
list, e.g.:
rxvt -fn basefont,font2,font3...
When rxvt-unicode sees a character, it will first look at the base
font. If the base font does not contain the character, it will go to
the next font, and so on. Specifying your own fonts will also speed
up this search and use less resources within rxvt-unicode and the
X-server.
The only limitation is that none of the fonts may be larger than the
base font, as the base font defines the terminal character cell
size, which must be the same due to the way terminals work.
Why do some chinese characters look so different than others?
This is because there is a difference between script and language --
rxvt-unicode does not know which language the text that is output
is, as it only knows the unicode character codes. If rxvt-unicode
first sees a japanese/chinese character, it might choose a japanese
font for display. Subsequent japanese characters will use that font.
Now, many chinese characters aren't represented in japanese fonts,
so when the first non-japanese character comes up, rxvt-unicode will
look for a chinese font -- unfortunately at this point, it will
still use the japanese font for chinese characters that are also in
the japanese font.
The workaround is easy: just tag a chinese font at the end of your
font list (see the previous question). The key is to view the font
list as a preference list: If you expect more japanese, list a
japanese font first. If you expect more chinese, put a chinese font
first.
In the future it might be possible to switch language preferences at
runtime (the internal data structure has no problem with using
different fonts for the same character at the same time, but no
interface for this has been designed yet).
Until then, you might get away with switching fonts at runtime (see
"Can I switch the fonts at runtime?" later in this document).
Why does rxvt-unicode sometimes leave pixel droppings?
Most fonts were not designed for terminal use, which means that
character size varies a lot. A font that is otherwise fine for
terminal use might contain some characters that are simply too wide.
Rxvt-unicode will avoid these characters. For characters that are
just "a bit" too wide a special "careful" rendering mode is used
that redraws adjacent characters.
All of this requires that fonts do not lie about character sizes,
however: Xft fonts often draw glyphs larger than their acclaimed
bounding box, and rxvt-unicode has no way of detecting this (the
correct way is to ask for the character bounding box, which
unfortunately is wrong in these cases).
It's not clear (to me at least), wether this is a bug in Xft,
freetype, or the respective font. If you encounter this problem you
might try using the "-lsp" option to give the font more height. If
that doesn't work, you might be forced to use a different font.
All of this is not a problem when using X11 core fonts, as their
bounding box data is correct.
On Solaris 9, many line-drawing characters are too wide.
Seems to be a known bug, read
<http://nixdoc.net/files/forum/about34198.html>. Some people use the
following ugly workaround to get non-double-wide-characters working:
#define wcwidth(x) wcwidth(x) > 1 ? 1 : wcwidth(x)
My Compose (Multi_key) key is no longer working.
The most common causes for this are that either your locale is not
set correctly, or you specified a preeditStyle that is not supported
by your input method. For example, if you specified OverTheSpot and
your input method (e.g. the default input method handling Compose
keys) does not support this (for instance because it is not visual),
then rxvt-unicode will continue without an input method.
In this case either do not specify a preeditStyle or specify more
than one pre-edit style, such as OverTheSpot,Root,None.
I cannot type "Ctrl-Shift-2" to get an ASCII NUL character due to ISO
14755
Either try "Ctrl-2" alone (it often is mapped to ASCII NUL even on
international keyboards) or simply use ISO 14755 support to your
advantage, typing <Ctrl-Shift-0> to get a ASCII NUL. This works for
other codes, too, such as "Ctrl-Shift-1-d" to type the default
telnet escape character and so on.
How can I keep rxvt-unicode from using reverse video so much?
First of all, make sure you are running with the right terminal
settings ("TERM=rxvt-unicode"), which will get rid of most of these
effects. Then make sure you have specified colours for italic and
bold, as otherwise rxvt-unicode might use reverse video to simulate
the effect:
URxvt.colorBD: white
URxvt.colorIT: green
Some programs assume totally weird colours (red instead of blue), how
can I fix that?
For some unexplainable reason, some rare programs assume a very
weird colour palette when confronted with a terminal with more than
the standard 8 colours (rxvt-unicode supports 88). The right fix is,
of course, to fix these programs not to assume non-ISO colours
without very good reasons.
In the meantime, you can either edit your "rxvt-unicode" terminfo
definition to only claim 8 colour support or use "TERM=rxvt", which
will fix colours but keep you from using other rxvt-unicode
features.
I am on FreeBSD and rxvt-unicode does not seem to work at all.
Rxvt-unicode requires the symbol "__STDC_ISO_10646__" to be defined
in your compile environment, or an implementation that implements
it, wether it defines the symbol or not. "__STDC_ISO_10646__"
requires that wchar_t is represented as unicode.
As you might have guessed, FreeBSD does neither define this symobl
nor does it support it. Instead, it uses it's own internal
representation of wchar_t. This is, of course, completely fine with
respect to standards.
However, that means rxvt-unicode only works in "POSIX", "ISO-8859-1"
and "UTF-8" locales under FreeBSD (which all use Unicode as wchar_t.
"__STDC_ISO_10646__" is the only sane way to support multi-language
apps in an OS, as using a locale-dependent (and non-standardized)
representation of wchar_t makes it impossible to convert between
wchar_t (as used by X11 and your applications) and any other
encoding without implementing OS-specific-wrappers for each and
every locale. There simply are no APIs to convert wchar_t into
anything except the current locale encoding.
Some applications (such as the formidable mlterm) work around this
by carrying their own replacement functions for character set
handling with them, and either implementing OS-dependent hacks or
doing multiple conversions (which is slow and unreliable in case the
OS implements encodings slightly different than the terminal
emulator).
The rxvt-unicode author insists that the right way to fix this is in
the system libraries once and for all, instead of forcing every app
to carry complete replacements for them :)
I use Solaris 9 and it doesn't compile/work/etc.
Try the diff in doc/solaris9.patch as a base. It fixes the worst
problems with "wcwidth" and a compile problem.
How can I use rxvt-unicode under cygwin?
rxvt-unicode should compile and run out of the box on cygwin, using
the X11 libraries that come with cygwin. libW11 emulation is no
longer supported (and makes no sense, either, as it only supported a
single font). I recommend starting the X-server in "-multiwindow" or
"-rootless" mode instead, which will result in similar look&feel as
the old libW11 emulation.
At the time of this writing, cygwin didn't seem to support any
multi-byte encodings (you might try "LC_CTYPE=C-UTF-8"), so you are
likely limited to 8-bit encodings.
How does rxvt-unicode determine the encoding to use?
Is there an option to switch encodings?
Unlike some other terminals, rxvt-unicode has no encoding switch,
and no specific "utf-8" mode, such as xterm. In fact, it doesn't
even know about UTF-8 or any other encodings with respect to
terminal I/O.
The reasons is that there exists a perfectly fine mechanism for
selecting the encoding, doing I/O and (most important) communicating
this to all applications so everybody agrees on character properties
such as width and code number. This mechanism is the *locale*.
Applications not using that info will have problems (for example,
"xterm" gets the width of characters wrong as it uses it's own,
locale-independent table under all locales).
Rxvt-unicode uses the "LC_CTYPE" locale category to select encoding.
All programs doing the same (that is, most) will automatically agree
in the interpretation of characters.
Unfortunately, there is no system-independent way to select locales,
nor is there a standard on how locale specifiers will look like.
On most systems, the content of the "LC_CTYPE" environment variable
contains an arbitrary string which corresponds to an
already-installed locale. Common names for locales are
"en_US.UTF-8", "de_DE.ISO-8859-15", "ja_JP.EUC-JP", i.e.
"language_country.encoding", but other forms (i.e. "de" or "german")
are also common.
Rxvt-unicode ignores all other locale categories, and except for the
encoding, ignores country or language-specific settings, i.e.
"de_DE.UTF-8" and "ja_JP.UTF-8" are the normally same to
rxvt-unicode.
If you want to use a specific encoding you have to make sure you
start rxvt-unicode with the correct "LC_CTYPE" category.
Can I switch locales at runtime?
Yes, using an escape sequence. Try something like this, which sets
rxvt-unicode's idea of "LC_CTYPE".
printf '\e]701;%s\007' ja_JP.SJIS
See also the previous answer.
Sometimes this capability is rather handy when you want to work in
one locale (e.g. "de_DE.UTF-8") but some programs don't support it
(e.g. UTF-8). For example, I use this script to start "xjdic", which
first switches to a locale supported by xjdic and back later:
printf '\e]701;%s\007' ja_JP.SJIS
xjdic -js
printf '\e]701;%s\007' de_DE.UTF-8
You can also use xterm's "luit" program, which usually works fine,
except for some locales where character width differs between
program- and rxvt-unicode-locales.
Can I switch the fonts at runtime?
Yes, using an escape sequence. Try something like this, which has
the same effect as using the "-fn" switch, and takes effect
immediately:
printf '\e]50;%s\007' "9x15bold,xft:Kochi Gothic"
This is useful if you e.g. work primarily with japanese (and prefer
a japanese font), but you have to switch to chinese temporarily,
where japanese fonts would only be in your way.
You can think of this as a kind of manual ISO-2022 switching.
Why do italic characters look as if clipped?
Many fonts have difficulties with italic characters and hinting. For
example, the otherwise very nicely hinted font "xft:Bitstream Vera
Sans Mono" completely fails in it's italic face. A workaround might
be to enable freetype autohinting, i.e. like this:
URxvt.italicFont: xft:Bitstream Vera Sans Mono:italic:autohint=true
URxvt.boldItalicFont: xft:Bitstream Vera Sans Mono:bold:italic:autohint=true
My input method wants <some encoding> but I want UTF-8, what can I do?
You can specify separate locales for the input method and the rest
of the terminal, using the resource "imlocale":
URxvt*imlocale: ja_JP.EUC-JP
Now you can start your terminal with "LC_CTYPE=ja_JP.UTF-8" and
still use your input method. Please note, however, that you will not
be able to input characters outside "EUC-JP" in a normal way then,
as your input method limits you.
Rxvt-unicode crashes when the X Input Method changes or exits.
Unfortunately, this is unavoidable, as the XIM protocol is racy by
design. Applications can avoid some crashes at the expense of memory
leaks, and Input Methods can avoid some crashes by careful ordering
at exit time. kinput2 (and derived input methods) generally
succeeds, while SCIM (or similar input methods) fails. In the end,
however, crashes cannot be completely avoided even if both sides
cooperate.
So the only workaround is not to kill your Input Method Servers.
Rxvt-unicode uses gobs of memory, how can I reduce that?
Rxvt-unicode tries to obey the rule of not charging you for
something you don't use. One thing you should try is to configure
out all settings that you don't need, for example, Xft support is a
resource hog by design, when used. Compiling it out ensures that no
Xft font will be loaded accidentally when rxvt-unicode tries to find
a font for your characters.
Also, many people (me included) like large windows and even larger
scrollback buffers: Without "--enable-unicode3", rxvt-unicode will
use 6 bytes per screen cell. For a 160x?? window this amounts to
almost a kilobyte per line. A scrollback buffer of 10000 lines will
then (if full) use 10 Megabytes of memory. With "--enable-unicode3"
it gets worse, as rxvt-unicode then uses 8 bytes per screen cell.
Can I speed up Xft rendering somehow?
Yes, the most obvious way to speed it up is to avoid Xft entirely,
as it is simply slow. If you still want Xft fonts you might try to
disable antialiasing (by appending ":antialiasing=false"), which
saves lots of memory and also speeds up rendering considerably.
Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong?
Rxvt-unicode will use whatever you specify as a font. If it needs to
fall back to it's default font search list it will prefer X11 core
fonts, because they are small and fast, and then use Xft fonts. It
has antialiasing disabled for most of them, because the author
thinks they look best that way.
If you want antialiasing, you have to specify the fonts manually.
Mouse cut/paste suddenly no longer works.
Make sure that mouse reporting is actually turned off since killing
some editors prematurely may leave the mouse in mouse report mode.
I've heard that tcsh may use mouse reporting unless it otherwise
specified. A quick check is to see if cut/paste works when the Alt
or Shift keys are depressed. See rxvt(7)
What's with this bold/blink stuff?
If no bold colour is set via "colorBD:", bold will invert text using
the standard foreground colour.
For the standard background colour, blinking will actually make the
text blink when compiled with "--enable-blinking". with standard
colours. Without "--enable-blinking", the blink attribute will be
ignored.
On ANSI colours, bold/blink attributes are used to set
high-intensity foreground/background colors.
color0-7 are the low-intensity colors.
color8-15 are the corresponding high-intensity colors.
I don't like the screen colors. How do I change them?
You can change the screen colors at run-time using ~/.Xdefaults
resources (or as long-options).
Here are values that are supposed to resemble a VGA screen,
including the murky brown that passes for low-intensity yellow:
URxvt.color0: #000000
URxvt.color1: #A80000
URxvt.color2: #00A800
URxvt.color3: #A8A800
URxvt.color4: #0000A8
URxvt.color5: #A800A8
URxvt.color6: #00A8A8
URxvt.color7: #A8A8A8
URxvt.color8: #000054
URxvt.color9: #FF0054
URxvt.color10: #00FF54
URxvt.color11: #FFFF54
URxvt.color12: #0000FF
URxvt.color13: #FF00FF
URxvt.color14: #00FFFF
URxvt.color15: #FFFFFF
And here is a more complete set of non-standard colors described
(not by me) as "pretty girly".
URxvt.cursorColor: #dc74d1
URxvt.pointerColor: #dc74d1
URxvt.background: #0e0e0e
URxvt.foreground: #4ad5e1
URxvt.color0: #000000
URxvt.color8: #8b8f93
URxvt.color1: #dc74d1
URxvt.color9: #dc74d1
URxvt.color2: #0eb8c7
URxvt.color10: #0eb8c7
URxvt.color3: #dfe37e
URxvt.color11: #dfe37e
URxvt.color5: #9e88f0
URxvt.color13: #9e88f0
URxvt.color6: #73f7ff
URxvt.color14: #73f7ff
URxvt.color7: #e1dddd
URxvt.color15: #e1dddd
How can I start rxvtd in a race-free way?
Try "rxvtd -f -o", which tells rxvtd to open the display, create the
listening socket and then fork.
What's with the strange Backspace/Delete key behaviour?
Assuming that the physical Backspace key corresponds to the
BackSpace keysym (not likely for Linux ... see the following
question) there are two standard values that can be used for
Backspace: "^H" and "^?".
Historically, either value is correct, but rxvt-unicode adopts the
debian policy of using "^?" when unsure, because it's the one only
only correct choice :).
Rxvt-unicode tries to inherit the current stty settings and uses the
value of `erase' to guess the value for backspace. If rxvt-unicode
wasn't started from a terminal (say, from a menu or by remote
shell), then the system value of `erase', which corresponds to
CERASE in <termios.h>, will be used (which may not be the same as
your stty setting).
For starting a new rxvt-unicode:
# use Backspace = ^H
$ stty erase ^H
$ rxvt
# use Backspace = ^?
$ stty erase ^?
$ rxvt
Toggle with "ESC [ 36 h" / "ESC [ 36 l" as documented in rxvt(7).
For an existing rxvt-unicode:
# use Backspace = ^H
$ stty erase ^H
$ echo -n "^[[36h"
# use Backspace = ^?
$ stty erase ^?
$ echo -n "^[[36l"
This helps satisfy some of the Backspace discrepancies that occur,
but if you use Backspace = "^H", make sure that the termcap/terminfo
value properly reflects that.
The Delete key is a another casualty of the ill-defined Backspace
problem. To avoid confusion between the Backspace and Delete keys,
the Delete key has been assigned an escape sequence to match the
vt100 for Execute ("ESC [ 3 ~") and is in the supplied
termcap/terminfo.
Some other Backspace problems:
some editors use termcap/terminfo, some editors (vim I'm told)
expect Backspace = ^H, GNU Emacs (and Emacs-like editors) use ^H for
help.
Perhaps someday this will all be resolved in a consistent manner.
I don't like the key-bindings. How do I change them?
There are some compile-time selections available via configure.
Unless you have run "configure" with the "--disable-resources"
option you can use the `keysym' resource to alter the keystrings
associated with keysyms.
Here's an example for a URxvt session started using "rxvt -name
URxvt"
URxvt.keysym.Home: \033[1~
URxvt.keysym.End: \033[4~
URxvt.keysym.C-apostrophe: \033<C-'>
URxvt.keysym.C-slash: \033<C-/>
URxvt.keysym.C-semicolon: \033<C-;>
URxvt.keysym.C-grave: \033<C-`>
URxvt.keysym.C-comma: \033<C-,>
URxvt.keysym.C-period: \033<C-.>
URxvt.keysym.C-0x60: \033<C-`>
URxvt.keysym.C-Tab: \033<C-Tab>
URxvt.keysym.C-Return: \033<C-Return>
URxvt.keysym.S-Return: \033<S-Return>
URxvt.keysym.S-space: \033<S-Space>
URxvt.keysym.M-Up: \033<M-Up>
URxvt.keysym.M-Down: \033<M-Down>
URxvt.keysym.M-Left: \033<M-Left>
URxvt.keysym.M-Right: \033<M-Right>
URxvt.keysym.M-C-0: list \033<M-C- 0123456789 >
URxvt.keysym.M-C-a: list \033<M-C- abcdefghijklmnopqrstuvwxyz >
URxvt.keysym.F12: command:\033]701;zh_CN.GBK\007
See some more examples in the documentation for the keysym resource.
I'm using keyboard model XXX that has extra Prior/Next/Insert keys. How
do I make use of them? For example, the Sun Keyboard type 4 has the
following mappings that rxvt-unicode doesn't recognize.
KP_Insert == Insert
F22 == Print
F27 == Home
F29 == Prior
F33 == End
F35 == Next
Rather than have rxvt-unicode try to accommodate all the various
possible keyboard mappings, it is better to use `xmodmap' to remap
the keys as required for your particular machine.
How do I distinguish wether I'm running rxvt-unicode or a regular xterm?
I need this to decide about setting colors etc.
rxvt and rxvt-unicode always export the variable "COLORTERM", so you
can check and see if that is set. Note that several programs, JED,
slrn, Midnight Commander automatically check this variable to decide
whether or not to use color.
How do I set the correct, full IP address for the DISPLAY variable?
If you've compiled rxvt-unicode with DISPLAY_IS_IP and have enabled
insecure mode then it is possible to use the following shell script
snippets to correctly set the display. If your version of
rxvt-unicode wasn't also compiled with ESCZ_ANSWER (as assumed in
these snippets) then the COLORTERM variable can be used to
distinguish rxvt-unicode from a regular xterm.
Courtesy of Chuck Blake <cblake@BBN.COM> with the following shell
script snippets:
# Bourne/Korn/POSIX family of shells:
[ ${TERM:-foo} = foo ] && TERM=xterm # assume an xterm if we don't know
if [ ${TERM:-foo} = xterm ]; then
stty -icanon -echo min 0 time 15 # see if enhanced rxvt or not
echo -n '^[Z'
read term_id
stty icanon echo
if [ ""${term_id} = '^[[?1;2C' -a ${DISPLAY:-foo} = foo ]; then
echo -n '^[[7n' # query the rxvt we are in for the DISPLAY string
read DISPLAY # set it in our local shell
fi
fi
How do I compile the manual pages for myself?
You need to have a recent version of perl installed as
/usr/bin/perl, one that comes with pod2man, pod2text and pod2html.
Then go to the doc subdirectory and enter "make alldoc".
My question isn't answered here, can I ask a human?
Before sending me mail, you could go to IRC: "irc.freenode.net",
channel "#rxvt-unicode" has some rxvt-unicode enthusiasts that might
be interested in learning about new and exciting problems (but not
FAQs :).