I am trying to configure the Termite Terminal to my liking; however, it seems that I cannot get the terminal to beep on a bell (\a) character.
Here is my ~/.config/termite/config file:
[options]
allow_bold = true
audible_bell = true
bold_is_bright = true
cell_height_scale = 1.0
cell_width_scale = 1.0
clickable_url = true
hyperlinks = true
dynamic_title = true
font = Hermit 13
fullscreen = true
icon_name = terminal
mouse_autohide = true
scroll_on_output = false
scroll_on_keystroke = true
scrollback_lines = 10000
search_wrap = false
urgent_on_bell = true
browser = firefox
scrollbar = off
# ... trimmed the colors portion ...
The XDG_CONFIG_HOME envvar is not set, and the only other configuration file that I have on my system for Termite is the one located at $XDG_CONFIG_DIRS/termite/config; however, it's not even used, since my above config takes precedence.
In urxvt, which I also have installed on my system, executing echo -ne '\a' makes a bell sound, since I have configured this terminal with the Bell-command Perl extension. However, neither in Termite nor in the Xfce Terminal does this command does not trigger a bell sound.
I have confirmed that I am able to play sounds from Termite (e.g. paplay /usr/share/sounds/ubuntu/stereo/bell.ogg works as expected), but for some reason echo -ne '\a' makes no sound.
How can I enable audible bell in Termite?
P.S. I don't know if it matters, but I am running all this on Manjaro with the Xfce4 desktop environment.
Related
I am trying to use Cmder in Windows Terminal. I tried following this guide, and I did everything as it says.
However, there is a small issue. No matter what I do, the prompt background colour does not change, it stays black.
I couldn't figure out the issue. Any suggestions?
In the comments section of the same article
I ran into this issue as well and was able to get it working. In your
"%cmder_root%\config" directory, create a file called "my_prompt.lua"
and add the following to it:
function my_prompt_filter()
cwd = clink.get_cwd()
prompt = "\x1b[1;32;49m{cwd} {git}{hg}{svn} \n\x1b[1;39;49m{lamb} \x1b[0m"
new_value = string.gsub(prompt, "{cwd}", cwd)
clink.prompt.value = string.gsub(new_value, "{lamb}", "λ")
end
clink.prompt.register_filter(my_prompt_filter, 1)
Kudos to Eric Grandt
#AMagyar 's answer is great, except that if you use conda, pyenv or other virtual environments, that information would be omitted (when it should be (base) λ, you will get λ). Instead, you can create my_prompt.lua as something like:
function my_prompt_filter()
local prompt = clink.prompt.value
prompt = string.gsub(prompt, '^\x1b%[1;32;40m', '\x1b[1;32;49m')
prompt = string.gsub(prompt, '\n\x1b%[1;39;40m', '\n\x1b[1;39;49m')
clink.prompt.value = prompt
end
clink.prompt.register_filter(my_prompt_filter, 1)
Everything is settled.
What controls the terminal text & background color?
In function set_prompt_filter in %cmder_root%\vender\clink.lua, you may read lines like:
local cmder_prompt = "\x1b[1;32;40m{cwd} {git}{hg}{svn} \n\x1b[1;39;40m{lamb} \x1b[0m"
This is the prototype of cmder prompts. The {cwd}, {git}, {lamb}, etc, are to be substituted with the actual content later on. The \x1b[1;32;40m is the ANSI escape sequence that controls the color of following text. 32 means green text color, 40 means black background color, 39 means default text color, and 49 means default background color.
Why was pyenv/conda environment omitted?
Also in function set_prompt_filter in %cmder_root%\vender\clink.lua, you may find how cmder added the information of virtual environments into {lamb} (or more specifically, prompts with () or []). So either you have to retrieve that information from the original prompt, or simply just replace the color codes, as in this answer.
I've just moved from xterm to URxvt and the shell prompt with URxvt uses the dark version of the colors instead of the light. Not sure if there's something obvious I've missed in the switch.
xterm prompt:
URxvt prompt:
.Xresources with xterm:
XTerm*font: xft:Source Code Pro for Powerline-10:pixelsize=17:hinting=True;antialias:True
! sync primary and main clipboards
XTerm*selectToClipboard: true
! double-click highlights words until blank text
XTerm*VT100.cutNewLine: false
XTerm*VT100.cutToBeginningOfLine: false
XTerm*VT100.charClass: 33:48,35:48,37:48,42:48,45-47:48,64:48,95:48,126:48
xterm*highlightSelection: true
! XTerm*font: 9x15
XTerm*faceName: Inconsolata
XTerm*faceSize: 13
XTerm*allowBoldFonts: false
XTerm*boldMode: false
XTerm*colorBDMode: true
XTerm*foreground: #c5c8c6
XTerm*background: #111111
*cursorColor: #aeafad
*color0: #000000
*color1: #912226
*color2: #727b33
*color3: #ae7b00
*color4: #1d2594
*color5: #682a9b
*color6: #2b6651
*color7: #929593
*color8: #666666
*color9: #cc6666
*color10: #b5bd68
*color11: #f0c674
*color12: #81a2be
*color13: #b294bb
*color14: #8abeb7
*color15: #ecebec
.Xresources with URxvt:
URxvt.scrollBar: false
URxvt.font: xft:Source Code Pro for Powerline-10:pixelsize=17:hinting=True;antialias:True
URxvt.intensityStyles: false
URxvt.highlightSelection: true
! Fix ctrl moving through words
URxvt*altSendsEscape: true
URxvt.keysym.Control-Up: \033[1;5A
URxvt.keysym.Control-Down: \033[1;5B
URxvt.keysym.Control-Left: \033[1;5D
URxvt.keysym.Control-Right: \033[1;5C
! sync primary and main clipboards
URxvt.selectToClipboard: true
URxvt*background: #111111
URxvt*foreground: #c5c8c6
URxvt*cursorColor: #aeafad
URxvt*color0: #000000
URxvt*color1: #912226
URxvt*color2: #727b33
URxvt*color3: #ae7b00
URxvt*color4: #1d2594
URxvt*color5: #682a9b
URxvt*color6: #2b6651
URxvt*color7: #929593
URxvt*color8: #666666
URxvt*color9: #cc6666
URxvt*color10: #b5bd68
URxvt*color11: #f0c674
URxvt*color12: #81a2be
URxvt*color13: #b294bb
URxvt*color14: #8abeb7
URxvt*color15: #ecebec
The short answer is that xterm and urxvt do not combine bold attribute with color in the same way. In ncurses, that should be reflected in the ncv (no color video) mask (and tell ncurses to not bother trying to do that), but your shell-prompt isn't that sophisticated — and you'd probably not like it to stop doing bold, even though the result is not quite what you'd expect.
You can see the differences using tack, though Fedora seems not to have packaged that (it's been separate from ncurses for more than 10 years). Here's a screenshot comparing xterm and ncurses, using the terminal descriptions provided by Fedora (but see this page):
It was a combination of URxvt.intensityStyles being set to false, and the bold font.
I've removed URxvt.intensityStyles: false from the config and added URxvt.boldFont: Source Code Pro for Powerline-10:pixelsize=17:hinting=True;antialias:True.
I'm using pexpect to automate ssh-ing into a remote server that prompts for a password. The process is very simple, and works great:
child = pexpect.spawn("ssh -Y remote.server")
child.expect(re.compile(b".*password.*"))
child.sendline(password)
child.interact()
This works great, however, I notice one quite annoying quirk I have not been able to figure out. When I use vim in this terminal, it seems to not resize correctly. When ssh-ing directly, and using a program such as vim, I can resize my terminal window (locally), and the remote program automatically/interactively fixes the columns and lines. My pexpect instance does not. There are a few other minor quirks that I can lvie with, but this one is quite annoying.
I'm hoping to find a way I can get my pexpect ssh session to behave the same way a native ssh session does, or at the very least understand the reason the two behave differently.
The SIGWINCH handles window size change. If you need it behave the same of native ssh, you should also set the pexpect initial window size:
import pexpect, struct, fcntl, termios, signal, sys
def get_terminal_size():
s = struct.pack("HHHH", 0, 0, 0, 0)
a = struct.unpack('hhhh', fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, s))
return a[0], a[1]
def sigwinch_passthrough(sig, data):
global p
if not p.closed:
p.setwinsize(*get_terminal_size())
p = pexpect.spawn('/bin/bash')
# Set the window size the same of current terminal window size
p.setwinsize(*get_terminal_size())
# Hook the window change signal so that the pexpect window size change as well
signal.signal(signal.SIGWINCH, sigwinch_passthrough)
p.interact()
There's actually an example for this under the interact() function in pexpect's doc. Just like writing C code, it requires a SIGWINCH handler.
import pexpect, struct, fcntl, termios, signal, sys
def sigwinch_passthrough (sig, data):
s = struct.pack("HHHH", 0, 0, 0, 0)
a = struct.unpack('hhhh', fcntl.ioctl(sys.stdout.fileno(),
termios.TIOCGWINSZ , s) )
global p
p.setwinsize(a[0], a[1])
# Note this 'p' global and used in sigwinch_passthrough.
p = pexpect.spawn('/bin/bash')
signal.signal(signal.SIGWINCH, sigwinch_passthrough)
p.interact()
I work on Mac OS X 10.7.3 with R version 2.14.0 (2011-10-31). My ~/.Rprofile is
options(repos=c(CRAN="http://cran.ch.r-project.org",
BioC="http://www.bioconductor.org",
Omegahat="http://www.omegahat.org/R"),
pdfviewer=path.expand("~/R/misc/shell_scripts/skim"),
browser="mybrowser")
where mybrowser is a file in /bin/ which contains open -a "/Applications/Google Chrome.app". When I open R and type help.start(), all I obtain is that Chrome becomes active, but no real output from help.start(). How can I properly set up browser in options so that help.start() works as expected?
I originally just had browser="Chrome", but R couldn't find the browser. I tried several kinds of things to solve this (e.g., browser="/Applications/Google Chrome.app" [and various variants to escape the blank]), but none worked. I guess that's because sh /Applications/Google\ Chrome.app just does not work. On the Mac, applications are opened via open -a ..., that's why I created mybrowser. That finally opened the browser, but I couldn't figure out how to get help.start to work properly.
Create a Renviron file in your home (i.e ~/.Renviron) and add this line.
R_BROWSER=google-chrome
I'm not sure about "chrome" part, i use conkeror and my setup is :
R_BROWSER=conkeror
But this should do the tricks
In the meantime, Hans-Joerg Bibiko helped out: the solution is to set browser to browser="/usr/bin/open -a 'Google Chrome'"
If you look in utils:::print.help_files_with_topic (the function that actually issues the call to browseURL()), there is this really annoying line:
if (.Platform$GUI == "AQUA" && type == "html")
browser <- get("aqua.browser", envir = as.environment("tools:RGUI"))
And since .Platform$GUI == "AQUA" on OSX, this means that you have to do some trickery to browse help files in your favorite browser. Hence, in my .Rprofile (located here path.expand('~/.Rprofile'), of course), I included these lines.
options(help_type='html')
options(browser="/usr/bin/open -a '/applications/Google Chrome.app'")
p <- .Platform
p$GUI = 'unknown'
unlockBinding('.Platform', as.environment('package:base'))
assign('.Platform', p , envir=as.environment('package:base'))
lockBinding('.Platform', as.environment('package:base'))
rm(p)
So far it doesn't seem to have any effect other than enabling use of an alternate browser, but you may want to read the section labeled "Aqua" in ?.Profile if you're worried about messing around with base.
Please save me from a potential nervous breakdown!
I've been following Apples documentation (see below) on how to create a Startup Item. Currently I'm just trying to get my script to print something to the console, much less actually run my app.
Here are my two scripts, one is the startup executable, the other is the plist:
#!/bin/sh
. /etc/rc.common
# The start subroutine
StartService() {
# Insert your start command below. For example:
echo "hey Eric we've started"
# End example.
}
# The stop subroutine
StopService() {
# Insert your stop command(s) below. For example:
echo "STOPPED ERIC"
# End example.
}
# The restart subroutine
RestartService() {
# Insert your start command below. For example:
echo "RESTART ERIC"
# End example.
}
RunService "$1"
{
Description = "Software Update service";
Provides = ("SoftwareUpdateServer");
Requires = ("Network");
Uses = ("Network");
OrderPreference = "Late";
Messages =
{
start = "Starting Software Update service";
stop = "Stopping Software Update service";
};
}
Using terminal I tried to set the permissions as closely as possible as to how it is documented in the example in the link below. The odd thing was that the files didn't show the 'root' aspect to their ownership.
I then ran SystemStarter start theApp and nothing happens. Absolutely nothing.
Any help?
http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/StartupItems.html
You should not create a Startup Item any more. It's a legacy mechanism and superseded by launchd. Write a plist for launchd instead. I know this is not the help you wanted, but sadly with Apple, you need to follow the mothership...
Read this section of the same document instead.
See the document just you quoted yourself:
Note: The launchd facility is he preferred mechanism for launching daemons in Mac OS X v10.4 and higher. Unless your software requires compatibility with Mac OS X v10.3 or earlier, you should use the launchd facility instead of writing a startup item. For more information, see “Guidelines for Creating and Launching Daemons.”
Note that v10.4 become available in 2005.