You can choose from the plaintext-version
or the HTML-version.
What you see here is the HTML-version:
1.1 The Problem:
People who work a lot on Telnet/SSH shell accounts are often faced with
considerable difficulties if they attempt to do edit text files on
The machines they are working on may be located on remote sites and
are connected to the user through the internet. This may result in bad
terminal response times if either side has a slow network connection -
either because it doesn't have much potential in the first place (think
56k and less modems), or because most of the bandwidth is already
occupied by other services. Slow terminal responses obviously hinder
text editing because the user cannot immediately spot spelling mistakes
anymore. The user either has to type very slowly, always keeping up
with the speed at which characters are echoed back on the screen, or
he has to ignore the possbility of typos, type as usual, and go back
to correct mistakes later. Depending on the speed of the connection,
going back may be another considerable waste of time.
It is also psychologically very annoying having to wait a long time for
the typed text to appear on the screen.
Another problem is terminal incompatibilities. We are still stuck with
the archaic termcap/terminfo terminal databases and terminal
descriptions that differ widely between the various Unix systems. If
you are lucky, ansi and vt100-compatible terminal descriptions will
generally make a screen editor like ``vi'' usable, but if you wish to
use ``advanced'' features such as the page up/down, pos 1 or end-of-line
keys, you will need a more complete description of the exact terminal
type you are using - be it software-emulated or real. One help is the
ability to specify your own termcap database e.g. by using the TERMPATH
environment variable if your implementation supports it. That way, you
can copy a termcap description entry from your native system to the
remote site so that termcap-based applications can use it instead of
the system-wide database. The drawback of this approach is that it
does not apply to terminfo (you may be able to decompile and recompile
terminfo bianry files for different systems, but don't count on that)
And finally, the system you are working on may not have your favorite
text editor installed. This one is not directly an argument for using
nwpedit because the nwpedit server must be loaded on the target machine
as well before it can be used, but at least nwpedit is likely much
smaller than your favorite text editor :-)
1.2 The Solution:
If you have decided that editing a file on your account via Telnet or
SSH results in more trouble than it's worth, there are already many ways
existent ways to work around the limitations. You could, for example,
download files via ftp or ssh (scp.) Doing so would of course also
result in delays if your problem is connection slowness, but it would
certainly be less annoying than editing the files directly.
The drawbacks of these solutions:
- Downloading, editing and uploading manually any time you want to
change something is a daunting task
- With these tools you are always transferring complete files. If
you only change five bytes of a 50kb file, you will still upload
nwpedit consists of a client and a server application to automate the
work of downloading those files, loading them into your favorite editor,
and sending back your changes, if any. nwpedit can transfer either
complete files or patches, it supports IPv4 and 6, has a cache for
directory listings and files that can be used in write-through (always
commit changes) or write-back mode (only commit changes when asked to),
and it is not tied to any particular text editor application (you can
have it launch any program you want.)
1.3 Status of nwpedit:
The current version of nwpedit was developed within roughly one week of
my vacation. It still lacks many features and certainly cannot be
considered to be complete by any definition. For example, the directory
listing cache is not used yet, the distinction between write-through
and write-back is not made yet, and the option to check the cache for
consistency on every file access is not implemented yet. Generally,
there aren't many configurable options either. Worst of all, there is
only a provisionary plaintext password authentication. And the server
isn't even a daemon!
So why this release? Because I wanted to get the program ``out the door''
as soon as possible and because it actually works. I have ``started''
developing nwpedit in July 2003. The first version was so bad and full
of ugly kludges that I was never motivated to finish it. Then, about a
month ago, I finally deleted all the old stuff. And now I have rewritten
it within a week and it is already so much better and more functional.
By releasing this stuff now, I can finally prove that nwpedit is no
nwpedit is known to work on FreeBSD 4.x, SuSE Linux 8.2, HP-UX 11i, Tru64
UNIX 5.1B and IRIX 6.5.??. Client and server will soon be tested on AIX and
Solaris as well. The client may be ported to Windows NT and derivatives
in the near future.
No nwpedit development is happening anymore. I rarely use it, but when I do,
it works for me.