Modifying/Editing A Text File

[#usetxted]: Using a “standard text file” editor
Various approaches

There are multiple approaches:

Disk information editors and binary file “hex” editors

Obviously, a couple of methods include editing the disk sectors that contain the file's information, and performing a binary edit of a file. However, editing a disk sector may not be an easy route (especially if the information is encrypted on disk), and the binary file editors are often not as nice to use.

Word processors

A full-blown word processor may be used, although they often save files in a format that saves information about features including font choices, other formatting details, and perhaps even embedded objects. Such formats may not be as understandable by some software, nor as readable to humans when using some other software (later), and so the tendancy to save in such advanced formats by default makes these more advanced editors undesirable in some cases.


A software programming integrated development environment (“IDE”) often includes a way to edit text files and to show syntax highlighting for at least one programming language, and this will likely work fairly well if such a solution is installed and used properly, although such an environment may be far more elaborate than needed just for editing a text file. (This section is primarily about simple text editing, not developing code that has a highlightable syntax. For script editors, Rob van der Woude's page on Script Editors & IDEs has some information. (Despite the similarity of the last name, Rob van der Woude is not of known relation to the initial creator of this document.) For DOS, solutions included RHIDE (Robert Höhne's Integraded Development Environment) and SETEDIT; coders interested in DOS may also be interested in Free Vision.) (Coders may also be interested in the coding section.)

However, there are quite a few editors that have been designed specifically for the task of working with simple text files. That is what most of this page is all about.

[#chstxted]: Choosing a text editor

Clearly there are different preferences regarding what text editor to use: OpenBSD's man page for mg notes that mg “is compatible with emacs because there shouldn't be any reason to learn more editor types than emacs or vi(1).” Which of those two is better has been the subject of “editor wars”. “Editor war”, defined by Wikipedia, is “the common name for the rivalry between users of the vi and Emacs text editors.” Users new to this software may remember the words from The introduction of NetBSD's guide to vi, which call vi “the bane of the newbie existence.” Many newbies may find that Emacs isn't much better when there is no previous experience, guide, or friend to help guide usage of the software.

Further details on each text editing software is in the section about how to use the software.

Here are some recommendations:

text appending

The option of using redirection to append to a text file is something that newcomers typically find to be rather daunting. It also doesn't really qualify as being a “text editor”, because it doesn't allow a person to easily edit existing content inside of a text file. However, if you want to create a brand new short file from scratch, then this may be the easiest way. For the brave, Redirection to a text file (in Unix and DOS/Windows) contains the details.


This very tiny editor provides compatible key bindings, providing available functionality that would likely satisfy quite a few people if they just gave this software a try. Unfortunately, despite its small size, it isn't pre-installed on as many systems as many of the other editors. If you see this as an option, checking it out is recommended. Some usage information is in the section about using Albrecht Kleine's MicroEditor e3 (text editor).

nano (or pico)

A lot of people like “nano”. It is also pre-installed on some popular operating systems, including Debian. For people using other operating systems, many people like install “nano” as a relatively early task. (Instructions at software installation may be helpful.) Using nano (or its predecessor, pico) is relatively user-friendly, while offering some of the advantages of programs like vi or mg (which uses a subset of emacs).

The main thing to know, in order to use nano, is that the caret (“^”) represents “Ctrl”. So when the help bars show “^X” exits, that means Ctrl-X. (This is not specific to just nano. nano is simply following a common convention notating keyboard “control key” sequence input.)

The pico software is older than nano and operates relatively similar. The main difference has to do with licensing.

  • By default, word-wrap is enabled. To flip that from within the program, press Esc, and then press an uppercase or lowercase L. To set the initial state to disable wrapping, a -w parameter (--nowrap) is supported...
    • However, sometimes parameters aren't quite as convenient to use. Setting the VISUAL environment variable to use a command line parameter may work well in some cases, while it may not work as well with another command that uses the VISUAL environment variable.

    This is also like the set nowrap in a supported configuration file (/etc/nanorc, ~/.nanorc, described by “nanorc” man page, sample at nanorc.sample (e.g. /usr/local/share/examples/nano/)

  • If the Numpad isn't working, try -K (--rebindkeypad)
  • The end of the file will contain new lines. -L (--nonewlines) can change that.
  • Esc, O allows usage of the screen's second line for editing, rather than keeping it blank.

A text editor that may be even easier for basic usage is ee. The main thing to know, in order to be able to effectively use ee for simple tasks, is simply that the Esc key brings up the menu.

The ee command comes default with FreeBSD. Unfortunately, the software might not be frequently found for other operating systems. Also, the program's interface may feel a bit more cumbersome, which can certainly be less desirable. (As I recall, the user interface could use up more screen space, and some tasks may require more keystrokes.) However, for someone who is just looking for something extremely simple, this may fit the bill quite nicely if it is available.

More graphical programs

Some people like to use an editor that provides a fairly nice graphical interface, such as SciTE. Systems using desktop environments may have another text editor more conveniently available. Wikipedia's Comparison of X Window System desktop environments: section titled “Default programs packaged” has a row named “Text editor”.

vi, and either mg or emacs

Many people who have spent a lot of time outside of graphical environments have proclaimed that they like one of these text editors better than the graphical alternatives. For editors similar to vi, see: vi usage. For mg or emacs, see: MicroEMACS (mg) / emacs.

Following is some older text, which is only slightly redundant with the above, and contains some additional information.

[#txtredir]: Redirection to a text file (in Unix and DOS/Windows)

Appending output to a file, including creating a new file by specifying a filename that doesn't exist, is a very common method to add desired text to a specific filename. This method may seem cumbersome for first-timers, but it tends to be universally available (being pre-installed and widely compatible with all sorts of environments), fast, automatable, and works well. Minimalists who already have a command line readily open and available will often decide to use the approach of redirection.

Some of the following options may not always, or even typically, be the nicest way to accomplish some tasks. However, they are a minimalist way, and can be very handy to know about. They can be the fastest options. Additionally, they can be the most convenient options in some circumstances, including cases when using a full graphical user interface isn't the best option (possibly due to a slow screen refresh scenario caused by slow bandwidth connections, or possible due to simply failing to work because of compatibility considerations such as dealing with some hardware limitations) or other cases when working on a command line.

Another case where it may be convenient to simply append a line to a text file is if a desired command is already in the command line history. In that case, see the tip about copying command line history to a batch/script file.


Although this can be the quickest way to create a new file, the interface may be quite simplistic, not really allowing any sort of editing. (Backspacing might not even work; backspacing might work flawlessly, or end up storing a backspace character which might not have the desired results. The results may depend on the environment being used, including any software involved with providing a shell prompt, and perhaps also depending on the terminal/console that is being used.)

How to do this

A quick example of how to do this, is to use the following command:

echo desired-text >> output.txt

That command will also append to an existing file, if the file can be easily written to (without issues related to file permissions/attributes/ownerships/sharing). Using just one greater than sign will not append to the destination file, but will instead cause the destination file to be overwritten. That's usually basically equivalent to attempting to deleting the destination file, if it exists, before attempting to create the destination file and writing to it. (The results might be different if deleting a file, and recreating a file with the same name, has some effects like losing customized file attributes, like security settings, that may have been on the old file.)

(To check out the contents of the file, see viewing a file's contents.)

[#histscrp]: copying command line history to a batch/script file

(This technique may work well with a DOS Batch file as well as a Unix script file.) This may or may not be easier/quicker than using copying visible text in the command line history to a text file. (For a simple command line, this may go real quick. In some more advanced cases, some escaping may be needed to prevent expansion of variables or, if applicable, wildcards. In that case, a copy/paste operation may often end up being faster.)

If a command line was run one, it may be in the command shell's command line history. Once it is there, it can be pretty quick and convenient to get the command stored in a batch/script file so the command can easy be run later.

Old text: To do this, use command line history recall to bring up the desired command line. Then edit the command line by prefacing the command line with the echo command, and then redirect the output of the echo command. That can be the fastest and most convenient way to get a successful command line placed into a text file. Note that the command line may be expanded, causing things like environment variables (and, with at least some command line shells, wildcards) to be expanded. This expansion may occur before the redirection, so the resulting contents of the text file may look different than the command line. (This may be worked with/around by accepting the expansion, escaping command line charaacters, or temporarily replacing command line characters and then editing the text file.)

Newer text:

(Note that this simple guide may not have the intended effect, particularly if the command line has complicated branching, or if the “command line” spans across multiple lines by using a Unix escape character at the end of the first line. However, this guide will likely work in simple cases.)

  • Press up arrow to use the shell's command line history.
  • Add the word “ echo  ”, followed by a space after the word, to the beginning of the line.
  • Escape or replace any special characters that may be expanded/substituted by the shell, unless it is okay to simply use the modified version of the command line in the shell. For instance, in DOS, replace any occurrences of %. The Unix equivalent may be $, although Unix may also have other special characters to be concerned with.
  • Go back to the end of the line. The fastest way to do this may be to press Enter to run the command line, and then press the “up arrow” to use the shell's command line history again. (Pressing the “End” key might be a still-faster way, but may also work less well when using some command line shells in some terminal environments.)
  • If in Unix, if the command line included an ampersand (“ &”) at the end of the command line, be sure to remove that.
  • Redirect the output to a file (by adding “ >> startvm ”).
  • If any special characters were modified, including removing an ampersand from the end of a Unix command line, then edit the text file to replace the removed characters.
Text editors available in OpenBSD

A note specifically for users of emacs: Users of emacs may notice (from OpenBSD documentation) that vi seems to exist with OpenBSD, being built into not only the main operating system but also onto the installation disks. Yet, there doesn't seem to be an installation of emacs (as evidenced if one tries to run emacs from the command line). Although a full blown, extensible emacs may be available as a third party port, it is good for OpenBSD users to determine whether they can get by with an already installed program which is mostly compatible: mg. For those who would like an overview of mg, especially those who are not familiar with emacs, see the OpenBSD FAQ about the bundled program called “mg. That editor functions as a simplified emacs and it is built in. (Information on how to use the mg editor is available.)

Other built-in editors include: vi/ex/view, ed, and xedit. All of those were included for factors such as code simplicity and size, rather than heavy popularity or ease of use.

OpenBSDsupport: How to use ed to edit /etc/fstab in single user mode shows a guide written by one person who does appreciate using ed.

To install other text editors, OpenBSD users may wish to temporarily visit the section called OpenBSD: Making package management easy (which is an elaboration of using the technique listed at Packages/Ports FAQ 15.2.2: “Making things easy: PKG_PATH”.) Then also review the next section, Using OpenBSD's pkg_add, for instructions on installing nano or, if preferred, a different text editor.

In FreeBSD
For a full screen editor, the editor ee is simple enough to make minor changes with. Simply know that a menu may be accessed by pressing Esc or Ctrl-[.
16-bit DOS, including MDOS (bundled with OS/2), and 32-bit versions of Microsoft Windows

There may be a command called EDIT. (This may end up running QBASIC/EDITOR (or some very similar syntax). If so, then the copy of EDIT pre-dates Windows 95 (at least if using MS-DOS... not sure about OS/2 Warp 4). In such a case, EDIT is just a wrapper, so the much larger QBASIC.EXE file is required for EDIT to effectively work. So, do not just copy a small EDIT command without also copying the file required to make it useful.) (Side note: The QBASIC.EXE may have other uses, beyond just editing a text file, as noted by MS-DOS Editor usage section.)

If EDIT does not exist (or even it if does), another likely command is the text file editor named EDLIN. However, that is likely to be about as painful, so thid party solutions may be preferred. (As a possible example: see FreeDOS's Edit: FreeDOS page on Edit, FreeDOS Edit, Wayback Machine Archive of old home page for FreeDOS Edit. Also, text editors mentioned by FreeDOS page may provide some other options, such as Bloček which supports Unicode (and can use fonts that look like cursive, and also supports image viewing). (Regarding Bloček's name, a page about Czech characters mentions “&chacek;” but that does not seem to be supported by HTML.)


The third party package Scintilla is the basis of many editors, including SciTE (which stands for “SCIntilla based Text Editor”, according to the main site).

A benefit of using the xedit editor is that it may come with the environment. That may be about the only benefit of this unimpressive text editor.

The “Comparison of X Window System desktop environments” page at Wikipedia, section called “Default programs packaged” has a section listing some popular text editors that may be bundled with some environments. (For example, Kate (“KDE Advanced Text Editor”), for KDE, which “is a complete rewrite of the older” KWrite, according to Kate review.) Leafpad is meant to be lightweight: Xfce's Mousepad is derived and meant to add support for printing. A review of Mousepad notes, “Mousepad was originally created to bring printing support to Leafpad. Well, since then Leafpad has added printing support, so what’s the diff? Very little.”

Windows (including 16-bit versions)
[#msnotpad]: Notepad

An option is to use Notepad.exe, if Notepad.exe is capable of loading the file and if Notepad.exe doesn't have issues with displaying new-line characters. (Notepad does not recognize, and effectively ignores, 0x0A “Line Feed” characters which is what Unix uses as new line characters. Instead, Notepad relies entirely on the presense of 0x0D “carriage return” characters.) Note that at least some versions of Notepad may cause some visual errors, causing the keyboard cursor and changes (including both inserting and deleting text) to appear on a different line than what is displayed. This tends to happen after some cut and/or paste operations. Scrolling a whole screen's distance (with PgUp or PgDown) will redraw things correctly. Cutting and then pasting the whole document may also draw the editable area correctly. (If an end of line, reached by pressing the End key, seems to be acting like a visible line directly above or below the cursor, that is a good indication that things aren't what they appear to be.)

One limitation of Notepad.exe is a maximum supported file size. The precise limitation may vary based on the version of the software. With Microsoft Windows 3, KB 59578 documented a limit as low as 45KB. Also, the number of columns may be limited (to 256 columns, or perahps 1,024 colums; again the exact limit likely varies between different versions).

If Notepad limits are an issue, use a word processor such as Write/Wordpad. When using Wordpad, be sure to save in the desired format! When editing text files, that is generally going to be an MS-DOS compatible ASCII text format. (Side note: this has been a relatively little known fact: Microsoft has publicly released some source code for Wordpad, as noted on the hyperlinked page just referenced.) (16-bit versions of Microsoft Windows did not have Wordpad, but did have Windows Write. This could be started by running the write command. With newer versions of Microsoft Windows, that same command may end up running Wordpad.)

For 32-bit versions of Microsoft Windows and the older 16-bit varieties of Microsoft Windows, MS-DOS solutions may apply. For example, an EDIT command is available as part of Microsoft Windows 95, and users of Windows 3.1 may have such an option available from the copy of DOS that was used when the computer started up.

For something more elaborate, check out Sc1 (by Neil Hodgson), obtainable by Scintilla's SciTE: Download page. This is cross-platform code with few restrictions, and uses code that is also used by some other software as well. (That release might not include as much external files, like online help?) If software even more elaborate than Sc1 is desired, perhaps check out SciTE (which stands for “SCIntilla based Text Editor”, according to the main site), which is also available from Scintilla's SciTE: Download page.

Other options may include Notepad++, which has now become GPL software, or PSPad which is not open source, but which is freeware.

Atom ( was made by GitHub and has now been released as open source software using the MIT License. This editor is notably larger than some of the other ones mentioned, being over 100MB in size, and contains plugins and features that may be appreciated by people looking for something more advanced. Wikipedia's article on Atom classifies it as a “Source code editor”. The software seems to have some fans. (However, Pian0_M4n's warning to Om Shankar's question, “What is the difference between Sublime text and Github's Atom” gives cause for some concern...)

Microsoft KB Q105763 makes reference to mep as being “the Microsoft Editor available in the Platform SDK.”

Installing a decent text editor
After choosing a text editor, see the section on installing software.
Using the editors

This may seem like a simple task: In some cases it is. In cases where it isn't, a lack of being able to easily edit a text file may be quite frustrating, particularly if some more advanced things are unfortunately not being able to happen just because this task, rather simple in nature and easily accomplishable at other times, doesn't seem to be easily doable.

Editors often used in BSD/Linux/Unix-like environments

It may be useful to know that Ctrl-[ will act like the Esc key.

Using the command shell
Concatenation can add contents of one file to another. A new file may be created by starting a copy process to copy /dev/stdin to a file, such as “ cp /dev/stdin output.txt ”, and ending the file with the “end of file” (“EOF”) character for Unix platforms, which is entered by pressing Ctrl-D. This may not provide a very nice interface for being able to backspace and may not be an easy to to edit an existing file, but it may frequently work.
[#vartxted]: Common Unix variables used with editing text files
Short description

When following these directions, be careful about where dollar signs do exist and where they do not exist. ($EDITOR is different from EDITOR.)

Running the following:


That command will show what commands are run with these variables. If either of those are empty, they may be set.

On a side note, there is one other variable that seems somewhat related in concept: the PAGER variable.)

Recommended values: not empty/null

The recommended experience is for people to have those variables be automatically set whenever they login. (That way, software can rely on those variables having non-null values. That way, software can do something like run “ ${VISUAL} filename ” without worrying that the shell might ignore the unset variable and just try to execute the specified filename.

Similarly, people can do something like “ cat filename | ${PAGER} ” without concern that the output will be lost due to being piped into oblivion.

Setting the variables using a Bourne shell

The precise method will depend on what shell is being used. The concept of setting a variable is discussed a bit more by setting environment variables.

If using a shell that is compatible with the “Bourne shell”, which is most common, and if using the text editor being used is popular text editor called nano, then using the following may work well:

export VISUAL="nano -w"

That will work in most cases. In some cases, having command line parameters may not work. (There was some thought that this might be the case with vipw or visudo, but both seem to work with commadn line parameters. Perhaps it was another program, or perhaps this limit may affect older versions of one one of these programs, or perhaps the thought of command line parameters was errorneous?)

(If you encounter such a program, simply edit your variable so that you don't include a command line parameter. Workarounds can include using a script file to make a command line editor. For nano, the effect of the popular -w parameter can be mimicked withiin the program using M-L. M-L is a reference to the meta key followed by L, so pressing Esc and then L, or pressing Esc and then L, may toggle that functionality within the program.)

Full description

Some programs will attempt to open a file for editing by looking at a couple of commonly-set environment variables, and these variables may also be called directly by the command line. The first one that is often checked, although this initial check is supported by slightly fewer programs, is VISUAL. This is meant to be a full-screen editor. If the program does not find that the variable called VISUAL is set (either because the variable is not set or because the program might not support both the VISUAL and EDITOR variable names), the program may proceed with checking the a variable called EDITOR, which is meant to be a text file editor. The variable called EDITOR is sometimes (or perhaps always, at least officially) more specifically meant to refer to a line-based editor. Pointing the variable EDITOR to a full-screen editor is a technique that may violate some specification that rarely, if ever, matters. However, that technique may commonly work just fine. For command shells that are compatible with the Bourne shell (at /bin/sh), these environment variables may be executed simply by using a command of $VISUAL or $EDITOR.

Some software may ignore the environment variable called VISUAL, but may support using the variable called EDITOR. (For example, this was found with OpenBSD's vipw command. OpenBSD's manual page for vipw documents support for EDITOR, but not VISUAL. Testing was performed to check whether the documentation was just somehow incomplete, and the results of this testing showed that the software did support EDITOR just as documented, but did not support the VISUAL variable which was not part of the documentation.)

Details about how these environment variables are set (automatically) may vary based on factors like what shell is being used. Such details may be available in the sections about operating system environment variables and, for details about automatically setting up the variables, details might be in the section about system startup processes and/or in documentation specific to the operating system being used.

In practice, setting command line arguments in the variables (by using a space in the command that is run, and using quotation marks to surrounding the command that will be run) may sometimes work, as programs may just execture the variable name if the variable is set. However, other software may check that the variable points to a file, and so including a space and command line parameters in the value of the variable, with the entire value of the variable surrounded by quotation marks, may end up not causing the desired effect. (If the value of the variable points to a text-based script file that runs the desired program with parameters, though, that may effectively work around the issue in a more compatible way.)

The editor may be a full-fledged dedicated text file editor, such as nano, or it may be a script. Typically it may even be a command line shell, although what may be nicer is a script that outputs passed command line arguments. Such a script may allow one to know which file was the file to be edited by whatever software called the environment variable. (In some cases, such a filename may be a temporary file with a rather random-looking filename.) So, one way to deal with nano word-wrapping unless -w is specified is to not run nano directly, but to set an environment variable to run a script which then runs nano -w as desired. (A script as simple as “nano -w $1 ” might be sufficient for accomplishing this task. Another approach, rather specific to nano, which hasn't been tested yet... could be to run “ echo set nowrap >> ~/.nanorc ”.)

There are some reasons to use these command line variables instead of just typing the name of a familiar and desirable command. First, if a program wants an end user to edit a text file, or wants to provide a menu option to run a command that edits a text file, these commands run an editor and presumably is the editor that the end user knows and prefers. (That presumption is based on the notion that the end user will customize these variables if desired.) Second, an end user who does not use the system frequently can often just run something like “ echo $VISUAL / $EDITOR ” to quickly find some options of text editors that probably are installed on the system. When there's a desire just to get a job done, using a known (even if unpreferred) editor that is installed may be quicker than trying to check for preferred editors (or installing one if the preferred ones aren't found).

Visual (windowed/full screen) text editors for Unix

This may be run with variables for running an editor.

[#viusage]: vi

From within vi, help may be obtained by pressing the Escape sequence (either the Esc key, or Ctrl-[) twice, and then typing :h (and pressing Enter).

The introduction of NetBSD's guide to vi calls vi “the bane of the newbie existence.” Although OpenBSD often endorses their excellent documentation, treating it as “authoritive”, the OpenBSD's manual page for vi “is intended for users already familiar with” the software. “Anyone else should almost certainly read a good tutorial on the editor before this manual page.” It is as if the software was considered to be too complex to have the “man page” be a sufficient introductory guide.

Saving and exiting

Here are some instructions, as dictated in clearly spoken phoenetic English: To save a file while exiting, all a user has to do is hold down the control key and press left square bracket twice in a row, then release the control key, and type colon double-you cue exclamation point, and then press Enter. What's so unintutive about doing all that?

Of course, the colon and the exclamation mark will require holding down the shift key, while the letters in between those symbols will need to be lowercase. Anything else would be easy.

(Those instructions were written out phoenetically because they seem a bit more forboding that way, to illustrate a bit more clearly about how ridiculously long of a sequence it is. However, it can be abbreviated a bit. First, know that pressing the [Esc] key is usually equivalent to the Ctrl-[ control keyboard sequence. So a bit of an easier sequence is: [Esc][Esc]:wq! and [Enter]. And, there is a special keystorke sequence that is slightly shorter, though less similar to many of vi's other commands.)

The vi software continues to be used despite any unintuitiveness because there are some advantages which include:

  • a very small size (which is nice for anyone trying to cram functionality into a small amount of disk space)
  • high portability
  • very few requirements about the video interface (to be able to do every basic task that vi does)

The vi command may also be the same executable as the editor “ex” which doesn't even require a full screen interface.

Because of some of these advantages, vi may be an available option in many scenarios, so being able to use vi can be handy when other scenarios aren't so conveniently available.

Usage guide

This editor has multiple modes, and this may affect how the editor responds to much of the input that it may be given. If it is at all questionable what mode is being used, simply press Esc twice to get into “command mode”. If Esc does not seem to work, then try Ctrl-[ instead of the Esc key.

Once in command mode, one can enter some commands. The simplest command to know about may be to type :help and press Enter. Namely it mentions some other commands that can be used at the prompt from which commands for the editor may be specified. Those commands include :viusage followed by Enter and :exusage followed by Enter. (The help refers to “<CR>” which stands for “carriage return”, the thirteenth ASCII character which is generally a character that gets generated when pressing the Enter key.) The commands in the :exusage help are probably also available for those using vi's interface.

To quit: Once in command mode, type :q! and press enter.
To write the file before quitting, once in command mode, type :wq! and then press enter.
(A faster way to quit and save is to go to command mode and press the capital letter Z twice, with no need to press enter.)
To start inserting characters: go to command mode and press the lowercase letter i.
To delete a character, go to command mode and press x. This doesn't seem to work well to delete a newline character.
To cut a single line (replacing any previous lines in the keyboard), go to command mode and type dd.
To move the cursor, arrow keys and cursor movement keys (particularly PgUp and PgDown) may work. If they don't, go to command mode (by pressing the Esc key/sequence twice) and press the letters h, j, k, and l (which are all next to each other on a QWERTY keyboard layout) as needed to move the cursor in the direction(s) needed.

The following commands may help further.

To start a new search, go to command mode and press the / key. Searching again for the next occurrance can be done by going to command mode and pressing n. Searching for the previous occurrance can be done with a capital letter N.
To paste the last line that was cut with the dd command, go to command mode and press the p key (which officially stands for “put”).
u may undo (an action) and U may undo (changes to a line).
G will go to the end of the file. To go to a specific line in a file, press colon (“:”) and then type a line number (e.g. :1) and then press Enter. (That is assuming that vi is in command mode.)

Further details are on a Guide to vi on NetBSD's site which, among other information, notes that NetBSD source code “contains a lot of useful documentation on (n)vi and ex, in the /usr/src/usr.bin/vi/docs directory.” Further details are on that page.

[#nexview]: ex, view, nex, nvi

The command “ex” may be the same binary file as vi, and edits by lines. Technically the ex interface may not be a full screen/visual editor. However OpenBSD's man page on ex, vi, and view notes, “ex and vi are different interfaces to the same program, and it is” (possible) “to switch back and forth during an edit session.

 view is the” (equivalent) “of using the -R (read-only) option of vi.” Later that man page states, “nex/nvi are intended as bug-for-bug compatible” (replacements) “for the original Fourth Berkeley Software Distribution (4BSD) ex and vi programs.”

Wikipedia's page on the “ex” text editor states, “The original ex was an advanced version of the standard Unix editor ed”. As such, the interface used by the ex command may be similar to that of the edlin editor.

This is simlar to vi.
This program has the string “vi” as part of this name. The editor may be similar to vi.
[#mgedtuse]: mg

(It may be helpful to be familiar with the concept of the “Meta key”. Some tutorials may refer to that key. However, that key may not be needed for some of the simplest operations.)

  • To exit, and be asked about saving first, use Ctrl-x followed by Ctrl-c. (However, if no filename was specified, mg might not ask about saving first, and may just quit.)
  • To simply save, use Ctrl-x followed by Ctrl-s.
  • To abort a process, use Ctrl-g.

For more details, see the tutorial file that is part of the source code. This may be found from mg tutorial: latest version. (That actually points to the development version of the tutorial. OpenBSD FAQ 8: section about the mg editor which have a hyperlink that points to the latest released version of the tutorial.)

One may also check out the man page for (OpenBSD's) mg editor.

Some of these resources are located on websites related to the OpenBSD project. There is a reason for that. Wikipedia's page on the text editing software called “mg notes that “An expanded version of the original is included as part of OpenBSD.” Portable version of mg notes that the software is “a portable version of the mg maintained by the OpenBSD team.”

The latest version of OpenBSD's tutorial on mg may also be found from the mg tutorial CVS page. For instance, it may link to revision 1.5 of the tutorial for mg.

[#edteeuse]: ee
Press Escape (or Ctrl-[) to access the menu. (This software may come with FreeBSD and be a package for OpenBSD.) (Hugh's Web Page) (the home page for ee) describes this program as being a “subset of” another editor, aee.
[#nanousag]: nano

For those who are not familiar with emacs or vi, a popular editor has been nano. There are three main things to know about nano for most users to feel comfortable with it:

  • A sequence of a caret (“^”) followed by a letter, such as “^G”, means to hold Ctrl and then press the letter (and then releasing Ctrl). (This is a fairly common standard: specifically the program is generally looking for a lower-case version of the letter. Some programs use a notation like ^-G, although that is less common.) nano also supports using the Esc key twice followed by the letter: Alternatively holding Ctrl and pressing [ once (and then releasing the Ctrl key) is a way to simulate pressing Esc once.
  • To save a file, the keystroke combination to use is the one that help shows for “WriteOut”. (The combination is ^O.)
  • nano has word-wrapping enabled unless running with the -w command line parameter (which makes nano operate... umm... “wraplessly”? The -w parameter seems to officially stand for “--nowrap”.). e.g. “ nano -w fileToEdit ”).
    • You can also enable or disable the feature from within the program, using Meta-L (“Long line wrapping disabled”). Just press Esc once (not twice), and then L, to toggle.
    • A similar feature is available with Meta-$

The following may be figured out fairly easily simply by reading online help, but here is a brief overview anyway. To exit (being prompted to save a file if there is unsaved work), use ^X. To save a file (without exiting), use ^O to WriteOut. To insert contents of a file (which is how to open a file if a blank file is shown), use ^R to read it. To search, use ^W to see Where the text is. (Warning: Getting too much into the habit of always using ^W to search, even in other programs, may not have the desired impact: some programs will close their window (so the entire program closes) if pressing that shortcut key combination.) To search in a case-sensitive fashion, use ^\. For other commands, like M-M (where “M-” denotes Meta- and can be done by pressing Esc once, so that may be done before pressing the letter that follows M-) to enable mouse support (although that may be impacted by things such as the graphical environment being used, or the terminal's compatibility with the mouse).

The editor called “pico” has been largely replaced by a similar editor named “nano”. For more details, see the section about nano, as the two are likely similar enough that being comfortable with one will allow one to use the other rather comfortably.

One neat thing about pico is that it integrated quite smoothly with an E-Mail program called “pine” (which has since been replaced as well, by alpine).

The primary motivation for the migration from pico to nano may have been that pico's license was rather restrictive. The program called Pine also had similar licensing concerns. In Debian mailing list article about Pine's freedom, Richard Stallman refers to “a program” ... “released by U of W” using the license wording that was used by Pine. That description (a program by UW using that license wording) also applies to Pico. For details about these licensing concerns, see information about Pine E-Mail client and MANA E-Mail client. The University since released the Alpine E-Mail client under different licensing. However, the success of nano basically meant there wasn't much of any need to do a similar thing with pico.

[#emacs]: emacs, MicroEMACS

The Emacs software is fairly complex. (It has built-in support for a windowing system, and can run other software. The software has been compared to an operating system.)

Many of the simplest keystrokes are identical to mg. To reduce unnecessary duplication, details are just showin in the guide to using mg. That simpler text editor supports at least some of the same commands as Emacs. So, try that guide first, to see if it provides the desired information of basic functionality. Then, for additional information, if desired, read on from here.

[#endemacs]: Closing Emacs

For Emacs, there are a couple of ways.

^X ^C

The most common is to press ^X ^C (that is, hold Ctrl, then press X, then press C, and then release Ctrl).

The user may be prompted one or more times. If a user responds to a “yes”/“no” question by entering an answer that is abbreviated down to a single letter, Emacs politely insists, “Please answer yes or no.” Prompts may include:


The user may be prompted about saving changes. (e.g.: “Save file /full/path/to/filename? (y, n, !, ., q, C-r, d or C-h)”).

(That may not make much sense when Emacs is being used as a front-end for the program called gdb, but remember that Emacs is primarily considered to be a text editor. So, even if using Emacs as a front-end for the GDB program, this prompt may show up.)

Exit anyway (despite modified buffers)

Modified buffers exist; exit anyway? (yes or no)

Leaving a program

If Emacs started another program, the following prompt may be seen:

Active processes exist; kill them and exit anyway? (yes or no)

For instance, this may show up if Emacs started GDB, and GDB is still running. If the desire is to quit both Emacs and GDB, then go ahead and say yes to this question.

The correct answer to provide will depend on the question. For instance, to exit without saving, the desired answer to the first question (Save?) may be no, while the desired answer ot the next question (Exit anyway?) may be yes. So, take the time to actually read the question that is being asked. Doing so may help to successfully exit the program more quickly.

There is another way to close Emacs without being prompted. This way might commonly be longer, but is covered here anyway. Start by pressing Meta-x. (It is helpful to be familiar with the concept of the “Meta key”.)

Emacs should show an “M-X ” prompt. At that prompt, type:


After the user presses Enter, Emacs quits. lists some key bindings. Viper mode allows Emacs to emulate the vi interface: To load viper mode using interactive methods, either press M-x (either hold Meta and press x, or hold Alt and press x, or press Esc and then press x) and then type “viper-mode” to enter, or similarly press M-x and then type “viper-go-away” to disable viper mode, or M-x followed by “toggle-viper-mode”. See Viper info: Loading Viper (another copy: Loading Viper, yet another copy: Viper info: Loading Viper).

Regarding the name of EMACS: EMacs Endorsed by AOOS (humor page), which might be in share/emacs/(version)/etc/JOKES, suggests the name may stand for: Esc-Meta-Alt-Control-Shift?

[#usagxedt]: xedit

The “Restrictions” section of the xedit man page (at understates things: This “simple text editor for X”, as it is titled on its man page, cannot save or load files with the keyboard: The “Commands” section has buttons to perform these actions with a mouse. Similarly, copy and paste operations need to be performed with a mouse (using the platform's standard copy and paste mechanisms). (There are some keybaord shortcuts listed in the section called “Editing” of the xedit man page (at, but they don't perform these simple operations.) A large chunk of the screen is dedicated to a “Message Window” rather than the text file being modified.

Despite these characteristics that cause xedit to not be a very good editor, it does come with X and so, unless it has been removed (which does happen with some operating system distributions), may be readily available if X is working. However, it may be better to find, or install, another editor, such as nano, gedit, Kedit, Kate?, or a word processor such as abiword.

[#edte3use]: Albrecht Kleine's MicroEditor e3

This section is about some GPL'ed softare by Albrecht Kleine, called “e3 Editor”, and is unrelated to E3 IBM. (For information about that, information about IBM's E text editor, third release is available.)

The program identifies itself as “MicroEditor e3” (followed by a version number and Copyright reference indicating a copyright starting in the year 2000, attributed to “A.Kleine”. In Microsoft Windows, this may show up on the first screen, but then the screen may scroll down to a prompt asking for a filename, so this message might only be seen if scrolling back up (in the command prompt window). The README file says “README for mini editor e3” (followed by a release number).

Overview/home pages e3 Editor seems to be the current home page for the most recent version. Note that some operating systems may not have a readily available executable file for the most recent version of the software. information about Albrecht Kleine's GPL'ed MicroEditor e3 (text editor) mentions that version 2.7 may have some more ports created than some of the newer versions (2.7.1 or 2.8). (For instance, at the time of this writing, the e3 executable files for DOS and 32-bit Microsoft Windows use using an older version number than what has been released for Linux. That is not necessarily a bad thing, as the enhancements may largely be designed for improved compatibility in the Linux environment, and do not reflect changes needed for some other versions.)

(non-informative) home page for e3 (previous home page for e3?), Wiki on this cites GPLv2, support for multiple operating systems, and multiple keymaps that make it able to act like several other editors. Club DR-DOS Wiki: section on E3 cites a couple of filesizes: DOS-only 4KB and DOS+Win32 dual-mode executable at 20KB. (Further details are in the section about e3 for DOS and 32-bit Microsoft Windows.) more info on the program. Be forewarned that freshmeat page cites some interesting permissions handling (at least in an old version).


Except in vi mode, help may be obtained by pressing Esc and then H, or by using Alt-H. information about Albrecht Kleine's GPL's e3 editor indicates that some versions are limited to WordStar keysets only, and discusses that topic a bit further. However, most releases will allow the user to switch editing modes.

When in Wordstar mode, Ctrl-K followed by Q will either quit, or prompt about whether to save a file first (and then quit).

Choosing a mode

In some executable files for this program, the user is able to switch “modes”, which essentially loads different key bindings. Whether this is possible or not can simply depend on which executable file is used.

To switch editing modes, enter two key sequences. 01234567890123456789012345678901234567890123456789012345678901234567890123456789

  1. For the first sequence:
    • If in Wordstar mode, the first key sequence is Ctrl-K, then M (or Ctrl-K, and then m).
    • If in Pico mode, the first key sequence is Ctrl-Q, then M.
    • If in Emacs mode, the first sequence is Esc and then X, or Alt-X.
    • If in Nedit mode, the first sequence is simply pressing Ctrl-E.
    • If in vi mode, the first sequence is Esc and then ;. (Ctrl-[ should be able to work instead of Esc, at least for vi, and probably for any of the modes since most non-graphical programs and the terminals they run in treat Ctrl-[ like Esc.)
  2. For the second sequence, type e3 followed by two letters (from the upcoming list of valid possilities), and then press enter. Those letters may be ws for Wordstar emulation, pi for Pico, ne for Nedit, vi for vi, or em for Emacs.
Choosing an executable name

With the release for Microsoft Windows, switching key bindings while the program is running is an unavailable feature, unfortunately. However, different key bindings can be used by making a copy of the executable file, and giving it a name that starts with “e3”, followed by two letters representing the key binding mode (ws, pi, ne, vi, or em). E3 Keybindings

Kinesics Text Editor

Kinesics Text Editor for Windows/Unix/Mac has a graphical program and a version designed to be run in the text console. It is free, although the license specifies that distribution is limited to free distribution.

At least in the console version for Microsoft Windows, the menu can be shown with Ctrl-] (Ctrl and “Right Square Bracket”) or F1. Or, Alt-F will go straight to the File menu.


Some IBM operating systems came with text editor(s) found in MS-DOS releases. (Try running EDIT: Details on the MS-DOS Editor may apply to the program that runs.) In some versions of OS/2 and some verions of IBM PC-DOS, there is TEDIT. (From someone who contributed to the development of the “E” series of editors, Davis Foulger's commentary on E says that TEDIT came at OS/2 4.0. However, at least some site staff believed it had come earlier with OS/2 3.0 or 2.1.) (There is a Wikipedia page for the E text editor from PC-DOS.) Another OS/2 option, which would be graphical, may be EPM.

Editing text files using tools designed to be run in text mode, either from interacting with a command line, or line-based options
May be able to use the stream editor: sed or piping a script into another program such as ed.
[#sed]: sed: the “stream editor”

Command line based, this may be a bit more difficult to use for the inexperienced to pull off a one-time operation, but may be among the easiest of options for a process that may be repeated. Since search and replace may be a fairly frequent task, learning the basics of sed can quickly pay off in the form of time savings.

A guide on sed starts with The Awful Truth about sed. For convenience, roughly half of that section is quoted here:

sed “is very simple, but the documentation is terrible.” Some “on-line manual pages for sed are five pages long, and two of those pages describe the 34 different errors you can get. A program that spends as much space documenting the errors as it does documenting the language has a serious learning curve.”

After that topic, the guide discusses using sed for searching and replacing text. Although the sed program is fairly flexible and can be used for different things (as described below), its most famous and common usage is for replacing strings.

For an operating system which supports sufficient redirection and processes quotation marks, the simple syntax for a “global” search and replace is:

sed "s/oldtext/newtext/g" < input >> output
Alternate forms

In Unix, the above is essentially the same thing as:

cat input | sed "s/oldtext/newtext/g" >> output

In DOS (and similar platforms, including Microsoft Windows), the corresponding syntax would be:

type input | sed "s/oldtext/newtext/g" >> output
Getting sed for DOS

However, in DOS, sed is not typically pre-installed. sed for DOS/Windows

When using this form, which uses pipes, the text gets sent to sed's “standard input” stream, just like when the < operator is shown. So, from sed's perspective, there is no real difference to these ways of running the software.

editors.sed.user message # 00074 indicates there is an even simpler option:

sed "s/oldtext/newtext/g" input >> output

This relies on sed to access the specified filename, instead of relying on the “operating system” to open the file and sending the contents to the sed program.

sed's “global” option
sed's customizable delimeter

Ignoring the quotation marks for a moment, note that character after the first letter of the initial parameter, the / after the letter s, is the “delimiter”. Although it may most commonly be a slash, a different character may work. The later two deliminators, which are slashes in the above example, need to match whatever the first deliminator is.

One thing the Sed guide correctly mentions is that the delimeter can be customized, so the character after the letter “s” is often a colon, or an underscore, although a slash is also used often when the text to be changed does not include a slash. The website also shows an example of using a pipe. Note that using a pipe may be rather problematic. In the example, a pipe is used inside apostraphes. Those apostraphes may cause the pipe to be interpreted as being part of a string, but whether that happens or not is rather shell-dependent. To encourage good habits that work on a wide variety of systems, using a pipe is not recommended.

tougher characters

Special characters can complicate things. There are generally slick workarounds for those willing to play around with things like “extended regular expressions”. However, different versions of sed may support different expressions/extensions, so do be careful and sufficiently test results before trusting them. For those who are looking for dead simple, rather than slick, any weird special character might be able to be referenced by using something like \d090 (for the decimal ASCII code 90) or \x5A (for the ASCII value corresponding with the hexadecimal 5Ah) for the capital letter Z, or \u0090 for Unicode. Again, though, there are some variations that may make such syntax not work so well. (sed FAQ 2.2 indicates that Howard Helman's 1991 version supported using \x.) If a character isn't responding as expected, some versions of sed may respond better to using a single backslash (“\”) character before some characters such as quotation marks and spaces.

This is all referring to the syntax as sed sees the syntax. The command line shell being used may have its own methods of interpreting characters, leading to other escaping being required (quite possibly in addition to the escaping that sed requires). For example, when running in a JP Software command line shell, sed may want quotation marks backslashed and the JP Software may want them escaped using the %= escape, resulting in something like \%=" to refer to a single quotation mark. An sh-compatible shell will require different escaping, including using multiple backslashes.

Because of the various escaping required, using something like \x(hex-number) may be more convenient. By escaping all non-alphabetic and non-numeric characters (including periods) in this way, one won't have to worry as much about whether the character might be treated by sed to have a special meaning, such as being part of an expression. However, only some versions of sed really support escaping characters with \d(decimal-number) and \x(hex-number) and \u(number-referencing-unicode-position). In some cases, finding and using a more advanced version of sed may be more productive than trying to use an older version.

Other possible uses of sed

To change only the first occurrence of a line, leave off the g after the third slash (but do not leave off the third slash).

For many other options, seek additional documentation. 1-line sed commands shows some options as well as mentioning version requirements for some of the example commands. A resource which looks promising is the web page which is hyperlinked above and which starts with the section, The Awful Truth about sed.

The sed program can be used for different things. A “turing machine” has been programmed with sed, proving quite a bit of flexibility. (See Discussion about sed being Turing-complete.) So, sed is flexible enough to be used as a programming language. Entertaining options have included:

[#sedtris]: sedtris

Sedtris (sed), Sedtris's Unix Shell Script

Julia Jomantaite's sedtris has been described as a Turing-complete Tetris-like game; According to Reddit article mentioning sedtris, the player presses Enter to move forward in time)

YouTube: sedtris

(which looks like might be more similar to Breakout than Arkanoid)
By the same author as sedarkanoid

Getting sed:

[#sedoswin]: sed.exe Binaries for DOS and/or Microsoft Windows
sed for Microsoft Windows

There are a few options provided for Microsoft Windows.

ssed and GNU sed
seder's Super-sed

seder's ssed: “super sed” had been briefly tested and supported escaping characters (using hexadecimal, \x##). Version 3.62 has been the latest version for over a decade (February 11, 2005, until at least 2016). Despite the zip's filename of sed-*.zip, the included file is named ssed.exe. A UPXed version is being distributed by ZIP file of seder's Super-Sed 3.62 after being UPXed with UPX 3.94w --ultra-brute.

(In contrast, GNU utilities for Win32 used an old sed-3.02 which did not provide character escaping and did not seem to provide a simple way to include a “newline” character in the replacement text.) The ssed.exe “super sed” also was one simple binary which worked, unlike GNUWin32 sed for Windows which had additional dependencies (listed in the bottom “Requirements” section of the GNUWin32 “sed for Windows” page). The version 4.2.1 of Sed released on December 27, 2010 presumably breaks compatibility with Win9x/NT, based on the January 1 announcement that compatibility would break; GNUWin32 sed 4.2-1 appears to have been released before then.

Another option may be provided a part of busybox-w32. See: busybox-w32 v1.28.0-FRP-1601-gc87d9b4b2 executable bundle (described a bit more by Winsh)

sed from MSYS

MinGW sed for MSYS may suffice, though MinGW's page on MSYS has a section called “MinGW build VS MSYS build” that notes some different escaping that may be needed as slashes convert to backslashes(at least when in MSYS's shell).'s page “MinGW & MSYS on Windows” noted some difficulty with the sed.exe that came with MinGW but not MSYS:

if sed was compiled and link using MinGW, MSYS will treat it as a native application and will try to change "/" to "\" to compensate for the difference between UNIX path and WIN32, resulting in unpredictability when used under the MSYS shell.

If you wish to use this, use 7-Zip (twice) to crack open the needed *.tar.lzma and *.tar.xz files:

  • the *bin*.tar.lzma file (from )
  • MSYS: gettext to grab msys-int-8.dll from the libintl* file
  • MSYS: libiconv to grab msys-iconv-2.dll from the libiconv*dll* file
  • msysCORE to grab msys-1.0.dll from the msysCORE-*bin-*.xz file (which also contains some other unneeded files)
sed from DJGPP
DJGPP v2 GNU software should have a DOS version which may work in 32-bit MS Windows. (Does it have any dependencies such as CWSDPMI?) However, it won't work with 64-bit Windows.

sed downloads for DOS

sed FAQ: quitting part way through seems specific to a DOS port.


For Microsoft Windows, see reptxt32 from LTR Data small command line utilities, which is a small executable file with source code available.

ex, nex
Although the ex editor is line-based and the main ex interface may be used even in an environment which does not support the full-screen interface of vi, the software may switch to vi mode by inputting the vi command and an ex prompt. Therefore, it seemed justified to place most of the information in the section about full screen editors where the ex (and nex) information may sensibly be discussed right by vi. That section will refer to Cyber Pillar's guide for the the edlin editor since that guide is also meant to cover ex.
[#edtxtedt]: ed

Wikipedia's page on the “ex” text editor states, “The original ex was an advanced version of the standard Unix editor ed”.

A couple of the programs on this web page, the ex command (described by the section on ex and extremely-similar programs) and the edlin editor, were very similar to ed. As such, a combined guide is or will be provided to cover multiple of these editors. That guide is currently in the section about the edlin editor. The guide was designed to provide information needed for interactive editing.

OpenBSD's manual page for ed: “Description” section has a couple of notes about scripting. The -s parameter is recommended, and using the H command at the start of scripts is recommended. Also, quitting twice may help prevent the program from not exiting, as described by OpenBSD's manual page for ed: “Diagnostics” section.

chaos's answer to Miloshio's question at discusses a case where using ed may be better (or, at least, more convenient) than using sed, and the answer demonstrates having ed receive commands through a pipe.

[#dostxted]: Editor(s) in DOS-compatible environments

Most of the DOS editors are full-screen editors. Lacking those, text file redirection may actually be the most convenient. Lacking that, there may be another option or two, although they may not be the easiest.

[#msdosedt]: MS-DOS Edit (and the similar program from IBM's OS/2)

Some further details, like version numbers, may be able to be provided here. The later versions of MS-DOS edit the following features not found in the QBASIC releases: Editing multiple files, hex-editing (with /78 or other numbers), and a smaller size. (It also might be less prone to being specific to a certain DOS version?)

The following may also be relevant to the version bundled with OS/2's MDOS.

The older versions, included with MS-DOS 5 and MS-DOS 6.x (6.0, 6.2, and 6.22), were bundled in with the QBASIC.EXE application. QBASIC was a trimmed down version of Microsoft's QuickBASIC which could create executable files. However, if QBASIC was started with a command line switch of either /ED, /EDI, /EDIT, /EDITO, or /EDITOR, then it would identify itself as a text editor.

On a side note, for MS-DOS 6.x versions, if QBASIC.EXE was run with /QHELP, it would show as the online help. (This file may not have been included with 32-bit versions of Microsoft Windows that came with MS-DOS Editor 2. However, Microsoft made the file available to downloaders: QBASIC.EXE and HELP.HLP were included in a downloadable OLDDOS.EXE distributed by Microsoft, described further on MS-DOS page on TOOGAM's Software Archive.)

Wikipedia's page on MS-DOS Editor: update by Wendy.Krieger notes that by renaming the help.hlp file to edit.hlp (which would make the MS-DOS Editor's help file unavailable from within the program), the MS-DOS help files could be made available within the editor while the editor is editing text files. This could allow text from the help.hlp file to be copied, and then pasted into a text file. (At the time of this writing, this fact is currently unverified by Cyber Pillar's staff, but seems probable to be true.)

So all the EDIT and HELP.COM commands really did is run QBASIC.EXE with the expected parameter to make the desired functionality active. Copying just EDIT to a location (like a floppy disk) and running EDIT without QBASIC.EXE in the path would not result in a working editor.

The program supports common user access (“CUA”) controls such as Shift-Delete to cut and Shift-Insert to paste, and has nice menu options as well as working with a mouse. About the only real secret of this nicely intuitive user interface is that Ctrl-P is meant as a sort of escape character to indicate that the next character input is meant to be text to be put into the file, not a control character for the program to interpret. (Perhaps this also affects the search field?) So although pressing the Esc key will generally exit back out of a menu, and so have no real effect when inputting text, Ctrl-P follow by the Esc key will cause ASCII code 27 (generally a left arrow) to appear in the text. (However, I believe there is a character which is not easy to input even if Ctrl-P is already input. Perhaps Ctrl-L.)

[#msedit]: Matuesz's Saucy Editor

Matuesz's Saucy Editor is for DOS and looks quite similar to Microsoft Editor. It may be enjoyed by people who aren't using an editor based on the code from Microsoft Editor, but remember and prefer its style. An old home page for the software (@ ) notes that “MSEDIT features also a FB mode (has to be invoked using the /fb switch). This mode allows to compile and run FreeBASIC source code from within the editor.”

Matuesz's Saucy Editor (Project Page @

[#e3edtdos]: e3 for DOS/Windows

This very tiny editor provides compatible key bindings, providing available functionality that would likely make quite a few people relatively happy if they just gave this software a try. Unfortunately, despite its small size, it isn't pre-installed on as many systems as many of the other editors. If you see this as an option, checking it out is recommended. Some usage information is in the section about using the e3 editor. page about e3 mentions itself as a home page for the DOS/Windows release. At the time of this writing, this was at version 2.7.1 with a 3,905 byte E3-16.COM file for DOS (which UPX can shrink to 3,299 bytes, reducing the size to under 85%, although that resulting file hasn't been tested by the author of this text), and a 19,464 byte E3.EXE file for 32-bit Microsoft Windows (which can be reduced down to 17,920 bytes with UPS compression applied). However, the result of UPX compression on version 2.7.1 is a broken executable file that does not work.

( information about Albrecht Kleine's GPL'ed MicroEditor e3 (text editor) references a e3 2.7.0 tarball (gzipped) that contains executable files for nine platforms, including DOS and 32-bit Microsoft Windows. The E3.EXE file for 32-bit Microsoft Windows is 19,464 bytes, which can be reduced down to 17,920 bytes with UPS compression applied. (Yes, these are the same file sizes as noted with version 2.7.1.) However, unlike the version 2.7.1 that was just noted, the executable file produced when UPX compresses version 2.7.0 will be a working file.

When tested, the 32-bit Microsoft Windows version seemed to delay significantly after the keystrokes to exit the program. The delay was close to 30 seconds. It also seemed to place the command prompt to the top of the bugger, without clearing later buffer contents, causing a weird effect of having prior screen contents show up when the command promt scrolled downward.

[#edlin]: The editor known as edlin

A lot of this section is preliminary material. It is the long term, though lower priority, plan to place a guide here which works fairly well for both edlin and nex.

The edlin command may have been the primary option in DOS offerings that pre-date MS-DOS 5.0. This command may be similar to ed, a text editor for Unix/BSD. This command has been described as being a stripped-down version of ex, which is an editor for Unix (and, naturally, also similar to nex since that is an editor for Unix which is “intended as bug-for-bug compatible” to nex: The quote is from OpenBSD's related manual page). Therefore, knowing ex may be enough to help one accomplish some tasks with edlin, whereas knowing edlin may be enough to accomplish those same tasks in ex and similar.

Microsoft documentation about Edlin (part of Windows XP documentation) notes, “This tool is not available on Windows XP 64-Bit Edition.” Similar edlin documentation is at Edlin sub-commands.

See MS KB Q97835: Using Edlin. (KB Q97835 suggests an off-line version of COMMANDS.TXT may have some information.) Online Edlin information may have been similar.

The following might work. It is based on reading some Edlin documentation and trying to accomplish the same thing with a different editor which may be similar.

Note that many commands reference using line numbers, although the period (“.”) character may be used to reference the “current” line.

Trying to get help
In EDLIN, the command is ?. In ex, the command is h. In the earlier ed program, the command is also h but isn't nearly as useful: Instead of providing useful help, the h command shows a very sparse description of the last error that has been encountered. (H might be a bit more useful, toggling automatic displaying of sparse descriptions when errors occur. OpenBSD man page for ed has recommendations for when scripts are used, including starting with the H command.)
Input the q command (by typing q and pressing enter) to quit.
Press the Enter key on a line by itself to view the contents of the current line, and to advance to the next line.
Press 1 and enter to go to line number one and then view the contents of the current line and advance to the next line.
w optional-filename
Use w to write to the current file, or w output.txt to specify the filename that should be written to and then proceed to write to the file.
May save and then exit/end.
# i
Use the “1 i” Start inserting lines before line 1. To stop entering lines, input a line which is just a period (in ex) or perhaps Ctrl-C (may be needed for edlin) or EOF (Ctrl-Z in DOS, ctrl-D in Unix).
# d
Use 1 d to delete a line
1 t required-filename
Use 1 t input.txt to read the contents of that file and then transfer those lines into the current file, inserting them before the specified line.
Read from disk and append.
Commands that differ between ed and edlin
In Unix ed, search with /searchtext (e.g. /abc). (Many other Unix commands may use slashes before search functions: examples include ed, ex, grep, less, and more.) Unix ed may use an s command to allow for substituting. In Edlin, s may search and r may replace. EDLIN users should be careful, if ever transitioning to ed (or possibly other commands), that the s command is meant to substitute, not search safely (by being read-only).
Note: There might be more.

Additional capabilities: search, substitute/replace, move

Another tool that may be able to accomplish editing a file may be the debug command. Further details on using debug to accomplish the task of editing a file are details which are not currently available here. The command may also be powerful enough to be dangerous, and this might not be an easy and effective route even if one knows how to do that. TechNet Library Archive: MS-DOS: Details related to Debug (and other topics) may represent some official documentation related to this program.

[#cnvfmtxt]: Converting between Unix format (ASCII), MS-DOS ASCII format, and Unicode

This can be done with sed (if sed is installed, which it is on many Unix systems). Useful One-Line Scripts For sed contains some methods for converting.

For those with easy access to run the MS-DOS Editor (or similar editor in IBM OS/2), that EDIT command will convert any Unix-style newline sequences to the sequence used in MS-DOS text files whenever that software saves the text files.