Hello. I have been told that system() is "bad" to use... So, how do I clear
the console screen safely without system()???
I doubt there is a way that anybody knows of. But if anyone does know a way,
please tell me how!
The cheesy way is to just spam end of lines to scroll the text off the screen.
a variety of nonstandard functions to write to consoles (these tend to be OS specific) exist, and they may or may not have a clear function, or a move the cursor function that lets you clear the screen one way or another.
there are other system call invocation commands that are more secure than system. Again, OS specific for many of them.
you may also consider understanding the scope of the issue.
system is 'bad' because some idiot can put cls.bat on your disk and do ANYTHING that can be done on the computer with the current user's rights when your program is fooled into calling it. Or an alternate cls.exe even that is a virus or malware etc. What are the odds of this happening? Well, if its a corporate computer, the risk is too great, sure. If its your home computer doing homework, the odds are less that some hacker is *that* interested in you to set up this rather unlikely hack. Also, if its a large, serious software package, would it be command line UI driven? Some utilities are, sure, but few of them have menus or need to clear the screen (eg, grep ..). A command line UI that needs a clear screen is fairly rare since, I dunno, 1985 or so?
Bottom line is that unless you have a very unusual program that is actually a console UI program that is actually not homework or a toy such that it needs real security concerns to be eliminated and best practices observed, system cls is just fine. (or generically, system() is just fine).
The cheesy way is to just spam end of lines to scroll the text off the screen.
Lol I have tried that.
Ok, so by running the line system("cls"), it COULD clear the screen, or it COULD activate some fake program called "cls" that was put there by some idiot hacker, right?
Thanks for answering.
One thing though, if I could get the code that is inside cls.exe (or whatever clears screen)
I could add it as a function in my code and use it, right?
yes, if you can find it. I think it is part of the cmd.exe program, though. cmd is a command parser and cls is one of the commands it understands. I don't think you can extract just that chunk of code.
if you still want to avoid system,
use ncurses library and you will find a clear screen I believe. I haven't done a lot of console fancy code in many, many years. The few things I clear the screen for use... system :P. Ncurses is a unix thing but its been ported to windows and is almost but not quite a c++ standard library these days.
Honestly, that is a good question.
Answer 1) ... order of operations. if cmd looks first for a batch file or executable in the current path, if not there then looks at what it knows how to do internally, then it could happen.
Answer 2) maybe cls is its own executable program and I was wrong on that one.
Answer 3) Something else :) Again, I haven't dug into this issue super deep. The problem isnt the CLS, its the SYSTEM, though. Even if CLS is built in and can't be overridden with malware (I don't honestly know), if you use system for OTHER things (you can do any 'dos' command with it, or run any program, etc) then those could be hijacked for sure. What ppl are telling you is that system() itself is a risk, not CLS.
also, this is relatively NEW, but on winx and everything current, try this gem:
std::cout << "\x1B[2J\x1B[H";
I should have remembered that up front, but its 2:30 am here, and I am a little more confused than usual due to the hour.
-- I tried it. on my system, there is no cls.exe or cls.bat or anything like it. Also, creating one where my test program runs, and calling system(cls) does NOT run the batch file, it clears the screen. /shrug. I take that to mean its built into cmd and that using it for CLS is likely safe enough, but using it for other things... may not be.
it clears the screen.
I have no idea why -- its some sort of archaic unix console command or code from the days of yore that works in windows since windows 10 (or a version or two before).
I mean, I know 'why' -- its because windows is coded to accept it as a command to clear the screen -- but I don't know "why these specific hex values". It was part of the unix shell on windows thing they did, to make windows more posix compatible, a few years back.
cout << "\033c";
this worked for me also, and for all I know its the same real bytes as the other one, but you could try it. I am too sleepy to check if its the same bytes as the first one we tried.
you can also check to see WHICH cmd you ran. I run the admin version, and maybe it matters, there are a number of subtle differences (you can't drag and drop a file or folder to the admin one, for example, but it can do stuff the normal can't). I don't know that this matters, but you can try it.
the web says the 2016 era 'anniversary update' should have put posix on there. Surely you have this.
I am going to bed now :) If you figure it out, I would love to know what it was. If not, and you still care, I can look again once I am rested.
void ClearScreen()
{
HANDLE hStdOut;
CONSOLE_SCREEN_BUFFER_INFO csbi;
DWORD count;
DWORD cellCount;
COORD homeCoords = { 0, 0 };
hStdOut = GetStdHandle( STD_OUTPUT_HANDLE );
if (hStdOut == INVALID_HANDLE_VALUE) return;
/* Get the number of cells in the current buffer */
if (!GetConsoleScreenBufferInfo( hStdOut, &csbi )) return;
cellCount = csbi.dwSize.X *csbi.dwSize.Y;
/* Fill the entire buffer with spaces */
if (!FillConsoleOutputCharacter(
hStdOut,
(TCHAR) ' ',
cellCount,
homeCoords,
&count
)) return;
/* Fill the entire buffer with the current colors and attributes */
if (!FillConsoleOutputAttribute(
hStdOut,
csbi.wAttributes,
cellCount,
homeCoords,
&count
)) return;
/* Move the cursor home */
SetConsoleCursorPosition( hStdOut, homeCoords );
}
Ok, thanks. What does std::cout << "\x1B[2J\x1B[H"; do?
It's VT100 escape codes. See ascii-table.com/ansi-escape-sequences-vt-100.php These were used by the DEC VT100 consoles to control how text was displayed on the screen. They were widely emulated by other manufactures. Anyone who did mini-computer programming in the 1980's probably knew many of these common ones off by heart.