… | |
… | |
575 | URxvt.color7: #e1dddd |
575 | URxvt.color7: #e1dddd |
576 | URxvt.color15: #e1dddd |
576 | URxvt.color15: #e1dddd |
577 | |
577 | |
578 | =item How can I start @@RXVT_NAME@@d in a race-free way? |
578 | =item How can I start @@RXVT_NAME@@d in a race-free way? |
579 | |
579 | |
580 | Despite it's name, @@RXVT_NAME@@d is not a real daemon, but more like a |
580 | Try C<@@RXVT_NAME@@d -f -o>, which tells @@RXVT_NAME@@d to open the |
581 | server that answers @@RXVT_NAME@@c's requests, so it doesn't background |
581 | display, create the listening socket and then fork. |
582 | itself. |
|
|
583 | |
|
|
584 | To ensure @@RXVT_NAME@@d is listening on it's socket, you can use the |
|
|
585 | following method to wait for the startup message before continuing: |
|
|
586 | |
|
|
587 | { @@RXVT_NAME@@d & } | read |
|
|
588 | |
582 | |
589 | =item What's with the strange Backspace/Delete key behaviour? |
583 | =item What's with the strange Backspace/Delete key behaviour? |
590 | |
584 | |
591 | Assuming that the physical Backspace key corresponds to the |
585 | Assuming that the physical Backspace key corresponds to the |
592 | BackSpace keysym (not likely for Linux ... see the following |
586 | BackSpace keysym (not likely for Linux ... see the following |