I run
kubectl edit deployment
to change the version of one of my pods (this commands opens a temp file in my text editor and then I usually edit and close this temp file) and even before I close this temp file in my text editor I can see the following note in my bash.
Edit cancelled, no changes made.
It was OK before I installed fish and I tried to switch to bash but it doesn't help either.
How can I fix it?
Things like this are most likely caused by it opening an editor that forks off instead of staying.
That means you'll want to set $EDITOR to an editor that does wait. E.g. nano, vim or emacs should work, and e.g. if you use sublime text you'll have to use subl -w to explicitly tell it to wait.
It's not quite clear which shell you're running at the moment. If it's bash, run export EDITOR="subl -w", in fish run set -gx EDITOR subl -w (or "subl -w" if you use fish < 3.0).
A refinement to the ample answer provided by #faho.
An approach with the $EDITOR variable achieves the goal but changes the default command-line editor. This might affect other programs dependent on this setting (e.g. crontab, edquota).
It'd be better to rely on the $KUBE_EDITOR variable. For example for the one-time use you might try:
KUBE_EDITOR="nano" kubectl edit deploy/hello-world
(Please see Editing Resources)
With vim, when you try to save it saves an edited copy which is specified in /tmp/ path, along with the error message, when you quit the editor.
This is equivalent to using get the resource, edit it in text editor, and then apply the resource with the updated version:
kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
vim /tmp/nginx.yaml
kubectl apply -f /tmp/nginx.yaml
deployment.apps/my-nginx configured
then remove the file
rm /tmp/nginx.yaml
So basically use apply on the file saved in the /tmp/<file.yaml>
This issue may also happen when changes made by you are not picked by an kubectl eg. because of incorrect YAML.
Please make other change that you are sure of.
After saving check if still getting the same problem
Example issue replication:
the spec.selector.app: xxx" is invalid as it is duplicated;
the last one will remain; the first will be ignored.
so if you just added the first one - it no changes will be made.
spec:
clusterIP: 10.152.183.151
clusterIPs:
- 10.152.183.151
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: xxx
app: rng
Related
Hi I am having a problem with setting alias in mac after I start the screen command, I have alias for working with git, like
commit=git commit
they work as I expect when I start my terminal (iTerm2), but then sometimes I use screen to have simultaneous instances in remotes servers and virtual machines I work with. After this the alias disappear(command not found).
Does anyone know why or how solve it?
To make the alias work, you must use the alias command. For example, to create an alias in Bash you do:
$ alias commit="git commit"
This works temporarily ie.: in your current shell. In order to make it "stick", you must put it in your ~/.bashrc. That will make it be sourced to all instances of Bash you'll invoke during your terminal session.
When you start screen, it starts a separate Bash too, so you'll be covered.
You write something about VMs. If you need this alias to work there, you must make ~/.bashrc on these VMs to have the same aliases. But that's the other story. You should already know how to achieve what you want.
You need to make sure your aliases are defined in ~/.bashrc to ensure they get included in all logins. You can test this out: edit your ~/.bashrc to include this line:
echo "bashrc"
And then edit your ~/.bash_profile to include this line:
echo "bash_profile"
You'll see when you start screen that only "bashrc" is displayed.
See this question for much more detail on the subject.
I've been having proxy issues with npm and git.
Looks like the proxy is set as an environment variable in Bash
If I check with
env | grep -i proxy
I can see the proxy settings.
I can unset the proxy with
unset http_proxy
unset https_proxy
unset ftp_proxy
This only appears to last as long as the terminal window is open.
If I close and reopen the terminal the proxy is back again.
Is is it possible to delete the proxies when I'm out of office and then recreate them when I need them?
You first need to find out where these environment variables are defined in your case.
Typically they are set in the ~/.bash_profile file (Mac OS X) or ~/.bashrc file (Linux). Since you tagged the question with osx, I assume that in your case they are set in ~/.bash_profile.
Please check whether this file defines these variables. You can either do that using Finder (you need to show hidden files), or from a terminal by running cat ~/.bash_profile. Feel free to post the output in your question.
There's a small chance that they are defined in a system-wide file like /etc/bashrc. Feel free to check that file as well.
If you need to define/undefine the variables on a regular basis, I recommend that you create a script for each defining/undefining and place it in a location like ~/bin. Then you can simply call the respective script when you open a new shell.
I handle this through the Bash-it framework. In my fork, I have added a proxy plugin that provides functions for this. Feel free to give this a try: https://github.com/nwinkler/bash-it/blob/master/plugins/available/proxy.plugin.bash
To answer your other question: There's no easy way to automatically detect and change the presence of a proxy from a shell window.
I have Vim on Windows server 2012, and when I start it from the start menu everything works fine. However, when I start it from the command line it take 5 seconds and uses 700MB memory. Even when its not opening a file. There is something weird going on, and I was wondering if there are any ways to debug it/figure out what is causing this? Thanks, Eric.
EDIT:
Here is the result of vim --startuptime outputfile (abbreviated):
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.000 000.000: --- VIM STARTING ---
...
016.000 016.000: parsing arguments
016.000 000.000: expanding arguments
4794.000 4778.000: shell init
4794.000 000.000: Termcap init
...
4825.000 000.000: setting raw mode
8768.000 3943.000: start termcap
8768.000 000.000: clearing screen
8783.000 000.000: --- VIM STARTED ---
You could use Sysinternals' Process Explorer to check if any of the processes are starting child processes or if there is any difference in the environmental variables.
Also, Sysinternals' Procmon would allow you to check what registry entries, files, etc does any application use (filter by command name includes vim), but probably you will find the differences just with Process Explorer.
Sysinternals was a company that created some nice apps for Windows and Microsoft bought it some years ago. You can access the last version of any of their apps on http://live.sysinternals.com
Excerpt from Vim FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual runtime
files or any plugin that is distributed with Vim or whether it is a
simple side effect of any configuration option from your .vimrc or
.gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your viminfo
file (-i NONE), without reading any configuration file (-u NONE for not
reading .vimrc file and -U NONE for not reading a .gvimrc file) or even
plugin.
In this invocation, try to reproduce your problem. If the error
persists, the chance is good you've found a bug in Vim (see also
Question 2.6. faq-2.6)
If the error does not occur when starting Vim this way, then the problem
is either related to some plugin of yours or some setting in one of your
local setup files. You need to find out, what triggers the error, you
try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load any
plugins. If the error occurs this time, the error is possibly caused by
some configuration option inside your .vimrc file. Depending on the
length of your vimrc file, it can be quite hard to trace the origin
within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half of
your .vimrc. If it doesn't happen, the problematic setting must be in
the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and move
your way along, until you find the problematic option.
It also mentions how to create a log file:
You can also use the -V command line argument to get more debug
information to analyze the problem:
$ vim -V2logfile
You can increase the value passed to the -V argument to get more debug
information. By also specifying a logfile name, this makes sure, the
debug messages don't appear on the screen and won't disturb you when
trying to reproduce the problem.
first time poster.
This came up in conversation at work this week...
Is there a way, when you connect to git remotely that you can get display current working directory/current git repo/branch in your terminal prompt?
Apparently, there are linux/vim scripts that exist for linux users, and I'd like to add this sort of shell script to my profile.
Currently I'm using some info from this page http://sos.blog-city.com/mac_os_x__bash_customize_your_terminal_prompt_a_little_color.htm to address some of this info locally.
Thanks in advance.
Get a copy of the git completion script. You can get this from git itself, or if you have a Linux box handy you could even just copy it from there (it'll probably be /etc/bash_completion.d/git). Then, arrange for this to get "sourced" by bash. You can do this by adding something like this to your .bashrc:
. /usr/local/git-completion
(assuming you named the file /usr/local/git-completion on your Mac).
Finally, you'll want to adjust your prompt. Also in your .bashrc, add something like:
export PS1='[\w$(__git_ps1 "|%s")]\$ '
Here's a blog post (not by me) that talks about this (and some other related stuff) in more detail: http://blog.bitfluent.com/post/27983389/git-utilities-you-cant-live-without
OK, I experimented with this after you pointed me in the right direction, my google searches got more refined results.
A lot of people point to the post you shared with me, like here: https://superuser.com/questions/31744/how-to-get-git-completion-bash-to-work-on-mac-os-x but I found some other jewels like these, which I didn't use but were informative: jeetworks.org/node/10 , jonmaddox.com/2008/03/13/show-your-git-branch-name-in-your-prompt/ .
I needed some different guidance on installing git.completion because I use homebrew which I found here: https://github.com/bobthecow/git-flow-completion/wiki/Install-Bash-git-completion which covers several ways to install it.
Finally, my bash/terminal has been a bit pokey so I upgraded to the latest bash with these instructions before I meshed with any of this: milkbox.net/brace_completion_snow_leopard_upgrading_bash/ and got some great speed improvement.
I ended up having to rebuild my profile script very carefully but with trail and error (because of differences between Bash 3 and 4, and some syntax errors)- now it looks great, and does the job.
Thanks again.
Sorry about above the security restraints of the site, restrict me (since I'm a newb) to 2 links to combat spam.
You just need 2 steps to do it.
Step.1:
Open ~/.bash_profile in your favorite editor and add the following content to the bottom.
For me it is like
emacs ~/.bash_profile
Step.2:
Add the following content to the bottom.
function git_branch {
git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'}
export PS1='\h:\w$(git_branch) \u\$'
Done!
P.s:
If you want your terminal colorful, try the following content.
export PS1 = '\[\e[1;39m\]\h:\w\[\e[01;39m\]$(git_branch) \[\e[01;39m\]$ \[\e[0m\]'
Another option to get git branch/status info in your shell prompt is to use powerline-shell.
You can see what this looks like in this screenshot:
The magenta/green bar is the current branch name. Its color indicates whether the working directory is clean. There are also markers that appear when there are untracked files, or when there are commits to be pulled-from/pushed-to the upstream remote.
Powerline-shell is compatible with bash, zsh, and fish.
I'm trying to use MacVim as a default editor (on my Mac, obviously). I'd like to have MacVim to edit commit messages when I hg ci. Unfortunately when I do so (either by setting EDITOR=mvim or alias vi='mvim') MacVim pops up with an empty message (i.e. none of the boilerplate in the bottom half), and when I save that commit message I get the error "abort: empty commit message".
Is there a way to use MacVim (presumably via mvim) to edit the commit messages when checking in changes with Mercurial?
Thank you for reading, and I look forward to reading the answers.
Brian
Set EDITOR='mvim -f', per the tip from the FAQ for making it work with Git:
How can I use MacVim to edit Git commit messages?
Add the following line to the file ~/.profile:
export EDITOR='mvim -f -c "au VimLeave * !open -a Terminal"'
The last part ensures that Terminal gets focus again after closing the commit message. (Note that you need to put the mvim script in your path for this to work.)
If you have multiple SCMs on a machine (e.g. you have to work with Subversion and Mercurial, as I do), you can differentiate the editor by using HGEDITOR instead of the more generic EDITOR env. For example, I have the following environment variables set up:
export HGEDITOR='mvim -f -c "au VimLeave * !open -a Terminal"'
export SVN_EDITOR='mvim -f -c "au VimLeave * !open -a Terminal"'
In this case it's sort of pointless because the configuration is the same, but this is just to illustrate the point.
That also of course raises the point that you can set EDITOR and get that as the default for your various applications that use that, then override it with an application-specific variable for those apps that need something different. I tend to use the app-specific variables just to be... thorough, I guess (some might call it something else :).