Re: creating a custom newsreader

Discussion in 'Perl Misc' started by gamo, Jan 26, 2014.

  1. gamo

    gamo Guest

    El 26/01/14 09:57, Cal Dershowitz escribió:
    > Howdy newsgroup,
    >
    > I'm a little bit bored and have decided to indulge a hobby project. I


    But a hobby doesn't means you doesn't RTFM.

    You basically failed to provide a server, and a group.

    Try something around this:

    #!/usr/bin/perl -w

    use News::NNTPClient;

    $c = new News::NNTPClient("news.aioe.org");
    ($first, $last) = ($c->group("comp.lang.perl.misc"));

    for (; $first <= $last; $first++) {
    print $c->article($first);
    }

    __END__


    This will print a lot of articles. That module provides _examples_
    as how to get articles i.e. by time.

    > Thanks for your comment, and cheers from the great state of california.


    Cheers from hell

    --
    http://www.telecable.es/personales/gamo/
    gamo, Jan 26, 2014
    #1
    1. Advertising

  2. gamo

    $Bill Guest

    On 1/28/2014 22:26, Eli the Bearded wrote:
    >
    > can't recall the last "material change" to xterm, but plenty of bug fixes


    A little OT, but speaking of xterm (the UNIX one - a terminal window under
    the X windows system). Is there a similar animal under Windows that has
    the same functionality as a remote Xterm ? Basically a single terminal
    window where you can log into another machine on your LAN and run a shell.

    I want to be able to log into my desktop from my laptop and run a job in a
    window.

    And no, I don't want/mean remote desktop which messes up the whole remote
    screen - just a single window on the laptop that talks to a shell on the
    desktop (tcsh in my case) like Xterm does with nothing visible on the desktop.
    $Bill, Jan 30, 2014
    #2
    1. Advertising

  3. gamo

    Dave Saville Guest

    On Thu, 30 Jan 2014 11:32:31 UTC, "$Bill" <> wrote:

    > On 1/28/2014 22:26, Eli the Bearded wrote:
    > >
    > > can't recall the last "material change" to xterm, but plenty of bug fixes

    >
    > A little OT, but speaking of xterm (the UNIX one - a terminal window under
    > the X windows system). Is there a similar animal under Windows that has
    > the same functionality as a remote Xterm ? Basically a single terminal
    > window where you can log into another machine on your LAN and run a shell.
    >
    > I want to be able to log into my desktop from my laptop and run a job in a
    > window.
    >
    > And no, I don't want/mean remote desktop which messes up the whole remote
    > screen - just a single window on the laptop that talks to a shell on the
    > desktop (tcsh in my case) like Xterm does with nothing visible on the desktop.
    >


    PUTTY?
    --
    Regards
    Dave Saville
    Dave Saville, Jan 30, 2014
    #3
  4. gamo

    John Black Guest

    In article <>, says...
    > The remote machine needs to be running sshd or telnetd or something
    > equivalent. (This, in practice, means it needs to Not Be Running
    > Windows.) If that is the case then you want PuTTY (put it into Google).


    cygwin provides telnetd for Windows (and lots more).

    John Black
    John Black, Jan 30, 2014
    #4
  5. gamo

    $Bill Guest

    On 1/30/2014 08:42, Ben Morrow wrote:
    >
    > The remote machine needs to be running sshd or telnetd or something
    > equivalent. (This, in practice, means it needs to Not Be Running
    > Windows.) If that is the case then you want PuTTY (put it into Google).


    I don't follow that - why can't the remote daemon just run on a different
    port and 'fork' off a terminal window with a shell running in it ?

    Will check out PuTTY asap.
    $Bill, Jan 31, 2014
    #5
  6. gamo

    $Bill Guest

    On 1/30/2014 20:26, Ben Morrow wrote:
    >
    > Quoth "$Bill" <>:
    >> On 1/30/2014 08:42, Ben Morrow wrote:
    >>>
    >>> The remote machine needs to be running sshd or telnetd or something
    >>> equivalent. (This, in practice, means it needs to Not Be Running
    >>> Windows.) If that is the case then you want PuTTY (put it into Google).

    >>
    >> I don't follow that - why can't the remote daemon just run on a different
    >> port and 'fork' off a terminal window with a shell running in it ?

    >
    > I'm not sure I understand... what do you mean by 'run on a different
    > port'?


    I mean listen on a port other than the standard sshd port for incoming
    connections.

    > If you mean, 'why can't the remote (Windows) machine create a new
    > cmd.exe window when a connection comes in', then how is the display of
    > that cmd window supposed to be communicated back to the client?


    No window is needed on the server - just a process running a shell. The
    terminal window would be on the client - the same as running a remote Xterm
    under an old UNIX system with XWindows (I used to do it all the time under
    Solaris) - same as a local Xterm, but you added a host arg to the open to
    log into a remote host. The server's shell input and output are simply
    routed back to the client terminal window.

    > This is
    > what a pty does for you on Unix: it provides a terminal device with a
    > 'back door' that programs like telnetd and sshd can use to see what's
    > been sent to the terminal, but a pty is a kernel facility and Windows
    > doesn't provide anything equivalent.
    >
    > What you could do, these days, I believe, is invoke cmd.exe via Windows
    > Terminal Services (assuming you're running a version of Windows which
    > supports that), forward the whole GUI mess to the client over RDP, and
    > then display it 'seamlessly' in a window on the client machine. (Or do
    > the same with VNC, of course.) This isn't really equivalent to a ssh
    > connection to a Unix machine, though.


    Sounds plausible - how does one do that complicated mess though?
    $Bill, Feb 1, 2014
    #6
  7. gamo

    $Bill Guest

    On 1/31/2014 21:17, Ben Morrow wrote:
    >
    > Quoth "$Bill" <>:
    >> On 1/30/2014 20:26, Ben Morrow wrote:
    >>> Quoth "$Bill" <>:
    >>>> On 1/30/2014 08:42, Ben Morrow wrote:
    >>>>>
    >>>>> The remote machine needs to be running sshd or telnetd or something
    >>>>> equivalent. (This, in practice, means it needs to Not Be Running
    >>>>> Windows.) If that is the case then you want PuTTY (put it into Google).
    >>>>
    >>>> I don't follow that - why can't the remote daemon just run on a different
    >>>> port and 'fork' off a terminal window with a shell running in it ?
    >>>
    >>> I'm not sure I understand... what do you mean by 'run on a different
    >>> port'?

    >>
    >> I mean listen on a port other than the standard sshd port for incoming
    >> connections.

    >
    > Why would you need to do that? (I'm confused, here; maybe it's not
    > important.)


    To accept a remote client connection that wants to control the shell on
    the server (basically the remote client is just the input and output of that
    shell on the server and obviously you need to fake it out into thinking
    the daemon [or a forked emulator from the daemon] is the terminal when in
    reality it's the client GUI window).

    > OK, you're talking about two different things here. The first is when
    > you're sitting in front of a terminal (emulator), you type 'ssh rhost',
    > and you get a shell running on rhost. If you were running a process
    > which expects to be running on the end of a pipe, this wouldn't need any
    > special handling: the sshd runs the process on the remote machine on the
    > end of a pipe, and forwards the data over the TCP connection (which is
    > just another kind of pipe).


    No, the terminal would start by connecting to the server; the server would
    either emulate the terminal itself or fork off a process to emulate a
    terminal; that process would fork off a tcsh with the input/output redirected
    back to itself; the inputs would come from the remote client and the tcsh
    outputs would be sent back to the remote client. The remote client doesn't
    need a shell, just the means to input and output data to the window that
    come/go to the remote server shell.

    > However, if you're running an *interactive shell*, the shell process
    > needs to be directly connected to a terminal device. (That is, a device
    > for which the Perl -t operator returns true.) Part of the mechanics of
    > doing prompting and line editing and such means that the shell needs to
    > be able to issue terminal-specific ioctls against its terminal, to
    > control things like local echo and whether characters are returned
    > immediately or wait for a return. This means that if you attempt to run
    > an interactive program with stdin and stdout connected to a pipe, it
    > won't work properly; instead, you have to run it on a pty, which is a
    > special kernel device that looks like a terminal to the shell, and looks
    > like a pipe to sshd.


    The client is the terminal device/window - the data's just going through a
    IP circuit to get there and back - hence the need to fake out the shell
    on the server to think it's talking to a terminal.
    The client is a terminal GUI that instead of sending keyboard sequences
    to a local shell, sends them to the remote shell (I think that's pretty
    simple) and accepts the shell output sequences and impresses them on the
    local same window. The only difference in the client is the shell it's
    talking to is on another host. As far as the server, it has to redirect
    the input/output of the shell it forked off to the remote client GUI.
    This is an interactive shell and GUI - not a one-shot. The shell has to
    'think' it's talking to a terminal device - doesn't mean there has to be
    one.

    > Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
    > are special functions in the Win32 API which only work if the process is
    > running directly under the control of an instance of cmd.exe. A sshd
    > running under Win32 can only implement the 'run a program on the end of
    > a pipe' scenario above, so it's useless for interactive logins.


    I think you're intimating that you can't emulate a pty through an IP
    connection on Doze. I'm hoping that's not true and worst case, if you
    have the shell source, could be fixed. The terminal GUI might be more
    of a challenge though.

    > The second thing you're talking about (if I'm understanding you
    > correctly) is remote X: this is where you're sitting at a shell running
    > on some other machine (via ssh, or whatever) and you run an X program
    > with the -display argument, and the window pops up on your local
    > display. (Or you do something equivalent that skips some steps.) This is
    > much more like the RDP case I described below (there are differences,
    > but they're not important), and, like that, it forwards a picture of a
    > window over the network rather than a terminal data stream, so it uses
    > much more bandwidth than ssh and requires appropriate GUI libraries on
    > the remote end. (In the X case the remote machine only needs the X
    > client libraries, rather than the full Windows GUI needed in the RDP
    > case, but again that's not really an important difference.)


    No, I don't need to pass graphical data, just the normal text data you
    would see at a terminal window. All I'm talking about is simulating
    a keyboard/terminal through a TCP/UDP connection to a remote host. A
    pretty simple situation if you can get the shell to 'think' it's input
    and output are a terminal device. Having a graphical interface would
    be OK, I just don't need it - I just need a text interface. An Xterm
    'is' a terminal interface GUI that runs pretty much like a Windoze
    terminal GUI, but can change hosts by invoking with an argument specifying
    host server.

    I'm still checking out PuTTY and it might have what I need ... OK, I got
    PuTTY running and I can log in and run tcsh interactively, so this does
    what I want, but I'll have to get used to the terminal GUI which is a
    bit more complicated than a normal terminal window. I can even run vim
    in the putty terminal seemingly ok, so that's a good thing.

    Thanks to all who suggested PuTTY which will do the job for now, Bill
    $Bill, Feb 1, 2014
    #7
  8. gamo

    Dr.Ruud Guest

    On 2014-02-01 06:17, Ben Morrow wrote:

    > Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
    > are special functions in the Win32 API which only work if the process is
    > running directly under the control of an instance of cmd.exe. A sshd
    > running under Win32 can only implement the 'run a program on the end of
    > a pipe' scenario above, so it's useless for interactive logins.


    This looks decent, and is free to try:
    http://www.extenua.com/silvershield

    See also: http://www.freesshd.com/
    but expect some security issues.

    --
    Ruud
    Dr.Ruud, Feb 1, 2014
    #8
  9. gamo

    $Bill Guest

    On 2/1/2014 12:16, Ben Morrow wrote:
    >
    > I don't know what that hypothetical option to xterm might do: my xterm
    > doesn't have such an option. But I suspect you're actually talking about
    > xon(1), which works exactly as I described: it makes an rcmd (terminal-
    > level) connection to the remote machine, sets up DISPLAY to point back
    > to your workstation, and then runs an X application (by default xterm).
    > This application then makes an entirely separate connection back to your
    > workstation, and sends X protocol (pictures of windows) along that
    > connection.
    >
    > Of course, this *still* needs pty support on the remote machine, because
    > xterm also uses a pty to make the shell it's running think it's running
    > on a terminal.


    Well, I think we may be talking apples and oranges. The Xterm program
    that I used years ago is probably extinct, so doubt you're still using
    it. I ran it on Solaris in the 90s running under the X11 XWindows
    server - it is a terminal emulator and could be used on like standalone
    VT220 terminals and such with the server running on the UNIX workstation
    or it could run as a window in that host or another emulating a VT220 or
    whatever. I have to assume that it has long ago been replaced by something
    bigger and better (but who knows, I still use vi [usually in the form of
    Vim] that I used back in the 80s and emacs is still around and Perl itself
    which I first used in the 80s). I'm not even sure if XWindows is still
    in use anywhere (I've been stuck on Windoze at home for years now); I
    assume GNOME/KDE and others have replaced it to whatever extent.
    I think we were running GDM or xdm Window managers back then with the
    Motif toolkit and Sun also had their own windowing system (Openlook I
    believe) which wasn't as nice looking as Motif on XWindows.

    PS: Arg to run on remote host: DISPLAY=<hostname>:0

    That being said, I'm running Bitvise SSH server on my desktop and
    PuTTY on the laptop and it does everything I described 'above' that
    I needed (trying to tweak the terminal GUI a bit to make it more
    friendly - closer to a standard terminal GUI). So apparently it can
    be done at least with cmd.exe (which I immediately ran a tcsh under).
    Not sure if it has the option of running tcsh directly (which I assume
    is what you're saying it won't be able to do); I see nothing in the
    config settings that would indicate you could change shells, so I'm
    going to assume you're right about that caveat.

    I just found reference to Xming (which uses a modified PuTTY client)
    XWindows system for Windoze - will look into that as well.

    Thanks to all for all the info/suggestions.
    $Bill, Feb 2, 2014
    #9
  10. On 2014-02-02 04:14, $Bill <> wrote:
    > Well, I think we may be talking apples and oranges. The Xterm program
    > that I used years ago is probably extinct, so doubt you're still using
    > it.


    No, it isn't extinct. I am writing this in an xterm. Since the time you
    were using it, it aquired support for UTF-8, truetype fonts and
    (probably) 256 colors, but otherwise it hasn't changed much. There are
    lot of other terminal emulators, of course, since that seems to be the
    first thing everybody who comes up with a new desktop environment or
    widget set writes.

    > I'm not even sure if XWindows is still in use anywhere (I've been
    > stuck on Windoze at home for years now); I assume GNOME/KDE and others
    > have replaced it to whatever extent.


    No. Gnome and KDE are built on top of X11, they haven't replaced it.
    They have (mostly, but not completely) replaced earlier widget sets like
    Athena or Motif.

    There is some devolopment done on new low-level graphics systems
    (Wayland, Mir, ...) but X11 is still the only system in widespread use.

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Feb 2, 2014
    #10
  11. gamo

    $Bill Guest

    On 2/2/2014 00:50, Peter J. Holzer wrote:
    > On 2014-02-02 04:14, $Bill <> wrote:
    >> Well, I think we may be talking apples and oranges. The Xterm program
    >> that I used years ago is probably extinct, so doubt you're still using
    >> it.

    >
    > No, it isn't extinct. I am writing this in an xterm. Since the time you
    > were using it, it aquired support for UTF-8, truetype fonts and
    > (probably) 256 colors, but otherwise it hasn't changed much. There are
    > lot of other terminal emulators, of course, since that seems to be the
    > first thing everybody who comes up with a new desktop environment or
    > widget set writes.
    >
    >> I'm not even sure if XWindows is still in use anywhere (I've been
    >> stuck on Windoze at home for years now); I assume GNOME/KDE and others
    >> have replaced it to whatever extent.

    >
    > No. Gnome and KDE are built on top of X11, they haven't replaced it.
    > They have (mostly, but not completely) replaced earlier widget sets like
    > Athena or Motif.
    >
    > There is some devolopment done on new low-level graphics systems
    > (Wayland, Mir, ...) but X11 is still the only system in widespread use.


    That's good to know - I miss my old days programming C on a Sparc workstation.

    I'm stuck on Windoze for almost 2 decades now and probably should have built
    myself a UNIX variant workstation to stay in the flow.

    Did some fun stuff like porting our realtime telemetry display system to an
    LSI-11 including drivers and such and then to an IBM PC (state of the art
    with a 10MB hard drive at the time - 80286 I think) reading realtime data
    off the LAN and manipulating/displaying on the console (proof of concept).

    We were paying $1000 for an external 1GB SCSI hard drive for our Sparcs back
    in those days; now you can get like 3000 times as much for like a tenth of the
    price. Time flies - science progresses.
    $Bill, Feb 2, 2014
    #11
  12. gamo

    Dr.Ruud Guest

    On 2014-02-01 20:06, Ben Morrow wrote:
    > Quoth "Dr.Ruud" <>:
    >> On 2014-02-01 06:17, Ben Morrow wrote:


    >>> Win32 doesn't have ptys; the equivalent of the 'terminal control ioctls'
    >>> are special functions in the Win32 API which only work if the process is
    >>> running directly under the control of an instance of cmd.exe. A sshd
    >>> running under Win32 can only implement the 'run a program on the end of
    >>> a pipe' scenario above, so it's useless for interactive logins.

    >>
    >> This looks decent, and is free to try:
    >> http://www.extenua.com/silvershield

    >
    > AFAICS this doesn't even pretend to support interactive logins: it just
    > talks about SFTP and running remote scripts. (Both of which are useful,
    > of course, and both of which can be done with Cygwin sshd or anything
    > else.)


    AFAICS, it also doesn't support scp.


    >> See also: http://www.freesshd.com/
    >> but expect some security issues.

    >
    > I think this was the non-Cygwin sshd I mentioned before; if it is, then
    > it tries to start an interactive shell and it doesn't work properly
    > because the terminal control isn't there.


    See also: https://github.com/traff/pty4j
    (uses libwinpty)

    --
    Ruud
    Dr.Ruud, Feb 2, 2014
    #12
  13. gamo

    $Bill Guest

    On 2/2/2014 16:22, Ben Morrow wrote:
    >
    > I
    > wonder how they got around the first problem I found, which is that
    > 'daemon' processes running from a Windows Service don't have the right
    > to create windows on the user's desktop?


    What if it has to be started manually (rather than from a service) ?
    $Bill, Feb 4, 2014
    #13
    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. balu
    Replies:
    1
    Views:
    685
    Dmitriy Lapshin [C# / .NET MVP]
    Nov 18, 2004
  2. balu
    Replies:
    3
    Views:
    554
    Ben Strackany
    Nov 24, 2004
  3. balu
    Replies:
    0
    Views:
    405
  4. Nemesis
    Replies:
    0
    Views:
    310
    Nemesis
    Jan 19, 2005
  5. $Bill

    Re: creating a custom newsreader

    $Bill, Jan 26, 2014, in forum: Perl Misc
    Replies:
    1
    Views:
    84
Loading...

Share This Page