Compiling and Running C code in notepad++ - c

I have a problem with compiling and running C codes in notepad++.
I am using the nppexec plugin and wrote the following in the script section after pressing F6:
C:\MinGW\bin\gcc.exe -g "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART).exe"
$(CURRENT_DIRECTORY)\$(NAME_PART).exe
After pressing OK, I get the following on the console:
C:\MinGW\bin\gcc.exe -g "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.C" -o "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe"
Process started >>>
<<< Process finished. (Exit code 0)
D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe
Process started >>>
Here, substitution.c is my program to be run. The problem is that the gcc part is working fine but I am not able to execute the program from here as there is no response.
As you see, it just says process started and after that nothing. No response to a key being pressed, it just accepts everything like a text editor.
If I go to the working directory and execute the program from there (double clicking the exe file) then it seems to run perfectly fine. The problem seems to be in my script or the plugin.
Please, can anyone find out what is wrong with my compiling and running script?

In addition to #paxdiablo 's answer, you may also find useful the following NppExec script for single file projects:
npp_save
cd "$(CURRENT_DIRECTORY)"
cmd /c del "$(NAME_PART)".o "$(NAME_PART)".exe *.o
C:\MinGW\bin\gcc.exe -g3 -std=c89 -pedantic -Wall -Wextra -Wno-nonnull "$(NAME_PART)".c -o "$(NAME_PART)".exe
npp_run "$(NAME_PART)".exe
The 1st line saves the document that is currently active inside notepad++.
The 2nd line ensures your current directory is the one of the active document. This let you refraining from using the "$(CURRENT_DIRECTORY)" variable in the rest of the lines.
The 3rd line removes any executables and object-file leftovers from previous successful compilations. Removing the last executable is a nice idea, because if you don't then the last line will cause your .exe produced by the last compilation to be run anyway, even if your current compilation fails. A failed compilation does not produce an .exe, so normally you don't want NppExec to run the previous .exe. Removing the previously produced object-file is optional, but it does ensure that it will not affect fresh compilations (it makes more sense in multi-file projects, as an alternative to the touch command-line tool).
The 4th line compiles the active document. Feel free to modify gcc's options according to your needs. If you add C:\MinGW\bin into the Windows PATH environment variable, and assuming you are using only one gcc installation on your system, then you can skip the absolute path, and write just gcc instead.
The last line executes the produced executable. The npp_run command tells NppExec to launch a new command-prompt window, and run your program in it (unless it is a WIN32 GUI program). I personally find it more convenient compared to the NppExec console embed in notepad++. It looks more natural and it also avoids some I/O redirection problems of the NppExec console.
However, if your program is a console app that does not interact with the user say via a loop, then this approach will cause the launched command-prompt window to close immediately after your program terminates, not giving you the chance to inspect its output. In that case you should have you program waiting for a key to be pressed by the user just before its termination. A quick-and-dirty way is to put a system("pause"); right before your main() function's return and/or exit() statements (it is much better though to write a simple cross-platform function or macro for this).
You may experiment with the above script by typing it in F6's <temporary script> and save it permanently for general use when you are happy with its behavior.
On a side note, you may also find it useful to have a look at this post, where I'm trying to explain how to setup NppExec so it jumps to the appropriate line in the source code, by double-clicking on any error gcc spits in the NppExec console during compilation.

Related

How to step into a function with gdb ddebugger when that function is located in another c program that is located in another folder?

I have an existing 'c' code written by a researcher and I want to debug it. The project is compiled using MAkE. I am trying to debug using gdb debugger.
suppose 'A' folder contains 'myproject.c', 'myproject', MAKEFILE and some subfolders B,C,D etc.
Now I debug the file gdb myproject. I created breakpoint at a function1. This function 1 is located in a file x.c in folder B. When I pass step command, it is executing the whole function but I want to see it line by line.
When I pass step command, it is executing the whole function but I want to see it line by line.
This means that x.c is compiled without debug info (without -g flag).
The Make File already has -g flag included
What the Makefile has is somewhat irrelevant. What matters is the command line that make constructs to compile x.c.
Run make clean all. That should (assuming proper Makefile) rebuild the entire program, recompiling x.c. Now look at the command line used to compile x.c. It will not have -g option. You'll need to modify the Makefile so it does.

How come when I try to compile my C program by making a file named for the program it creates an application for it?

I once tried to compile a C program I made that was for a chess game (thanks to YouTube's Bluefever Software for the tutorial), but when I went to compile the program, I executed this line of code:
C:\TDM-GCC-64\>gcc Chess/chess.c Chess/init.c -o chess
The compiling worked (there were no syntax errors or anything), but when I got to my file directory, I saw this (circled in blue):
An unexpected application (but there were no viruses!):
How did this happen? It may had something to do with the line I was compiling, but what is the "intel" behind this?
It is normal for the compiler to generate an application!
What is surprising is the location for the executable, it should have been generated in the parent directory:
C:\TDM-GCC-64\> gcc Chess/chess.c Chess/init.c -o chess
The explanation is interesting:
You are using the Windows operating system, where the filenames are case insensitive.
You instructed gcc to generate the executable into chess, but this is the name of the Chess directory. In this case, gcc generates the executable in the named directory and gives it a name that is the basename of the first source file chess.c -> chess.
Furthermore, the application name really is chess.exe in Windows, but the default setting for the file manager is to not display file extensions. This is a very unfortunate choice. I suggest you change this setting in the Windows/File Explorer Options window to always show file extensions. This will allow you to distinguish chess.c, chess.exe and chess.h more easily.
You have a Makefile in the Chess directory, you should use the make command to build the executable:
C:\TDM-GCC-64\> make -C Chess
Or simply cd to the Chess subdirectory and type:
C:\TDM-GCC-64\Chess> make
That's the file you told the compiler to make.
The -o option to gcc is the output file. In this case, you told it to create an executable file named chess. And that's exactly what was created.
The compiler is automatically creating an executable file while compiling.

C - program compiling, but unable to provide arguments

I'm on a Mac and in terminal I'm compiling my program
gcc -Wall -g -o example example.c
it compiles (there are no errors), but when I try to provide command line arguments
example 5 hello how are you
terminal responds with "-bash: example: command not found"
how am supposed to provide the arguments I want to provide after compiling?
Run it like this with path:
./example 5 hello how are you
Unless the directory where the example binary is part of the PATH variable, what you have won't work even if the binary you are running is in the current directory.
It is not a compilation issue, but an issue with your shell. The current directory is not in your PATH (look with echo $PATH and use which to find out how the shell uses it for some particular program, e.g. which gcc).
I suggest testing your program with an explicit file path for the program like
./example 5 hello how are you
You could perhaps edit your ~/.bashrc to add . at the end of your PATH. There are pro and conses (in particular some possible security issues if your current directory happens to be sometimes a "malicious" one like perhaps /tmp might be : bad guys might put there a gcc which is a symlink to /bin/rm so you need to add . at the end of your PATH if you do).
Don't forget to learn how to use a debugger (like gdb). This skill is essential when coding in C (or in C++). Perhaps consider also upgrading your gcc (Apple don"t like much its current GPLv3 license so don't distribute the recent one; try just gcc -v and notice that the latest released GCC is today 4.8.1).
./example 5 Hello how are you is the syntax you're looking for.
This article lends a good explanation as to why this is important.
Basically, when you hit Enter, the shell checks to see if the first set of characters is an absolute path. If it's not, it checks the PATH variable to find executables with the name of the command you are trying to run. If it's found, it will be run, but otherwise it will crash and burn and you will become very sad.

Compiling Programs from Within Emacs?

What is the best way to compile programs inside emacs? I am currently opening a separate buffer with C-x 3 and running eshell inside it using M-x eshell then invoking either make or clang directly; most of the time I do have a Makefile set up.
Is there any advantage with running the compilation process using M-x compile vs running make inside eshell? Any other ways to do it and what are the advantages/disadvantages of those?
The easiest way to do this is to use the Emacs built-in compile command. M-x compile should do you fine. You can then edit the command that will be run (by default make -k) and then hit return to run the compilation. Emacs will then parse the output and if it finds any errors they will link to the source files so you can open them in a buffer.
Positives about it are:
Parsing of the output buffer
Memorisation of the compile command between invocations
Compilation output is shown in a non-selected buffer, you can quickly edit the file you were working on and fix any silly errors.
M-n and M-p scroll by error messages
Most of these features are provided by the compilation-minor-mode minor mode though not the actual compilation command and buffer. Once you have run a compilation command in eshell you could probably get similar results by setting the minor mode to compilation-minor-mode.
I personally prefer to run make or whatever command you're using to
compile within a multi-term
for the following reasons:
it works like M-xcompileRET if you activate
compilation-shell-minor-mode (M-p, C-`, …).
but you can, obviously, use other commands like
mkdir build
cd build
./configure --with-another-option
Of course you can do this from Emacs but I prefer the shell
interaction for this kind of stuff.
And imo, the main drawback of M-xcompile is that if
you're editing a file located in another directory than your
Makefile then you have to use M-xcompile in the correct
directory and then M-xrecompile. But if you want, say to
make clean && make, then you'll have to switch to the correct
directory, do it, switch back.
However term.el has its own drawback, it uses a non-portable hacky
way to track the current directory.

How do I run a C program from VIM?

Is there a way to compile and run a C program from VIM without typing its filename ?
:!gcc -o somename % && ./somename
When using :!, % will be substituted by the name of the currently opened file.
When your project becomes larger, you can also write a makefile and compile the current project with :make, if there are any errors, vim will jump to them automatically.
Use the following mapping code in your .vimrc file for compiling and running a c programming file.
map <F8> : !gcc % && ./a.out <CR>
F8 key is for run the mapping. "%" is to take the current file name.
Or, if you want to save the current file before compiling it, use
map <F8> :w <CR> :!gcc % && ./a.out <CR>
Or more ideally, if you want to use the file basename not the default 'a.out' as the executable file name, use the following:
map <F8> :w <CR> :!gcc % -o %< && ./%< <CR>
In the above command, "<" after "%" removes extension and dot (foo.c => foo), so "%<" is the file basename.
You can find this and similar infos in cmdline.txt. Command in vim:help: cmdline.txt. You can also find specific details about the use of "%" by using :help filename-modifiersin vim.
TL;DR No Makefile is required, tweaking &makeprg is also completely useless, and yet :make %< is enough to compile from Vim.
Long answer:
I duplicate an answer I gave in a closed "duplicate question".
Considering we are using vim, and not vi, :make is the way to go.
On Linux-like (it also applies to cygwin, but not to mingw on windows -- in mingw case, see the other answers that alter &makeprg, leave it alone otherwise) systems where gnumake is installed, if you don't have a Makefile in your project, and if your project is made of only one file, just type :make %<. It will be enough (you can play with $CXXFLAGS, $CFLAGS, $LDFLAGS (for -Llib/path options) and $LDLIBS (for -llibname options) to tune the compilation options). Then to run the program, type :!./%<, or with latter versions of vim, run :terminal ./%<.
If your project is made of several files, then you'll need a Makefile to take advantage of :make.
If you manage your project with CMake, and if you compile your project in a directory (or several -> debug, release, ...) outside the sources tree, then the integration will require a plugin. AFAIK, I'm the only one to propose such a plugin: BuildToolsWrapper integrates the management of CMake (choice of the build directory, possibility to chose between the debug, or release, or whatever build directory). It has to be coupled with one of the local_vimrc plugin.
In all cases, calling directly the compiler from within (or outside) Vim with :!g++ -o %< % or whatever is what we used to do 15 years ago on vi. Vim has a wonderful feature: it can integrate (yes, like in IDE) the compiler. See :h quickfix. Navigating between errors directly from the editor is much easier than extracting one error line with our eyes, typing back the line number into the editor, going back to the shell to see what exactly was rejected, ... It may be enough in C, but In C++ when we are "trying to call an overload that doesn't exist", we can't work this way (switching back and forth between the editor and the shell).
Finally, if you want to compile on a single keystroke those mono-file projects, you can add in your .vimrc:
nnoremap <silent> <f7> :make %<<cr>
If you want to adapt automatically the compilation command depending of the kind of project mono-file pet project, or real world multi-file project, well, more wiring is needed, and this is what BTW does -- it reads various options to know what to do.
Last note: &makeprg is best left alone, at least not set to g++/gcc/clang/clang++/gfortran/... Because, every time you change your language, you'll have to change it (unless you use :setlocal). With the solution I recommend, if I want to use clang++ instead of g++, all I have to do is to set: :let $CXX='clang++' (or $CC in C), and then call :make %<. I can even define :let $CXXFLAGS='-std=c++11' to compile in C++11 -- the same variable will be used to turn warnings on, to use a sanitizer, etc.
It's 2018 now, vim 8 has released for 2 years and shipped with all the Linux distributions and Mac OS X. But a lot of vim tutorials are still teaching people something ten years ago.
You can compile your C++/Java programs in vim as convenience as Sublime Text or NotePad++ with some dedicated plugins for Vim 8 or NeoVim.
For example, the AsyncRun plugin will allow you run shell commands in background and read output from quickfix window in realtime.
See the screen capture.
Just like compiling programs in IDEs, the compilation errors will be matched by errorformat and be highlighted and become selectable. You can navigate errors in the quickfix window or continue editing while compiling.
Quick setup
Copy & paste the lines below to your vimrc:
Plug 'skywind3000/asyncrun.vim'
" open quickfix window automatically when AsyncRun is executed
" set the quickfix window 6 lines height.
let g:asyncrun_open = 6
" ring the bell to notify you job finished
let g:asyncrun_bell = 1
" F10 to toggle quickfix window
nnoremap <F10> :call asyncrun#quickfix_toggle(6)<cr>
When you input “:AsyncRun echo hello ” in the command line:
see the capture here
You will see the realtime command output in the open quickfix window.
Compile and run a single file
Compiling a single file with AsyncRun is much simpler than Sublime Text’s build system. We can setup F9 for this:
noremap <silent> <F9> :AsyncRun gcc -Wall -O2 "$(VIM_FILEPATH)" -o "$(VIM_FILEDIR)/$(VIM_FILENOEXT)" <cr>
The macros in $(..) form will be expanded as the real file name or directory, and then we will have F5 to run the executable:
noremap <silent> <F5> :AsyncRun -raw -cwd=$(VIM_FILEDIR) "$(VIM_FILEDIR)/$(VIM_FILENOEXT)" <cr>
The double quotation mark is used to handle path names containing spaces. The option -cwd=$(VIM_FILEDIR) means running the file in the file's directory. The absolute path name $(VIM_FILEDIR)/$(VIM_FILENOEXT) is used because linux needs a ./ prefix to running executables in current directory, but windows doesn't . Using the absolute path name of the binary file can handle this crossing platform issue.
Another option -raw means the output will not be matched by vim's errorformat, and will be displayed in quickfix as what it is. Now you can compile your file with F9, check the compilation errors in quickfix window and press F5 to run the binary.
Build C/C++ Projects
No matter what build tool you are using, make or cmake, project building means acting to a group of files. It requires locating the project root directory. AsyncRun uses a simple method called root markers to identify the project root. The Project Root is identified as the nearest ancestor directory of the current file which contains one of these directories or files:
let g:asyncrun_rootmarks = ['.svn', '.git', '.root', '_darcs']
If none of the parent directories contains these root markers, the directory of the current file is used as the project root. This enables us to use either <root> or $(VIM_ROOT) to represent the project root. and F7 can be setup to build the current project:
noremap <silent> <F7> :AsyncRun -cwd=<root> make <cr>
What if your current project is not in any git or subversion repository ? How to find out where is my project root ? The solution is very simple, just put an empty .root file in your project root, it will be located easily.
Let’s move on, setup F8 to run the current project:
noremap <silent> <F8> :AsyncRun -cwd=<root> -raw make run <cr>
The project will run in its root directory. Of course, you need define the run rule in your own makefile. then remap F6 to test:
noremap <silent> <F6> :AsyncRun -cwd=<root> -raw make test <cr>
If you are using cmake, F4 can be map to update your Makefile:
nnoremap <silent> <F4> :AsyncRun -cwd=<root> cmake . <cr>
Due to the implementation of c runtime, if the process is running is a non-tty environment, all the data in stdout will be buffered until process exits. So, there must be a fflush(stdout) after your printf statement if you want to see the real-time output. or you can close the stdout buffer at the beginning by
setbuf(stdout, NULL);
At the mean time, if you are writing C++ code, a std::endl can be appended to the end of std::cout. It can force flush the stdout buffer. If you are developing on windows, AsyncRun can open a new cmd window for the child process:
nnoremap <silent> <F5> :AsyncRun -cwd=$(VIM_FILEDIR) -mode=4 "$(VIM_FILEDIR)/$(VIM_FILENOEXT)" <cr>
nnoremap <silent> <F8> :AsyncRun -cwd=<root> -mode=4 make run <cr>
Using the option -mode=4 on windows will open a new prompt window to run the command, just like running command line programs in Visual Studio. Finally, we have these key mappings below:
F4: update Makefile with cmake.
F5: run the single file
F6: run project test
F7: build project
F8: run project
F9: compile the single file
F10: toggle quickfix window
It is more like build system in NotePad++ and GEdit. If you are using cmake heavily, you can write a simple shell script located in ~/.vim/script/build.sh to combine F4 and F7 together: it will update Makefile if CMakeList.txt has been changed, then exectute make.
Advanced usage
You can also define shell scripts in your dotfiles repository and execute the script with F3:
nnoremap <F3> :AsyncRun -cwd=<root> sh /path/to/your/dotfiles/script/build_advanced.sh <cr>
The following shell environment variables are defined by AsyncRun:
$VIM_FILEPATH - File name of current buffer with full path
$VIM_FILENAME - File name of current buffer without path
$VIM_FILEDIR - Full path of current buffer without the file name
$VIM_FILEEXT - File extension of current buffer
$VIM_FILENOEXT - File name of current buffer without path and extension
$VIM_CWD - Current directory
$VIM_RELDIR - File path relativize to current directory
$VIM_RELNAME - File name relativize to current directory
$VIM_ROOT - Project root directory
$VIM_CWORD - Current word under cursor
$VIM_CFILE - Current filename under cursor
$VIM_GUI - Is running under gui ?
$VIM_VERSION - Value of v:version
$VIM_COLUMNS - How many columns in vim's screen
$VIM_LINES - How many lines in vim's screen
$VIM_SVRNAME - Value of v:servername for +clientserver usage
All the above environment variables can be used in your build_advanced.sh. Using the external shell script file can do more complex work then a single command.
Grep symbols
Sometimes, If you don't have a well setup environment in you remote linux box, grep is the most cheap way to search symbol definition and references among sources. Now we will have F2 to search keyword under cursor:
if has('win32') || has('win64')
noremap <F2> :AsyncRun! -cwd=<root> grep -n -s -R <C-R><C-W> --include='*.h' --include='*.c*' '<root>' <cr>
else
noremap <F2> :AsyncRun! -cwd=<root> findstr /n /s /C:"<C-R><C-W>" "\%CD\%\*.h" "\%CD\%\*.c*" <cr>
endif
The above script will run grep or findstr in your project root directory, and find symbols in only .c, .cpp and .h files. Now we move around the cursor and press F2, the symbol references in current project will be displayed in the quickfix window immediately.
This simple keymap is enough for most time. And you can improve this script to support more file types or other grep tools in your vimrc .
That’s the practical way to build/run C/C++ projects in Vim 8 or NeoVim. Just like Sublime Text’s build system and NotePad++’s NppExec.
No more outdated vim tutorials again, try something new.
since most of the time you would use a Makefile, in addition to the given answers, I also like to see my results in a "cleared" screen:
map <F10> :w<CR> :!clear; make<CR> :!./%<<CR>
:w<CR> saves the file
:!clear; make<CR> clears the screen and runs make
:!./%<<CR> runs a program (%) without the extension (<)
Add this line in your vimrc file
nnoremap <silent> <F8> :!clear;gcc % -o % && ./%<CR>
Now you only have to press f8 key to compile and run your c program.
Just thought I would add this to these answers here. As has been mentioned, you can use the :make command in vim. What has not been mentioned yet, is that :make can invoke other programs, other than make.
:set makeprg=gcc\ %
Will cause :make to execute gcc with the % symbol replaced by the current file name.
You can then get fancy and do
:set makeprg=gcc\ %\ &&\ ./a.out
and simply typing :make will compile and execute your program. You can do this for other languages as well of course.
:set makeprg=cabal\ repl
:set makeprg=python\ %
After doing some research (including this very page), I made my mind to add this shortcut:
map <F9> :w<CR> :!gcc % -o %<.x -Wall -Wextra 2>errors.err; cat errors.err<CR>
You can also include -ansi -pedantic-errors if you will.
The errors.err file will help you with vi quickfix.
I looked through all of these solutions and I found that they didn't work (as far as I could tell) for the case of editing a file in a different directory -- I wrote some vimscript that does this in a kinda clunky way, but hopefully someone can find this useful:
let mycommand = ':!gcc % -o %< && echo "%<" && [ $(pwd) == "." ] && %< || ./%< '
nnoremap <silent> <F8> :execute mycommand <CR>
or if the commands above work for you in multiple directories feel free to just ignore this.
It may be worth adding that SingleCompile plugin offers that facility for C and other languages as stated by the author:
SingleCompile is a Vim plugin aimed at making it more convenient to
compile or run a single source file without leaving Vim. Consider this
situation: you have just written a small C source file for a tiny
test, but you have to write a Makefile to compile it, or exit Vim to
compile it, or compile it using "!gcc" without quickfix feature
because Vim's make command only use the "make" command? This plugin
will help you out.
Suggested mappings for F9 and F10:
nmap <F9> :SCCompile<cr>
nmap <F10> :SCCompileRun<cr>
I have created command to Run my c & cpp codes
:command Runcpp !clear;g++ % -o %:r && ./%:r<CR>
:command Runc !clear;gcc % -o %:r && ./%:r<CR>
Put above code in .vimrc file and run you code using command Runcpp & Runc
you Can easily compile and run your program from vim directly just go to normal mode and type
:!gcc yourProgramName.c
and then just simply write the following to run the program
:!gcc % | ./a.out
Add these three lines to your .vimrc file
au FileType c set makeprg=gcc\ %
au FileType cpp set makeprg=g++\ %
map <F7>:make && ./a.out<CR>
You can compile and run your program by pressing the F7 button.
I have the following in my vimrc:
autocmd filetype c nnoremap <F9> :w<CR> :!clear<CR> :!gcc % -o %< && %<<CR>
This will allow you to Compile/Run C with <F9> and clear console
You can also do the following:
autocmd filetype c nnoremap <F8> :w<CR> :!clear<CR> :!make && ./%<<CR>
This will allow you to Compile/Run C using Makefile with <F8> and clear console

Resources