I am learning C Programming currently on VS Code. I run program a lot of time repeatedly which mess up terminal. Mostly I use cls before running program to clear previous output of terminal. My default terminal is PowerShell in VS Code. Is there any way to clean terminal before each run.
What I have tried after google search:
-I have tried adding cls to powershell profile but it does not work on every code run.
-Checking clear previous output in coderunner settings didn't work either.
The easiest way is to add cls to the beginning of your code, but that's not always best:
You can also set a keyboard shortcut for clearing the console (Used to be ctrl+k, but was removed)
You don't want to replace the existing behavior when running code, but a pretty simple one-button solution could be setting up a vs code macro to do Terminal: Clear, and also run your open file in the terminal.
Related
I have written one very simple app in C. I know how to run it through Visual studio, but i want to start it from desktop with a double-click. If I double-click on a .exe file made in folder, it does not start. How can I do this?
If you do not wish to modify your code so that it will wait for user input before closing (and there are many reasons that might be inappropriate), you could create a batch file wrapper:
myprog.bat
myprog.exe
pause
Then either you can double click the batch file or create a shortcut to the batch file then edit the shortcut to set the path to the batch file and the path from which to run (so it can find the exe).
That pretty much emulates how Visual Studio runs your code without terminating the window.
Another method you might consider is a batch file such as:
runner.bat
%1
pause
Then you can drag-and-drop your executable onto the runner.bat icon to run it. The advantage being that you don't have to create a new batch file and/or shortcut for every new executable.
Really though this is not a C question, or even a programming question - it is most likely off topic. If your code is ever required to run to completion unattended in a batch file for example, you would not necessarily want to add any interactivity to the program itself.
Your problem is that double clicking on a console app will open a new console window, run the program and then close the window.
VS studio does a trick where it runs the app in a new console window but keeps it open till you press a key.
You can add that same thing yourself - put a getchar() call at the end
Or you can make a bat file to run the app as per Cliffords answer
1st open the code with visual studio code
Run or Build the program
then u will find an executable file where u have saved your code
Open that executable file
but you must have installed mingw installed in your environment
you must compile it first with mingw or like compiler. and start it with by code:
cmd> yourdirectory(e.g Desktop)/ gcc yourcodefile.c your question is available also internet => how-to-compile-c-program
There's this bug with the placement of certain characters in the embedded terminal in CLion (the Run tab that pops up when you click the Run button), and I figured out that if I changed the terminal in CLion, that wouldn't happen. I changed the terminal to cmder, and it is all working now, except one thing: I can't figure out how to make CLion run the program to that terminal.
I tried changing the configuration, but all it did on run was open cmder but not execute the program (I had to run it manually, by writing the file name).
I wonder, what's the way to fix this, and make CLion directly run C programs on the terminal, instead of the Run tab?
Thank you.
The CLion run configuration always runs in the integreted run window. That is not a terminal emulator, and it cannot be changed so that it runs in an actual terminal emulator (like cmder).
Your best bet is to try to fix the "character placement" in the run window. Maybe ask a different question where you explain the issue, or if it's a clear bug, file a bug report for it.
I am using eclipse cdt oxygen with mingw64 7.2.0 on windows 10 to write programs in c. Whenever I write programs that only outputs like:
printf("x\n");
The output got printed into the console. However when I write programs that asks for inputs, like:
c = getchar();
rather than going to the console, eclipse instead opens a terminal. I believe that is where you will type the input. This doesn't usually bother me, however my eyes are destroyed, I am using a screen reader and this terminal is somewhat inaccessible. It is usable, but can be very hard to use sometimes (E.G. my screen reader JAWS does not speak what I'm typing).
Is there a way for eclipse cdt to put all inputs and outputs directly to the console?
Unfortunately in this case eclipse console is read only. Better once compile and build your code go to the folder where it created your exe file and run that exe in command prompt and test.
open command prompt window (type cmd)
cd C:\path_to_your_exe\
yourexe
This will also help you in case your program takes command line parameters.
I want to debug an application with lldb. At the beginning, I want to set a few breakpoints with a set of commands. I'm aware of the -s option, but this somehow doesn't let me interactively debug the application after executing the commands in the file. Essentially I want to replicate the behavior of gdb. How do I do this?
There is a bug in the way the lldb command parser sources command files, where it doesn't recognize that a command like "breakpoint command add" has switched to a new "input parser" (the one that reads and stashes away the commands but doesn't execute them, and then waits for the DONE to exit.) The effect of this is that, if you do:
breakpoint command add
some command
some other command
DONE
the input gets all messed up and things go poorly, as you have seen. This bug is actually fixed in TOT lldb, though that hasn't made it to an official Xcode release yet.
In the meantime, there aren't any great workarounds for this. If your breakpoint commands are simple, you can use the --one-liner option to specify them without switching to the breakpoint input parser. Or, if you know a little Python you can make Python function breakpoint commands, import them with "script import" and tie them to the breakpoint with the -F option.
For years now my Windows C tagging/scoping solution has almost worked. I can build the filelist, build the tags (via Exuberant Ctags) for vim/gvim navigation, build cscope.out, and tag around within gvim.exe windows I launch by clicking on C source files.
The final piece that eludes me is that I can't seem to get cscope in cmd.exe to launch my editor when I select an item. I made sure gvim.exe is in my Path environment variable. I made sure the CSCOPE_EDITOR environment variable is set (more on that below). But when I select a line item from within cscope the editor is not launched. Instead I get one of the two following failures:
If CSCOPE_EDITOR is either gvim.exe -f or "gvim.exe -f" then I see that printed at the top of the cmd.exe window followed by the line offset and the filename (e.g. "gvim.exe -f +72 myfile.c") and then it quickly returns to cscope without the editor ever popping.
If CSCOPE_EDITOR is gvim.exe (without the -f option) then a gvim.exe process is kicked off (I see it in Windows Task Manager under Processes) but it never comes to the foreground as an application. Furthermore, the cscope window in cmd.exe goes blank and is unresponsive until I manually kill the gvim.exe process that was spawned.
For reference:
cscope -V returns "cscope: version 15.8a" and was downloaded from this site: http://code.google.com/p/cscope-win32/
My version of gvim.exe is 7.3 which the latest available from http://www.vim.org/
Also, I have tagged this post with "C" because, while this is not a C language question, cscope and ctags are primarily used for C programming and thus I think the C tag is relevant. (Thought I'd point that out before someone comes along and removes the tag and says this isn't a C question, since C programmers are the most likely people to have the answer.)
With help from #mattn and #mMontu and a lot of trial-and-error and an ugly but simple hack I finally have this working. Here are the problems I encountered:
cscope-win32 does not handle spaces in the EDITOR or CSCOPE_EDITOR environment variables. I tried every space-escape trick I could think of (single-quotes, double-quotes, backslash escapes) and nothing worked.
When gvim.exe is successfully launched by cscope-win32, if that gvim.exe tries to add the same cscope.out database (via cs add cscope.out) the add command hangs. If the add is part of a vimrc file then the editor will hang during opening (with the gvim.exe and cscope.exe processes starting but the application window never appearing). If the add is done after the editor window opens then the window will hang. This appears related to multiple cscope-win32 processes being attempted in the same process tree, but I have no actual proof of that.
Here's my solution to the problem. Like I said, it is an ugly but simple hack.
Create a wrapper batch file. I named mine gvim_cscope.bat. Make sure it is in a directory that exists in your PATH environment variable. You can verify this in a cmd.exe shell by calling "where gvim_cscope.bat".
Edit the batch file and add your editor command but precede it with the windows start command. For example, my batch file contains the following:
start gvim.exe %*
Create/Update your CSCOPE_EDITOR environment variable to be "gvim_cscope.bat". In case you've never modified a Windows environment variable before, you can get to them (on Windows 7 anyway) via Start -> right-click Computer -> Properties -> Advanced System Settings -> Environment Variables.
That's all I needed to get things working. Open a new cmd.exe window (so the updated environment variable is pulled in) and open cscope.exe and everything works. I am able to pop multiple gvim.exe windows from within cscope.exe, each with its own connection to the cscope.out database. The first problem is avoided by using the wrapper batch file (no more spaces in the command) and the second problem is avoided by using the windows start command so that gvim.exe is started as a separate process.
Thanks for the help #mattn and #mMontu. So nice to have things working right!