Re: programming a "terminal"?

Discussion in 'C Programming' started by Arjun, Dec 13, 2005.

  1. Arjun

    Arjun Guest

    I can't use screen directly because I've got to program the thing
    myself, though that doesn't exempt me from borrowing code (if
    applicable) from somewhere else.

    I don't think the windowing system will be too much of a problem (this
    will bite me), because ncurses has good support for that - I may have
    several different screens, stdscr, screen1, screen2, etc, or I may have
    one large pad with each visible section being one window. I've written
    some ncurses stuff before, so I'm pretty confident about this. What's
    stumping me is the actual command execution.

    >A typical command-line window in a window has a RUNNING shell in
    >it (which eliminates the effect of logging out and back in for every
    >command, and makes builtin commands like cd and umask and >environment
    >variable changing stick). The stdin, stdout, and stderr of the
    >shell are typically connected to a pseudo-terminal. The pseudo-teriminal
    >avoids some of the buffering problems you get with pipes buffering
    >stuff, making interactive response difficult to impossible. Each
    >session attached to a window thinks it has its own terminal (of
    >perhaps tiny size).


    >The master end(s) of the pseudo-terminals are connected (perhaps
    >over a network) to the windowing program whose job it is to present
    >the windows.


    I think I understand what you're saying, but I'm a little unclear on a
    few points:

    - So, I have my program initiate a shell... is this as simple as
    system("bash"), or is there something else I need to do to facilitate
    everything that will follow (redirecting stdin, etc to
    pseudo-terminal)? I know all that will take extra code, but does it
    require a speciall initialization method or anything?

    - I'm unsure of what you mean by pseudo-terminal. Are you referring to
    pseudo-terminal in the sense of, say, ptyp3 and ttyp3? If you are, I'll
    bone up on my knowledge of them, it's virtually nil now.

    - The master ends of the pseudo-terminal connect to the windowing
    program... would this be connecting the pseudo-terminal to all the
    ncurses stuff with named screens and key actions and so on?

    >From the answers to these questions, I should be able to get a decent

    sense of the direction I need to go in, so I can really start working.

    >A *simple* setup has only one window.


    True enough, and this would be a fine source for me - I'm really
    curious about the terminal part of it.

    I have to admit that I'm fairly clueless about this area of C, most of
    the stuff i've done in the past has been in other areas.

    Thanks,
    Arjun
    Arjun, Dec 13, 2005
    #1
    1. Advertising

  2. "Arjun" <> writes:
    > I can't use screen directly because I've got to program the thing
    > myself, though that doesn't exempt me from borrowing code (if
    > applicable) from somewhere else.


    Why do you have to program it yourself?

    > I don't think the windowing system will be too much of a problem (this
    > will bite me), because ncurses has good support for that - I may have
    > several different screens, stdscr, screen1, screen2, etc, or I may have
    > one large pad with each visible section being one window. I've written
    > some ncurses stuff before, so I'm pretty confident about this. What's
    > stumping me is the actual command execution.


    Your program is almost certainly going to be largely system-specific.
    ncurses in particular is off-topic in comp.lang.c, since it's not part
    of the standard library. Your best bet is probably comp.unix.programmer.

    <OT>
    If the sources to the screen program are too much, you might be able
    to get some insight from the documentation.
    </OT>

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Dec 13, 2005
    #2
    1. Advertising

  3. Arjun

    Arjun Guest

    I've got to program it myself because it's a project I'm required to do
    for my CS class.

    I'll check out comp.unix.programmer and the screen documentation.

    Thanks
    Arjun
    Arjun, Dec 13, 2005
    #3
  4. "Arjun" <> writes:
    > I've got to program it myself because it's a project I'm required to do
    > for my CS class.


    Your next assignment is to read <http://cfaj.freeshell.org/google/>
    and follow its advice.

    And if you're asking for help on a homework assignment, please say so
    up front.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Dec 13, 2005
    #4
  5. >I can't use screen directly because I've got to program the thing
    >myself, though that doesn't exempt me from borrowing code (if
    >applicable) from somewhere else.


    ANSI C doesn't acknowledge any such requirements. ANSI C overrides
    them. Homework assignments in C *DO NOT* have to avoid using
    semicolons, or avoid making library calls, or whatever even if the
    assignment says so. Any instructor trying to enforce these is
    subject to the wrath of both undefined behavior and undefined
    behaviour, and this tends to involve grade books getting shoved
    where the sun don't shine.

    >I don't think the windowing system will be too much of a problem (this
    >will bite me), because ncurses has good support for that - I may have
    >several different screens, stdscr, screen1, screen2, etc, or I may have
    >one large pad with each visible section being one window. I've written
    >some ncurses stuff before, so I'm pretty confident about this. What's
    >stumping me is the actual command execution.


    >>A typical command-line window in a window has a RUNNING shell in
    >>it (which eliminates the effect of logging out and back in for every
    >>command, and makes builtin commands like cd and umask and >environment
    >>variable changing stick). The stdin, stdout, and stderr of the
    >>shell are typically connected to a pseudo-terminal. The pseudo-teriminal
    >>avoids some of the buffering problems you get with pipes buffering
    >>stuff, making interactive response difficult to impossible. Each
    >>session attached to a window thinks it has its own terminal (of
    >>perhaps tiny size).

    >
    >>The master end(s) of the pseudo-terminals are connected (perhaps
    >>over a network) to the windowing program whose job it is to present
    >>the windows.

    >
    >I think I understand what you're saying, but I'm a little unclear on a
    >few points:
    >
    >- So, I have my program initiate a shell... is this as simple as
    >system("bash"), or is there something else I need to do to facilitate
    >everything that will follow (redirecting stdin, etc to
    >pseudo-terminal)? I know all that will take extra code, but does it
    >require a speciall initialization method or anything?


    All of this stuff is system-specific.

    You need to allocate a pseudo-terminal device (there is a system-specific
    procedure to do this, which is supposed to work with several programs
    each trying to grab one simultaneously). This may require root
    privileges.

    You start the shell with stdin, stdout, and stderr set to the slave
    ends of the pseudo-terminal. Your window manager takes input (output
    from the program) from the (multiple) master pty ends and paints
    them on the display device. (It's pretty mandatory to use non-blocking
    I/O or select() or poll() here.) This involves interpreting sequences
    in the output from the program to move the cursor around, clear the
    screen, etc. YOU have to deal with translating row and column
    numbers in the window to row and column numbers of the physical
    display device.

    >- I'm unsure of what you mean by pseudo-terminal. Are you referring to
    >pseudo-terminal in the sense of, say, ptyp3 and ttyp3? If you are, I'll
    >bone up on my knowledge of them, it's virtually nil now.


    Yes.

    >- The master ends of the pseudo-terminal connect to the windowing
    >program... would this be connecting the pseudo-terminal to all the
    >ncurses stuff with named screens and key actions and so on?


    Yes, but the "connecting" part is done with code YOU write. YOU
    decide that the sequence ESC 3.141592OH_CRAP!! clears the window
    corresponding to the program it came from. YOU decide what terminal
    type your windowing program is, and YOU write the termcap entry for
    it (unless you're just borrowing an existing one, which may save a
    little work). YOU need to keep one program from overwriting another
    one's window.

    One of the things you need to deal with is that ncurses doesn't like
    you to run off the edges of windows, so YOU have to deal with
    preventing it. printw("supercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocious")
    in ncurses tends to cause smegmentation faults.

    >>From the answers to these questions, I should be able to get a decent

    >sense of the direction I need to go in, so I can really start working.
    >
    >>A *simple* setup has only one window.

    >
    >True enough, and this would be a fine source for me - I'm really
    >curious about the terminal part of it.
    >
    >I have to admit that I'm fairly clueless about this area of C, most of
    >the stuff i've done in the past has been in other areas.


    Gordon L. Burditt
    Gordon Burditt, Dec 15, 2005
    #5
  6. In article <>,
    Gordon Burditt <> wrote:
    >YOU decide what terminal
    >type your windowing program is, and YOU write the termcap entry for
    >it (unless you're just borrowing an existing one, which may save a
    >little work).


    (Off-topic, obviously)

    A slightly amusing idea is to use the termcap entry pointed to by the
    TERM variable to *define* the actions you take in response to the
    sequences specified in it.

    This is reminiscent of the devices which instead of coming with a
    remote control allow you to use any old remote control you have lying
    around by learning what the buttons send.

    -- Richard
    Richard Tobin, Dec 15, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brantley Richbourg

    Visual Studio .NET & Terminal Server

    Brantley Richbourg, Nov 1, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    464
    Brantley Richbourg
    Nov 1, 2004
  2. Bill Priess

    Re: Restart service - Terminal Services

    Bill Priess, Jun 25, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    1,110
    Bill Priess
    Jun 25, 2003
  3. Arjun

    programming a "terminal"?

    Arjun, Dec 13, 2005, in forum: C Programming
    Replies:
    1
    Views:
    304
    Chuck F.
    Dec 13, 2005
  4. gaurav kashyap
    Replies:
    3
    Views:
    6,615
    Paul Boddie
    Oct 31, 2008
  5. Steve
    Replies:
    2
    Views:
    916
    edicionsdigitals.com edicions digitals xarxa socia
    Dec 7, 2010
Loading...

Share This Page