4

I want to clear all the text that is on the screen. I have tried using:

#include <stdlib.h>
sys(clr);

Thanks in advance! I'm using OS X 10.6.8. Sorry for the confusion!

rob mayoff
  • 375,296
  • 67
  • 796
  • 848
user2651382
  • 101
  • 1
  • 3
  • 8
  • 3
    What OS are you using? – JSQuareD Aug 09 '13 at 19:52
  • Duplicate question. Please check. – Tarik Aug 09 '13 at 19:52
  • 1
    I believe this question's answer will depend on the OS you are using. You need to edit the question and tell us which OS you are using – Paul Renton Aug 09 '13 at 19:54
  • Related: http://stackoverflow.com/q/228617/620197 – Mike D Aug 09 '13 at 19:59
  • 1
    Please consider the wisdom of doing this, when you find an answer. Many users, me included, don't appreciate programs randomly clearing their screens, or going off and doing something when I've pressed a key but before I've been given the opportunity to confirm it's the input I wanted to give by pressing **Enter**. Unless you're using an actual TUI, this kind of thing is never necessary, and usually just annoying. – Crowman Aug 09 '13 at 20:03
  • So this function `clrscr();` of the conio.h library wont work in C? I used it so many times. – Sid Aug 09 '13 at 20:04
  • @Sid: `clrscr()` isn't in stdio.h, it's in conio.h, which isn't POSIX compliant or available on most (edit) compilers. – Commander Worf Aug 09 '13 at 20:08
  • @Sid: `clrscr()` may be in *your* `stdio.h` header (`stdio.h` is not a "library"), but it's not in C's. – Crowman Aug 09 '13 at 20:08

4 Answers4

12

You need to check out curses.h. It is a terminal (cursor) handling library, which makes all supported text screens behave in a similar manner.

There are three released versions, the third (ncurses) is the one you want, as it is the newest, and is ported to the most platforms. The official website is here, and there are a few good tutorials.

#include <curses.h>

int  main(void)
{
     initscr();
     clear();
     refresh();
     endwin();
}
Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
Jiminion
  • 5,080
  • 1
  • 31
  • 54
7

The best way to clear the screen is to call the shell via system(const char *command) in stdlib.h:

system("clear"); //*nix

or

system("cls"); //windows

Then again, it's always a good idea to minimize your reliance on functions that call the system/environment, as they can cause all kinds of undefined behavior.

Commander Worf
  • 324
  • 1
  • 9
  • 5
    What a waste, you don't fork a full process for do this, and why introduce the race condition? – Edwin Buck Aug 09 '13 at 20:14
  • +1 to Edwin for bringing up the process issue. – Jiminion Aug 09 '13 at 20:17
  • How would you do it? Including the ncurses library is a bit overkill IMO, and one 'clear' process will hardly slow down most programs. – Commander Worf Aug 09 '13 at 20:18
  • 2
    If you think adding a library is overkill, try running a program. It adds all the libraries used to develop the program. Also, since, that program is a _shell_ it then interprets the arguments, does a look-up for the program on the path, and then launches another program. All of that for a screen clear? ncurses is a far better choice, and if someone slips in a rogue copy of "clear" or "cls", or has the ability to reorder their path, you didn't just introduce a security hole. – Edwin Buck Aug 09 '13 at 20:35
  • Can someone explain to me the race-condition this introduces and how forking would prevent it? – gravitas Aug 09 '13 at 20:36
  • 2
    You avoid it by not running two programs to do one job. If you decided to go with this solution, then you avoid it by polling the operating system to ensure that the clear program has exited cleanly before writing any further text to the screen (which would require a write-lock in your program). This "simple" solution is very problematic, to the point it's not simple to fix. Use the solution (documented by Jim) that costs you an extra five lines of code, but isn't subject to this race condition, because all of your screen logic is in one process. – Edwin Buck Aug 09 '13 at 20:40
3

Windows:

system("cls"); // missing 's' has been replaced

Unix:

system("clear");

You can wrap this in a single, more portable piece of code like so:

void clearscr(void)
{
#ifdef _WIN32
    system("cls");
#elif defined(unix) || defined(__unix__) || defined(__unix) || (defined(__APPLE__) && defined(__MACH__))
    system("clear");
//add some other OSes here if needed
#else
    #error "OS not supported."
    //you can also throw an exception indicating the function can't be used
#endif
}

Note the check for unix is pretty expansive. This should also detect OS X, which is what you're using.

Community
  • 1
  • 1
JSQuareD
  • 4,641
  • 2
  • 18
  • 27
  • Uses system call => extra process. Hmm..... – Jiminion Aug 09 '13 at 20:28
  • @Jim Good point, but it is the most no-nonsense way to do this. And in a simple console-application making a system-call every now and then will hardly be an issue for performance. – JSQuareD Aug 09 '13 at 20:57
  • Yes. I can see how both solutions have their place. – Jiminion Aug 09 '13 at 20:58
  • @edwinbuck exactly what makes this unportable? Also, whatever OS you're using, stdlib.h is the only header that needs to be included, so no preprocessor logic is required there. – JSQuareD Aug 09 '13 at 21:36
  • @JSQuareD You are right about the header includes. My apologies. The part that I meant to express in my complaints is that it assumes a very particular environment configuration, which while stock, is easily modified way past deployment. In that sense, it isn't functionally assured unless you can control the execution environment, over the entire life of the program. Not worth the hassle in my opinion, but you are right, the source code is portable. – Edwin Buck Aug 09 '13 at 21:44
  • @edwinbuck hmm.. I guess. But I find it hard to believe that people would undefine these macros or modify the meaning of cls or clear. And if they did, it's hardly the source code that's to blame. On any rate, I'm not saying curses isn't a more portable/elegant solution, I just think it's a bit of an overkill if you just want to clear the screen. Plus, it might be a fair bit of work to implement into an existing console application. – JSQuareD Aug 09 '13 at 21:56
  • `system("cls || clear");` –  Jun 13 '19 at 04:13
1

The availability of this function or similar ones like clrscn() are very system dependent and not portable.

You could keep it really simple and roll you own:

#include <stdio.h>

    void clearscr ( void )
    {
      for ( int i = 0; i < 50; i++ ) // 50 is arbitrary
        printf("\n");
    }
David Elliman
  • 1,379
  • 8
  • 15
  • 8
    That's not C, it's C++. And that doesn't clear the screen, just fills it with blank lines. Two key differences being that the cursor ends up at the bottom of 50 empty lines (instead of at (0,0)) and that the scrollable buffer is not erased as it would be if you cleared the screen. – brianmearns Aug 09 '13 at 19:57
  • 4
    It compiles as C for me. It works. Most command line programs do not use cursor addressing. – David Elliman Aug 09 '13 at 20:00
  • this is the way you did it before the VT terminal! – tallen Aug 09 '13 at 20:08
  • 1
    This _is_ in fact the only truly portable solution. (but it could cost a lot of paper on your TTY ;-) – wildplasser Aug 09 '13 at 20:17
  • 1
    @DavidElliman: It compiles as C because you changed it =J. ``cout <<`` like you originally had is not C as you cannot do operator overloading in C. My point about it not actually clearing the screen was that your cursor is left at the bottom of the console instead of the top. It's not just a matter of cursor addressing, it's a very definite cosmetic difference. When you clear the screen and start typing, you expect it to appear on the first line, not the last. It may be functionally the same in most cases, but it looks and feels very different to the user. – brianmearns Aug 10 '13 at 01:40