substitute for conio.h in linux

[saurabh_s]

hi

i was compiling a program in linux , the program had conio.h file which is generally used in turbo c in windows. now the program is not compiling and giving errors.

so what is the substitute . as clrscr() cant work without this file.

[ZuK]

Have a look at the ncurses library
http://www.tldp.org/HOWTO/NCURSES-Programming-HOWTO/
K.

[Narue]

Remove clrscr, you probably don't need it.

[ZuK]

@Narue: This is ridiculous.
The Op is asking for a way to port a program from one OS to another and you are telling him to throw away a probably perfectly working program
and start to design from scratch.
If you don't have anything meaningful to say about the question you should leave it altogether. This kind of comments are not helpful at all.
We could argue about the usefulness of clearing the screen in a console application. But there sure are reasons to do it.
K.

[jwenting]

no, all she says is that clrscr() is in almost all cases it is used used incorrectly and without being needed.

Its SOLE use is to clear the screen in console applications. BUT, console applications should NOT clear the screen, they should instead assume that the screen is not in any way under their control!

There are NO reasons for a console application to clear the screen. If you need total control of the screen you should not be writing a console application in the first place.

[ZuK]

There are NO reasons for a console application to clear the screen. If you need total control of the screen you should not be writing a console application in the first place.

I guess you are talking about programming in an environment with a GUI. But I am still using lots of programs from times
where no such thing as a GUI was available. In such an environment clrscr() was very useful to provide something that gets close to a GUI.
This thread is about porting not about redesign. :)
K

[Narue]

>you are telling him to throw away a probably perfectly working program and start to design from scratch.
Were you using Google Translate to read my post in Danish via Urdu? I suggested removing one line, not throwing away the program and starting over. Try reading for comprehension sometime, it's amazing the things you can learn.

>But there sure are reasons to do it.
Yes, there are. But most of the time when looking at old Turbo C programs, this is how it's used:

#include <conio.h>

void main() /* For added realism */
{
  clrscr(); /* Silly and useless */

  /* Program without clrscr here */
}

Now, until the OP shows us that his use is one of the "valid" ones, I'm going to assume that his use is in the majority of clrscr calls, ie. unnecessary.

>If you don't have anything meaningful to say about the question you should leave it altogether.
All of my posts are meaningful. If you're too narrow-minded to understand what I'm saying, or too stupid to read my posts correctly, that's not my problem.

[ZuK]

You should have said: Only if your program looks like this

#include <conio.h>

void main() /* For added realism */
{
  clrscr(); /* Silly and useless */

  /* Program without clrscr here */
}

throw away the clrscr().
I agree with that.

All of my posts are meaningful. If you're too narrow-minded to understand what I'm saying, or too stupid to read my posts correctly, that's not my problem.

I have checked some of your posts. It seems whenever someone has a different opinion you reply with an insult.
K.

[Narue]

>You should have said
I did, though without spelling it out for the slow people such as yourself:

Remove clrscr, you probably don't need it.

>It seems whenever someone has a different opinion you reply with an insult.
Taken out of context (which is something you seem very good at) it probably does seem that way. Pick a post and link to the thread and I'll be happy to explain the lesson/merit of my reply. Provided someone has a reasonable opinion, I'm willing to debate in a civil manner.

[kc0arf]

Hello,

Narue strikes me as a very experienced programmer, and she also cuts to the chase on program design. I only hope that she dismisses remarks about her character, and uses her volunteer time here to maintain the high level of excellence her experience offers us.

This thread, however, is about the conino.h file, and it's technical uses. It will not turn into a character debate; and if anyone tries, I'll lock and we will all move on. The moderator staff will also torpedo any new threads that deal with character in public.

Christian

[jwenting]

I guess you are talking about programming in an environment with a GUI. But I am still using lots of programs from times
where no such thing as a GUI was available. In such an environment clrscr() was very useful to provide something that gets close to a GUI.
This thread is about porting not about redesign. :)
K

no, I'm SPECIFICALLY talking about programs in a commandline environment.
There's ways to have a fullscreen application in those too, unless your operating system and hardware are from the mid 1970s or before.

It's about porting but during ports errors in the design should be addressed and the clrscr command is used in error (in fact its very inclusion in compiler libraries could be considered an error on the part of the compiler writers).

NEVER clear the screen in a commandline environment. That screen isn't yours, you're expected to graciously share it with everyone else.

You should in fact not expect any output to ever reach the screen at all. Redirection to file is extremely common, especially in a Unix environment. Redirection to printer is also quite possible.
Clearing the screen in those situations makes no sense as the file or printer cannot be cleared. Therefore using a command to clear the screen doesn't produce predictable results, therefore its use constitutes a bug.

Bugs should not be ported therefore removing the clrcscr is a required step in the porting process.

[ZuK]

Ok. This is too much.
@kc0arf : would you remove my account.
Bye

[wasted___]

may not be a good idea....

but still....
it can behave like clrscr();

use fork(), execve() and wait()

#include <unistd.h>
#include <stdio.h>

int main()
{
int pid;
pid = fork();
if (0 == pid)
{
execve("/usr/bin/clear", NULL, NULL);
}
wait(NULL);

....
ur contents...
..
..
}

dont forgot to include <unistd.h> for these system calls...
this pgm, creates a copy of the pgm as a child by fork()
the parent waits for the completion of the child by wait()
meanwhile the child calls "clear" cmd by using execve()

its like you using cls in cmd!!!

[Duoas]

Hmm, without knowing anything at all about the OP's original purpose, this thread has become a hate-war over clearing the screen.

It is not uncommon for old DOS programs to assume complete control of the console -- particularly in business environments. Catagorically stating that it is always/never acceptable to do something is beyond anyone's qualifications.

"Porting" from DOS is not something that is usually done for trivial CS 101-type and nicely-behaved streams-type programs. The OP seems interested in correctly porting all the original behaviors of the program... which include taking over the console. I would otherwise agree with Narue's curt remark -- you probably don't need it. Well-behaved streams applications don't muck with the user's TTY.

On *nix systems, you will have to either emit the correct terminal escape sequences yourself or use NCurses. (There are other ways to do this, but they are not Correct -- they either introduce security holes in your application or will break on systems other than your development machine[s].)

To properly emit the "clear" sequence yourself (in *nix), use the following very simple snippet:

#include <unistd.h>
#include <term.h>

void ClearScreen()
  {
  if (!cur_term)
    {
    int result;
    setupterm( NULL, STDOUT_FILENO, &result );
    if (result <= 0) return;
    }

  putp( tigetstr( "clear" ) );
  }

You will have to link with the appropriate library (-lcurses, -lncurses, -lterminfo, or something odd on your system -- SunOS is particularly obnoxious about linking to the correct library).

By "very simple" I mean that it could be made more efficient if you plan to do a lot of direct terminal manipulation, but for most purposes this will do. Notice that it also lacks issues of environment validation. You can use isatty() at the head of your program to verify that you are interacting with a human sitting at a terminal TTY.

Do you also need to mess with colors, position the cursor, and get unbuffered input? (If not, then I suspect that Narue is right, and you should dike out the call to clrscr().)

Hope this helps.

[WaltP]

Hmm, without knowing anything at all about the OP's original purpose, this thread has become a hate-war over clearing the screen.

Yes, and it was thankfully dead for 6 years until a wasted person resurrected it with a worthless suggestion.

[Duoas]

:-@
Whoops!