Does someone know the reason why in the tmux configuration
set-option -g prefix C-a
unbind-key C-b
bind-key a send-prefix
bind-key C-c new-window
bind-key C-n next-window
bind-key C-p previous-window
bind-key C-a last-window
new-session -n $HOSTNAME
the mapping C-a works, but not the mapping C-c, C-n and C-p?
Note that those bindings are for prefix plus sequence, so you've successfully bound C-a C-c, C-a C-c, etc. If you're looking to use just C-c, you want to use the -n ("no prefix") arg to bind-key:
bind-key -n C-c new-window
The real problem was that there is a tmux server that needs to be stopped in order for the configuration changes to become effective. I wasn't aware of this.
Related
I want to extract the name of a prerequisite from the target.
TARS= zabc zbcd zcde zdef
# and I want abc.o to be a prerequisite for zabc
$(TARS): $(patsubst z%,%.o,$#) z.c
gcc -c -o $# $^
However, this is not working.
Consider the following:
TARS= zabc zbcd zcde zdef
# and I want abc.o to be a prerequisite for zabc
$(TARS): $(patsubst z%,%.o,zabc) z.c
gcc -c -o $# $^
Ignore the TARS in above code but this works for make zabc.
So I want to know how to use $# as an argument in the function for getting the prerequisite name.
The short answer is, you can't. Automatic variables, as made clear in the documentation, are only set inside the recipe of a rule, not when expanding the prerequisites. There are advanced features you can take advantage of to work around this, but they are intended only to be used in very complicated situations which this isn't, really.
What you want to do is exactly what pattern rules were created to support:
all: $(TARS)
z%: z%.o z.c
gcc -c -o $# $^
That's all you need.
ETA
GNU make doesn't provide any completion capabilities, so you'll need to figure out where that completion is done and how it works, to know what you need to have in your makefile to have it work. If it only completes on explicit targets, you can either just make them like this:
all: $(TARS)
$(TARS):
z%: z%.o z.c
gcc -c -o $# $^
Or you can use static pattern rules instead:
all: $(TARS)
$(TARS): z%: z%.o z.c
gcc -c -o $# $^
I didn't understand the last sentence in your comment below.
This is the guilty makefile :
$ cat -n example.mak
1 define this
2 $(patsubst $(1)/%.o,%.o,why_this_does/that.o)
3 $(patsubst butnot/%.o,%.o, butnot/but_not_that.o)
4 endef
5
6 why:
7 $(info $(call this, why_this_does) ?)
And this is my question :
$ make -f example.mak
why_this_does/that.o
but_not_that.o ?
make: 'why' is up to date.
The root cause is not in patsubst but in call. The manual has a note:
A final caution: be careful when adding whitespace to the arguments to call. As with other functions, any whitespace contained in the second and subsequent arguments is kept; this can cause strange effects. It’s generally safest to remove all extraneous whitespace when providing parameters to call.
and indeed, if you replace
$(info $(call this, why_this_does) ?)
by
$(info $(call this,why_this_does) ?)
you get what you want.
I have recently installed byobu terminal multiplexer, and I found that I am not able to move in a fast way through the terminal. In linux you can do: Control+Arrows (Left/Right). I want to find the same but in byobu.
And I would like to configure it, in order to be able to use Ctrl+Left and Ctrl+Right if it's possible, not other combinations.
Any idea?
I have tried already this: How to make byobu forward-word and backward-word with CTRL+arrow?
But is not working for me.
Ubuntu 13.10
Thanks in advance.
One way to change your key bindings is to edit /usr/share/byobu/keybindings/f-keys.tmux (or edit ~/.byobu/keybindings.tmux).
You will find these lines :
bind-key -n M-Left previous-window
bind-key -n M-Right next-window
M is for Meta, aka the ALT key. Example. Change the lines for :
bind-key -n C-Left previous-window
bind-key -n C-Right next-window
C for Ctrl key (and S for Shift key).
Save, quit, press F5 to reload profile.
Refs : Bybobu doc, Byobu-and-mc, keybindings-in-byobu-using-tmux-backend, tmux
If the Function and other keys are bound to some other program, they won't work. Also, on some OS e.g CentOS, the keys (and their combinations) cease to function.
My solution is to use the bind-key which is Ctrl a to perform different actions. Here are a list of few important shortcuts with bind-key
Help
$ Ctrl-a ?
Create new window
$ Ctrl-a c
Horizontal split
$ Ctrl-a | #Shift + \ = |
Vertical split
$ Ctrl-a %
Rename windows
$ Ctrl-a ,
Move window
$ Ctrl-a .
To move between splits (tested on RHEL)
$ Ctrl-a (arrow-keys)
NOTE: Tested on RHEL/CentOS
The diff command, even using git option, includes path prefixes commonly used on DCS:
--- a/file.ext
+++ b/file.ext
So applying such patches you should need to using -p1 instead of -p0.
Is there any way to generate clean patched from Mercurial?
Mercurial won't emit -p0 patches. As #Ringdig points out, they're very seldom what you want.
You could adapt the see script given in this answer : transforming patch strip level to remove the first directory instead of adding it.
Something like this should work (untested) :
sed \
-e 's!^--- a/!--- !' \
-e 's!^+++ b/!+++ !' \
< p1.patch \
> p0.patch
Assuming your "p1 patch" is in a file named p1.patch, the output will be in p0.patch
I'm trying to write a wrapper for qrsh, the Oracle Grid Engine equivalent to rsh, and am having trouble identifying the command given to it. Consider the following example:
qrsh -cwd -V -now n -b y -N cvs -verbose -q some.q -p -98 cvs -Q log -N -S -d2012-04-09 14:02:08 GMT<2012-04-11 21:53:41 GMT -b
The command in this case starts from cvs. My wrapper needs to be general purpose so I can't look specifically for cvs. Any ideas on how to identify it? One thought is to look for executable commands starting from the end backwards, which will work in this case but won't be robust as "cvs" could appear in an option to itself. The only robust option that I can come up with is to fully implement the qrsh option parser but I'm not thrilled about it since it will need to be updated with qrsh updates and is complicated.
One option is to set QRSH_WRAPPER to echo and run qrsh once. However, this then requires two jobs to be issued instead of one, adding latency and wasting a slot.