I am new to GNU screen command. I created .screenrc file in my home directory and added below two lines(source) to display the status bar.
caption always
caption string "%{= bW}%3n %{y}%t %{-}%= %{m}%H%?%{-} -- %{c}%l%?%{-} -- %D %M %d %{y}%c"
but I am not seeing the status bar(after entering into screen mode).When I run source .screenrc, I am getting error "-bash: caption: command not found".
What am I missing here?
Problem was that, I already started screen and then added the file .screenrc in my home directory, but active screens are not recognizing the .screenrc file.
so I killed all active screen sessions and then stated new screen session (screen). Now I am able to see the status bar.
First, you cannot do soruce .screenrc, since that tries to run the file with bash (or whatever is in the first line if you have #!/some/shellorprogram).
I'm not sure why you are not seeing the status bar, but the source command is a red herring.
Can you try something simpler with the caption, and maybe even something static to see if the syntax is right and it's the format string that is breaking?
Something like
caption always
caption string "test caption"
On my Ubuntu server the test caption works, so it's probably your format string. Build it piece by piece to find the busted part.
The other one works, too. Where are you putting your screenrc file?
ls -al ~/.screenrc
Related
When I tried to use monkeyrunner command to run recorder, I got the error: mismatched input 'monkey_recorder' expecting NEWLINE.
Here is screenshot of my command.
enter image description here
You should try AndroidViewClient/culebra which will give you some advantages over monkeyrunner and monkey_recorder. For example, instead of recording the screen coordinates for a touch, culebra records the selector of the View touched so the script or test will be screen coordinates agnostic.
See Culebra GUI page for details.
I've removed and added a few times now the following line to ~/.tmux.conf:
set -ga terminal-overrides ',xterm*:smcup#:rmcup#'
Which according to the person who provided it does the following:
to fool the multiplexers into thinking that the terminal has no "alternate screen" mode (such as that used by pico, mutt, etc). This is accomplished by setting termcap commands for the session.
The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as.
The end result is that the overflow ends up in the terminal's scrollback buffer instead of disappearing. Of course, since this is one static buffer, things will get messy as you switch between screen or tmux windows, but this is handy for quickly flicking up to see the output of an ls command or the such.
I don't quite understand the bolded section (emphasis added), but guess this is the source of what I'm seeing. It's causing some weird sort of unicode overspill upon exiting tmux.
Pasted as plaintext this text won't show up, but the symbol [001B]112 appears alongside the usual [exited]:
]112[exited]
(FWIW I think it has pasted in that line, but isn't displaying)
I followed this advice ("Use terminal scrollbar with tmux"), and while it does work, this is just ugly/annoying to see that upon exiting. Can anyone advise how to fix or avoid the output message?
Offhand, I would get the unwanted "message" is some hard-coded application (or script) which is helpfully resetting the xterm dynamic text cursor color. See XTerm Control Sequences in the description of Operating System Controls:
The dynamic colors can also be reset to their default
(resource) values:
...
Ps = 1 1 2 -> Reset text cursor color.
So... somewhere there is some script doing the equivalent of
echo -n -e '\e]112\a
The results probably depend most on what particular terminal emulator you are using. Both screen and tmux filter out escape sequences that their developers did not care to implement, and pass through those that the terminal "should" handle.
Just take a look at sentence you provided: "The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as."
In my case, the $TERM has value xterm-256color and the corresponding line in ~/.tmux.conf looks like:
set -g terminal-overrides "xterm-color256:smcup#:rmcup#"
To clarify, I mean the icon that is displayed when the app is running (e.g. inside the dock).
With trial and error, I found out that it uses "/usr/share/pixmap/xfce4-terminal.xpm" as the icon (tested by replacing this file with some other icon).
I was unable to find where it maps the running xterm to this icon.
If I copy the xterm binary to a different name and run that one, it gets a different icon, which shows that there is a possibility to change it.
I already tried setting the "xterm*iconPixmap:" resource, but that appears to have no effect at all.
You could try using xseticon
usage: xseticon [options] path/to/icon.png
options:
-name : apply icon to the window of the name supplied
-id : apply icon to the window id supplied
Sets the window icon to the specified .png image. The image is loaded from
the file at runtime and sent to the X server; thereafter the file does not
need to exist, and can be deleted/renamed/modified without the X server or
window manager noticing.
If no window selection option is specified, the window can be interactively
selected using the cursor.
Hints: xseticon -id "$WINDOWID" path/to/icon.png Will set the icon for an xterm.
********** EDIT **********
I think you need the imagemagick program installed to access the convert command. Then, find an icon that you like and convert it to an xbm file:
Code:
convert /path/to/icon/file /path/to/xterm.xbm
Create an ~/.Xresources file with the following content:
Code:
xterm*iconPixmap: /path/to/xterm.xbm
Then merge in the ~/Xresources file:
Code:
xrdb -merge ~/.Xresources
The update came from: http://forum.xfce.org/viewtopic.php?id=6779
I finally managed to do by setting *iconHint on the xterm resource.
The value needs to be a path to an .xpm file WITHOUT the extension.
X resources that you want to be loaded at login time need to go into an ~/.Xdefaults file.
So a complete solution for an icon my-xterm.xpm would be:
mkdir ~/.icons
mv my-xterm.xpm ~/.icons/
echo 'xterm*iconHint: '$HOME'/.icons/my-xterm' >> ~/.Xdefaults
If you want your changed ~/.Xdefaults to become active without logging in, run xrdb -merge ~/.Xdefaults
If you just want one xterm to have a different icon, you can start the xterm like this:
xterm -xrm 'xterm*iconHint: /full/path/to/icon' …
Not 100% sure that changing the .desktop file would help in XFCE. But it's a worth a shot.
Find the path to your local icons, here is in the sub path of
/usr/local/share/icons.
Then simply copy the .desktop file to you home dir eg:
cp /usr/share/applications/xterm-color.desktop ~/.local/share/applications/
Then edit the .dekstop fil in an editor, there is a line like this:
Icon=xterm-color
Replace this with a icon name from your icons path and logout and back in and you should be good to go. (The icon should not have the file extention like .png or .svg).
My Zsh prompt cursor is sometimes (most of the time actually) a line below were it should be (attaching screenshot):
If I hit enter multiple times, the prompt seems to get fixed:
My first thought is that it was an error within my custom prompt, so I replaced by prompt with a simple one containing only one digit:
PROMPT='> '
But the error persisted.
Any clues about what can be missing?
You can find my theme here: http://pastebin.com/cSJwGWKZ.
Notice that I'm using Oh My Zsh.
EDIT: The prompt seems to get fixed when I reach the bottom of the terminal (by hitting enters).
The culprit is %{$(echotc DO 1)%} in your RPROMPT, which moves the cursor one line down when printing RPROMPT. When reaching the bottom of your terminal there is no additional line to go down to, so the cursor just remains where it was.
Depending on where you want your RPROMPT you have basically two options:
On the same line as your input cursor (after λ):
Just remove %{$(echotc DO 1)%} from your RPROMPT:
RPROMPT='$(_git_time_since_commit) $(git_prompt_status) ${_return_status}%'
One line (or any other number of lines, really) above your input:
Add %{$(echotc UP 1)%} at the beginning of your RPROMPT, this will move the cursor up one line, print the right prompt and move back down one line:
RPROMPT='%{$(echotc UP 1)%}$(_git_time_since_commit) $(git_prompt_status) ${_return_status}%{$(echotc DO 1)%}'`
Note: the second method may lead to RPROMPT overwriting parts of PROMPT if both get to long and/or the terminal window to narrow. If RPROMPT remains on the same line as input, it will be hidden once the input reaches it (and will reapper if you delete some of the input).
Here's what happens. I'm using Vim + LaTeX-Suite to edit TeX files in Vim. This could be in the Terminal or in MacVim.
I happily
Insert lots of $\LaTeX \commands$ etc. I love using the $\backslash$.
TeX works great. No problem.
Then I go and open up a .R file in the same window (different tab). R-Plugin for Vim uses the <Leader> key (mapped to \ as per usual) to execute commands, e.g. I type \sa to send the selection to R and execute and move the window down. Life is nice.
Problem: even though while editing an R file, Vim is nice enough not to bug me in insert mode when I type \, for some reason when I switch back to the tab to edit the TeX file, then type \ in insert mode, it moves the cursor left of the \ and pauses as though waiting for the rest of the command, before then re-moving to the right of the \ and moving on as I type.
Below shows what happens just from typing \ in insert mode; obviously I could reproduce this by moving the cursor to the left with the arrow keys, but that's not how this happened--the cursor just moves left for a split second as though waiting for the R command to finish being input.
So: how can I stop the annoying behavior in the TeX file insert mode, without sacrificing other functionality? Note, (a) I don't expect mapping <Leader> to a different key to help since then that key will just have the same left-cursor-move problem in TeX; (b), I like the leader as \ anyway so I don't want to change it.
Put this line in your vimrc (requires Vim-R-plugin >= 0.9.9.2):
let g:vimrplugin_insert_mode_cmds = 0
If the problem persists, you can do the following in Normal mode to know what are the keyboard shortcuts in Insert mode:
:imap