I used to call this command to popup a simple balloon message when gradle build is complete. It had worked fine on cygwin's bash.
notifu /p "Gradle build complete" /m "Now you can take a look at the results" /d 0 > /dev/null
However, after switching to git's bash, the windows-style command line options such as /p /m have become resolved as cygwin drive letters: p:/ m:/. Obviously, notifu couldn't accept them.
Could anybody please tell me why it had been perfectly working on cygwin's bash, but not on git-bash now?
#astrounaut use like this in git-bash:
notifu //p "title" //m "message.."
I used previously (in here) or seen (in that answer) the escape character '^' for Cygwin msys bash.
Try a ^ in front of the /, in order to convince Cygwin that /p isn't a drive path:
notifu ^/p "Gradle build complete" ^/m "Now you can take a look at the results" ^/d 0 > /dev/null
Related
I can use #if exist to test a file does exist or not, but did not find the document via Google. For example, in my makefile for nmake ;
clean:
#if exist $(BIN_DIR) rmdir /S /Q $(BIN_DIR)
#if exist $(OBJ_DIR) rmdir /S /Q $(OBJ_DIR)
You won't find any documentation regarding "#if exist" in nmake documentation. These are plain shell commands.
So just open a cmd window and at the prompt enter "help if". By the way the "#" sign suppresses the echo in a shell script.
Thats's why most of .bat scripts start with "#echo off".
You can find nmake documentation here (I'm surprised you did not find it):
VS 2012:
http://msdn.microsoft.com/en-us/library/dd9y37ha.aspx
VS 2010:
http://msdn.microsoft.com/en-us/library/dd9y37ha(v=vs.100).aspx
VS 2008:
http://msdn.microsoft.com/en-us/library/dd9y37ha(v=vs.90).aspx
Earlier versions are also available but nmake has not changed much.
Variables that are accessed using the $(VARNAME) syntax are either environment variables, or variables declared inside the makefile itself.
Here's a really simple makefile that declares a variable, and the single rule (ALL) ouputs the PATH (from the environment) then the locally-declared variable.
MY_VAR=12345
ALL:
#echo $(PATH) $(MY_VAR)
I tried to start gvim using start command like this
start gvim.exe
But it doesn't work for gvim, although it does work for firefox.exe. My questions are-
How can I start gvim from command prompt?
Why start command doesn't work for gvim.exe?
Are there any additional parameter that I can use when starting gvim from command prompt?
Completely different, so a separate answer:
Actually, -- I just remembered -- Vim isn't normally added to the path variable, it's run through .bat files in C:\Windows.
From another answer on StackOverflow:
When you install gVim: Please make sure Create .bat files for
command line use is checked. It'll create several .bat files in
C:\Windows\:
C:\>cd %windir%
C:\WINDOWS>dir /b *.bat
evim.bat
gview.bat
gvim.bat
gvimdiff.bat
view.bat
vim.bat
vimdiff.bat
vimtutor.bat
This is because gvim.exe is not in your PATH list. If you know which directory gvim.exe resides, add this directory to your PATH list. This can be done by typing the following in an Explorer address bar:
Control Panel\System and Security\System
Then press Advanced system setings, then Environment Variables. The PATH is a list of directories separated by a ;.
Try typing just "gvim" instead of "start gvim.exe". That works for me. Vim isn't in my path environment variable.
I'm trying to execute the program as followed.
./chExt1.sh cpp test.CPP
This should rename test.CPP to test.cpp but I don't even think this script is executing at all.
I am consistently getting this "command not found error".
The script is below :
#!/bin/sh
newExtension=$1;
oldFile=$2;
firstPart=`echo $oldFile | sed 's/\(.*\)\..*/\1/'`
newName="$firstPart.$newExtension";
#echo $oldFile
#echo $newName
mv "$oldFile" "$newName"
#echo "$oldFile"
#echo "$firstPart"
#echo "$newName"
I finally fixed the issue. Something went horribly wrong when I FTP'd the text file which contained the script and then just transferred it inside of a .sh in linux. I wrote in from scratch in emacs and that cleared everything up.
Based on your comment, do this in vi to remove the extra control characters. I have had this problem before when editing files in gedit or when editing in Windows and then using on a Unix/Linux machine.
To remove the ^M characters at the end of all lines in vi, use:
:%s/^V^M//g
The ^v is a CtrlV character and ^m is a CtrlM. When you type this, it will look like this:
:%s/^M//g
In UNIX, you can escape a control character by preceeding it with a CtrlV. The :%s is a basic search and replace command in vi. It tells vi to replace the regular expression between the first and second slashes (^M) with the text between the second and third slashes (nothing in this case). The g at the end directs vi to search and replace globally (all occurrences).
Source
I am not able to run gvim from cygwin. When I try to open a new file with :
gvim filename
gvim opens a file with 'No name' and displays error as :
Error detected while processing command line
E492: Not editor command: C:\cygwin\home\chandan\l
Press enter or type command to continue
More problematic is that I can't open existing file in the path
>which gvim shows /usr/bin/gvim
I have put alias gvim=/cygdrive/c/Program\Files\(x86\)/Vim/vim73/gvim.exe still
I wrote cyg-wrapper.sh for this sole purpose.
It supports:
symbolic links
options that must not be interpreted as pathnames (see -c with gvim, or any flags starting with a minus sign).
In other words, it enables us to type:
gvim /etc/profile -c /PS1 -c "echo 'correctly opened'"
# or even:
cd ~/tmp ; ln -s ~/bin/cyg-wrapper.sh
gvim -d http://hermitte.free.fr/cygwin/cyg-wrapper.sh cyg-wrapper.sh
explorer -e
explorer "$vim"
explorer http://hermitte.free.fr/
Note: I use the following function in my .profile to run gvim with cyg-wrapper.sh
gvim() {
opt=''
if [ `expr "$*" : '.*tex\>'` -gt 0 ] ; then
opt='--servername LATEX '
fi
cyg-wrapper.sh "C:/Progra~1/Edition/vim/vim73/gvim.exe" --binary-opt=-c,--cmd,-T,-t,--servername,--remote-send,--remote-expr --cyg-verbose --fork=2 $opt "$#"
}
EDIT: Currently (Sept 26 2014, using Vim 7.4), Windows gVim uses C:\Windows\gvim.bat to launch gVim from the command line. Replacing the gvim.exe path in the gvim() function with this script allows launching gvim without changing the path to match the current Vim version (which may actually be in Progra~2); however, it appears to also open a superfluous cmd.exe window.
Found this thread, I find the answer from jens unacceptable. We're not asking to be told not to do it. I didn't like the other answers either there was always some quirk, like settings not used or an extra command line window popping up. I Did some digging and this works for me. No extra command line box for nothing and it uses my proper gvim settings.
alias gvim='HOME=/cygdrive/p/ cygstart /cygdrive/c/Program\ Files\ \(x86\)/Vim/vim74/gvim.exe'
You simply need to alter the HOME to your own. To find out what to put there run gvim from windows then put in ":echo $HOME" and hit enter in my case it shows P:\ so that translates to /cygdrive/p/
Also if your gvim.exe is in a different directory/version you'll need to adjust.
Now when I type 'gvim script.sh' at a cygwin command prompt it launches gvim with the file, all nice and neat!
UPDATE
I found a slightly better way to do this. Using the alias was tying up my session that I ran the gvim from, I wanted it to launch as a separate process, using "gvim &" is inelegant as it lists job number when launching and displays a "done" line when completed. I'm too fussy so I figured out how to get that all tidy by using a function.
Just add this to your .bash_functions file, it builds on the previous section regarding home directory and backslash use.
gvim() {
ORIGHOME=$HOME
HOME=/cygdrive/p/
/cygdrive/c/Program\ Files\ \(x86\)/Vim/vim74/gvim.exe $1 & disown
HOME=$ORIGHOME
} 2>/dev/null
UPDATE 2 for babun users!
Ok since having wrestled with this originally I have ended up scrapping the original cygwin install in favor of babun which seems to be a less troublesome setup for those wanting linux functionality in windows without a full blown virtual. Of course my gvim launch script broke, and I had to do the following in my .zshrc file (babun uses zsh, at first I resisted and switched it to bash but then relented as I figured they must have reason, and they did, I like it)
gvim() {
OLD_HOME=$HOME
OLD_VIMRUNTIME=$VIMRUNTIME
export HOME=/cygdrive/c/Users/gmitchell/
export VIMRUNTIME="C:\Program Files (x86)\VIM\vim74"
TARGET=$(cygpath -w $1)
(/cygdrive/c/Program\ Files\ \(x86\)/Vim/vim74/gvim.exe $TARGET &)
export HOME=$OLD_HOME
export VIMRUNTIME=$OLD_VIMRUNTIME
}
*Note: the surrounding curved braces ( ) stops the job id from messing up your clean shell, and you no longer need the "disown"
P.S. The only remaining annoyance with this now is that you cannot "exit" the babun shell until all gvim instances you've launched are closed. Maybe someone can figure that own out. I've tried. When you type exit it just hangs there until you've exited all gvims.
Do yourself a favor, don't attempt to run a windows gvim from cygwin. The set of environment variables is likely completely different, and the pain of backslash directory separators, blanks in filenames, inability to understand /cygwin paths makes this an exercise in futility.
Then, what? Install the cygwin version of gvim and forget about all these problems.
Here is all you need to do:
alias gvim="run.exe /cygdrive/c/Programming/Tools/Vim/vim74/gvim.exe"
Works also with Notepad++, like so:
alias np="run.exe /cygdrive/c/Programming/Tools/Notepad++/notepad++.exe"
I have the same problem
because of the $SHELL var
so, I simple do like this
alias gvim='cmd /c "set SHELL=cmd & start gvim"'
It works for me, may be this will be help you too.
and maybe you want use the same alias for vim.
I put the following function in my .bashrc:
function gvim
{
GVIM_CMD=/cygdrive/c/path/to/gVimPortable.exe
if [[ -z "$1" ]]
then
$GVIM_CMD
else
$GVIM_CMD `cygpath -w $1`
fi
}
This allows me to launch gVim from anywhere.
It works fine for files with spaces, too...
This is a take off on low351's answer. I was unhappy with leaving HOME changed in the cygwin terminal, since I use that locally for a cygwin HOME, not my windows home. But gvim is all setup using Windows HOME. I added this to my .zshrc:
# run windows gvim from command line
gvim() {
local OLD_HOME=$HOME
HOME=/cygdrive/c/Users/jason/
local TARGET=$(cygpath -w $1)
/cygdrive/c/Program\ Files\ \(x86\)/Vim/vim74/gvim.exe $TARGET & disown
HOME=$OLD_HOME
} 2>/dev/null
really, just storing and restoring HOME. Being local, OLD_HOME goes away when the function returns, so it doesn't pollute the environment. If you're editing a cygwin file, running it through cygpath -w will make it a file path that windows gvim understands. It also lets you use window paths (e.g. C:/tmp/foo.txt) but w/ unix '/' separators, so you can dispense with /cygdrive/c. I believe this is all compatible w/ bash. This gives the following output:
> gvim
[2] 5060
>
It seems like the main problem is the HOME and VIM variables which are appropriate to the cygwin environment get exported when running Windows gvim, causing problems because Windows gvim knows nothing of cygwin. This fixes it:
alias gvim='env -u HOME -u VIM /cygdrive/c/Program\ Files\ \(x86\)/Vim/vim74/gvim.exe'
I have Windows gvim set as the default application (in Windows) for many filetypes, so Windows gvim frequently gets opened via the open alias. This fixes that use case:
alias open='env -u HOME -u VIM cygstart'
I just renamed gvim.bat which comes with the standard Win32 vim installation to gvim and put it into /usr/bin.
I am also sharing settings beetween Win32 GVim and Cygwin VIM referring to this article:
http://vim.wikia.com/wiki/Synchronize_configuration_to_many_computers
This way i can have both Vim and Win32 Gvim running with the same plugins and settings.
Since I've tried all of these and had issues I'll show what I'm using. I wrote it in ruby and it handles everything I throw at it (files, directories, or nothing) without any errors/popups/etc.
I saved it as gvim in ~/Dropbox/bin/cygwin/ (which is in my PATH)
#!/usr/bin/env ruby
args=''
filepath=''
arg=ARGV[0]
if arg
if File.exist? arg
if File.file? arg
args+="--remote-tab-silent "
end
filepath=`cygpath -w '#{arg}'`.strip
filepath="'#{filepath}'"
end
else
end
exe="'/c/Program\ Files\ \(x86\)/vim/vim73/gvim.exe' #{args} #{filepath}"
spawn exe
Here's the script I use for ~/bin/gvim. It runs it as if I called gvim FOO from the "Run" dialog (thanks to the batch file being invoked by explorer.exe). Can't play too nicely with the command line, but a self-deleting batch file comes to the rescue.
#!/bin/bash
TEMPFILE_NAME=gvim-`date +%s`-${RANDOM}.bat
TEMPFILE=$TMP/$TEMPFILE_NAME
TEMPFILE_W=`cygpath --windows --absolute --long-name "$TEMPFILE"`
TARGET=
if [ "$1" = "" ] ; then
TARGET=`cygpath --windows --absolute --long-name "."`
else
TARGET=`cygpath --windows --absolute --long-name "$#" | tr '\n' ' '`
fi
WIN_GVIM=`where gvim.exe | tr -d '\r\n'`
WIN_GVIM=`cygpath "$WIN_GVIM" --windows --absolute --long-name`
unix2dos > $TEMPFILE << EOF
start "gvim" "$WIN_GVIM" $TARGET
DEL %~f0
EOF
chmod +x $TEMPFILE
explorer.exe "$TEMPFILE_W"
Special thanks to this answer for the explorer.exe technique.
I'm attempting to use the :!<cmd> format in vim to execute an external command and put the results in the buffer. If I type :!, path completion is possible and I can complete the path right up to the command I want to execute. This automatically escapes spaces like so:
:!c:\Program\ Files\ (x86)\Microsoft\ Visual\ Studio\ 9.0\Common7\IDE\TF.exe
When I hit enter, I get:
'c:\Program\' is not recognized as an internal or external command
Which I suspect means that vim has not escaped the spaces properly when passing the command to cmd.exe. I've tried all sorts of escaping combinations to make this work but to no avail. The only way I've found to do this is to work out what the DOS8.3 filename is and use that instead of the long path name. However, I don't like this approach since it's going to make my script less portable. Does anyone know if this can be done, or is it a bug in vim?
If you have quoted arguments, not just the exe path, then you may need to do some fancy quoting, like below. The main problem is not the exe path itself, but the arguments. I found this webpage helpful for similar problems myself:
http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx
Not sure offhand and don't have time to check, but if you have a quoted argument then sample below may be closer to what you need:
silent! exe 'r!"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe" history /followbranches \^"#\^"'
Also, I wonder whether the quotes around the path may need special treatment since they are around only a portion of the full command. In any case, the quotes \^" work for main quotes in command line and ^" for quotes embedded in other quotes. I have in the past found it useful to experiment with the command at a windows prompt, remembering to test it with the way Vim prepares it, which is with your command prepended by c:\windows\sys32\cmd.exe .
On second thought, I think when I was working with similar problem I never did get to point of solving command with both quoted arguments and quoted exe-path-with-spaces in same command. I expect there's way to do it, but I instead just created a soft link to the exe in path with no spaces. E.g.:
mklink c:\users\myname\myexe c:\program files(x86)\myapp\myexe.exe
After having done that there's no need to quote the exe command itself and quoting the argument with \^" worked fine. I am of course curious about how to quote an exe-with-spaces that also has quoted arguments.
EDIT: I think I found way around my problem with quoting, don't have VS to test with your exact command but here's what I think may work from command line:
cmd /k ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe" history /followbranches ^"#^""
If that works for you from command line then I think only issue is getting Vim to include the /k switch. (Also, there could be issue with Windows command line "throwing away" the /followbranch switch, because of the forward slash, but maybe not.)
EDIT2: I think the trick for doing it from Vim is just to include the 'cmd /k' as part of the command you're running. You end up with several levels of shells opening, but I don't think that's a problem. For an example, here's on that runs from Vim, with (1) spaces in exe path, (2) quoted argument (the (message .. ) ) and even (3) a quote within a quoted argument (\^"hi\^"). This command opens an Emacs instance and has Emacs print message "hi":
!cmd /k ""c:\program files (x86)\emacs\emacs\bin\emacs.exe" --eval ^"(message \^"hi\^")^""
And yet one more EDIT: Including your own 'cmd /k' does create problems, I think, if you're trying not just to execute the external command, but to read its output back into the Vim buffer. In that case you could redirect the output to a file in the user's home directory and the use :read to insert into the buffer. If there's some way to get Vim's own cmd to use k switch then this would be unnecessary, but if not then at least this provides good workaround.
Enclose the full pathname of the executable in double quotation marks. Do not escape spaces in the pathname.
In your example, some of the backslashes were added to escape spaces, and others are a part of the pathname. You did not provide the original pathname, but I can guess at it. If I guessed right, the command that will work is:
:!"c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe"
This works equally well in a script. The equivalent script command is:
silent execute '!"c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe"'
I have tested this in Vim 7.3.346 x86, installed on Windows 7 Pro SP1 x64.
%0 (batch name) %1 (1st parameter) %2 (2nd parameter)
example:
C:\CSW>MyBatchFile.bat "C:\Program files" "C:\CSW\My File.txt"
Not sure if this works with vim but it does work with bash in windows.
You just need to call by adding double quote in it.
I dont have enough idea about Vim script. but while running in command prompt if you will give the complete exe path having space then it will give error like
C:>c:\Program Files\Internet Explorer\iexplore.exe
'c:\Program' is not recognized as an internal or external command,
operable program or batch file.
But It will work if you will surrounded with double qoute.
C:>"c:\Program Files\Internet Explorer\iexplore.exe"
C:>