This document describes MsgEd TE 6.3, a Public Domain Fidonet Message Reader and Editor Software for OS/2, Windows, DOS and Unix.
MsgEd TE is a message reader and editor software for Fidonet (and compatible) network(s), supporting Squish, Hudson, Jam and Fido *.MSG message bases. This program is released to the public domain. There are absolutely no usage or distribution restrictions. This is truely free software.
MsgEd TE emerged from MsgEd, a public domain fidonet message reader initially written by Jim Nutt and thereafter maintained by numerous people (among them Paul Edwards, Andrew Clarke, and Kim Lykkegaard). MsgEd TE is being developed by Tobias Ernst. You can reach me at 2:2476/418 or via e-mail at tobi@bland.fido.de.
MsgEd TE tries to support a vast number operating system platforms by employing portable software design techniques. It is my policy to release executables and source code at the same time for all supported platforms, among them OS/2, Unix (Linux and FreeBSD as well as commercial Unix systems), Windows NT, 16- and 32-bit DOS.
MsgEd TE is developed with the GNU C compiler and GNU boundary checking, which assures high program stability.
MsgEd TE formerly was an alternative branch to the main Msged development line, which was evolving into a slightly different direction, but as that main development line seems to have ceased, you can now consider MsgEd TE to be the most recent version of Msged. Since then, most of the features of the last incarnation of the main Msged development line, Msged 4.30, have been incorporated into MsgEd TE.
If you like MsgEd TE and start to use it as your everyday Fidonet editor, please drop me a note saying that you do so at ‘Tobias Ernst 2:2476/418’ or at ‘tobi@bland.fido.de’. I originally started to work on MsgEd TE to create a Fidonet editor that fulfilled some special personal needs of mine. Since then, things evolved and I saw myself doing a lot of work that I would not have done just for my own needs. Writing this documentation is one such example, porting to Windows NT another. If I continue to do this work in the future and add new features to MsgEd TE will strongly depend on how much feedback I receive from users that like and use MsgEd TE. Therefore: Don't be shy - drop me a mail. :-)
At this place, I also would like to express my thankfulness to all people that helped making MsgEd TE what it is now, that being all the developers that haved worked on the Msged sources in the past, the Husky developers, and all the beta testers that used the Pre-Release of MsgEd TE 6.3.
This chapter provides you with information that is necessary to successfully install and use MsgEd TE. Part of this chapter applies to all versions of MsgEd TE, while some sections only apply to a particular operating system. If this is the case, the particular operating system is mentioned in the section title.
You should carefully read this chapter because it might save you from a lot of pain, especially (but not only) when using MsgEd TE in networked or UNIX environments.
MsgEd TE 6.3 is shipped in various distribution archives. This section describes the contents of each. You normally do only need one of these files containing the executable and documentation for your platform, and maybe the file that contains the printable version of the documentation. In the following files, ??? must be replaced by the version number, e.g. 600 for version ‘6.0.0’.
For compiling MsgEd TE, you also need the ‘smapi’ library. The ‘fidoconfig’ library is not needed, MsgEd TE can now parse Fidoconfig without need for this library. The versions of ‘smapi’ libary that can be used to build MsgEd TE 6.3 are:
Attention: Most of these ZIP-files contain subdirectories, so you should use the ‘-d’ option when unzipping them with pkunzip.!
This section provides guidelines and additional notes for installing MsgEd TE on OS/2, DOS or Windows.
CHCP command. It
is probably 437, 850 or 866. Then, select the corressponding read map and
write map files that are shipped with MsgEd TE (the have names of the
form READMAPS.codepagenumber and copy them over to READMAPS.DAT
and WRITMAPS.DAT. For example, this could look like this:
R:\MSGED> CHCP
Active Codepage: 850
Prepared System Codepages: 850; 437
R:\MSGED> COPY READMAPS.850 READMAPS.DAT
R:\MSGED> COPY WRITMAPS.850 WRITMAPS.DAT
Please note that the filenames for the Ukrainian codepage 1125 differ from this naming scheme, they are called READMAPS.UKR and WRITMAPS.UKR.
If there is no READMAPS.XXX file corresponding to the ‘Active
Codepage’ returned by the CHCP command, see if there is a
READMAPS.XXX file for one of the prepared codepages. If there is, use
that one, and use the CHCP command to change to this code page each
time before starting MsgEd TE. In the example above, this command would
be CHCP 437. You probably would want to place this command in a batch
file, together with the invoation of MsgEd TE.
If MsgEd TE does not support the codepage that you want to use, please contact the author and ask him to add support for that particular codepage.
See Using Special Characters like Umlauts or Cyrillics - The Charset Kludge, for more information on read and write map files, charset kludge lines, codepages, and character set recoding.
This section provides information on installing MsgEd TE on Linux, FreeBSD or any other Unix-like system.
See Installing MsgEd TE as part of the Husky Project Tools, if you want to use MsgEd TE in conjunction with the hpt Tosser and other Husky Project tools.
The rest of this subsection only covers manual installation of MsgEd TE as a standalone message reader, and may be skipped if you are using MsgEd TE in a Husky environemnt.
If you are using Linux you can get the Linux distribution archive which contains a pre-compiled binary. If you are running any other Unix (including FreeBSD, which due to a strange problem in the termios code won't run the Linux binaries properly) you have to compile the source code on your own (which usually is not much of a problem). See Compiling the Soruce Code, for more information on this.
Please note that this manual does not necessarily cover installation of the RPM archives of Msged created by other persons. Some tips of the following sections also apply when you install the RPM files, but others don't Please refer to the documentation of those RPM archives for more information.
The following describes the installation of the files from the Linux distribution archive. If you have compiled MsgEd TE yourself, you will find the files that are mentioned below in slightly different locations (much in the doc/ subdirectory), but they are all present somewhere in the source code archive as well, after you have done all build actions as described in the appendix.
~ $ mkdir ~/msged-work
~ $ cd ~/msged-work
~/msged-work $ unzip ~/msgte63l.zip
~/msged-work $ chmod guo+x msged
~/msged-work $ su root
Password:
/home/someone/msged-work # cp msged /usr/local/bin
/home/someone/msged-work # exit
~/msged-work $ cp sample.cfg ~/.msged
If you are an administrator and want to install MsgEd TE system-globally,
you can make MsgEd TE read a different configuration file either by
re-compiling MsgEd TE and define the MSGEDCFG macro (this is also
done automatically when you compile MsgEd TE with huskymak.cfg -
in this case the default location is msged.cfg in the etc
subdirectory that you defined in huskymak.cfg). Or you can simply
create a script that calls the MsgEd TE binary with the -c
command line option. Specify the desired file name directly behind the
-c.
If you do this, you should, in the global configuration file, use a statement
like include ~/.msged, so that each user can indivudally configure his
own user name and other user specific settings.
~/msged-work $ cp msghelp.dat ~/.msged.hlp
~/msged-work $ cp sample.tpl ~/.msged.tpl
~/msged-work $ cp scheme.004 ~/.msged.colors
~/msged-work $ cp readmaps.is1 ~/.msged.readmaps
~/msged-work $ cp writmaps.is1 ~/.msged.writmaps
Note that this assumes that you are using ISO 8859-1 font encoding, as is usally the case on Western Unix systems. If you use ISO 8859-5 (Russian Unix vendor fonts), use readmaps.is5 and writmaps.is5 instead, and if you use KOI8-R (Russian Linux and FreeBSD with e.g. cronyx fonts), use readmaps.koi and writmaps.koi instead. See Using Special Characters like Umlauts or Cyrillics - The Charset Kludge, for more information on read and write map files, charset kludge lines, and character set recoding.
If you are using Husky sofware, e.g. the hpt tosser, you can also install MsgEd TE as part of the Husky software. In this case, you should first follow the generic Husky installation instruction as found in the file INSTALL found in the huskybse package.
These instructions essentially boil down to getting the source code packages
of Huskybse, Smapi, Fidoconf and Msged (in this case, use the Husky Msged
distribution, msged-VERSION-src.tar.gz), untar each file, create a
huskymak.cfg based on the template found in the huskybse
package, and then entering each of the subdirectories and typing make;
make install. But be sure to read the file in detail.
After you have done so, you already have a working installation of
MsgEd TE. The command make install entered in the MsgEd TE
subdirectory will already have taken care of installing a workable default
configuration file msged.cfg into your Husky etc
subdirectory. This file is set up to read most of the necessary settings for
MsgEd TE from your fidoconfig (the basic Husky configuration
file), so that once you have configured fidoconfig, you can directly
start using MsgEd TE.
The only thing that you need to adjust is the codepage setting. MsgEd TE is designed to do codepage translation, so that if your computer uses a different characters set compared to what is commonly encountered in fidonet echos, MsgEd TE will handle the job of translating those messages to a character set your local terminal can handle, and likewise translate text you type back so that it is stored in a way other users can read it. This is important for most non-English languages (like German, French, Russian etc.). If you use this feature of MsgEd TE, you don't need to abuse your tosser to do codepage translation any more.
In order to select the proper codepage for your terminal, simply load the MsgEd TE configuration file msged.cfg into your favourite editor and uncomment the line that is correct for your location. The file is commented, and further instructions can be found there. See Using Special Characters like Umlauts or Cyrillics - The Charset Kludge, for further information.
MsgEd TE does neither use the curses library for most of its tasks, nor
does it make use of termcap or terminfo data bases. The way that
MsgEd TE uses to create its full screen interface is to emit ANSI x3.64
character control sequences. This is a common subset of control sequences
that is recognised, among others, by VT52, VT100, VT200 and higher VTxxx
terminals, by xterm, by the FreeBSD and the Linux console, by the OS/2 telnet
program, and others. In order to enable special features like color support
based on the TERM variable, you can use IF constructs in the
configuration file, as shown in the sample configuration file.
I have tested this on several Unix boxes and it worked remarkably well. For optimum results, you should use the scheme.004 color scheme file found in the doc/ resp. samples/ subdirectory. If you have problems seeing the cursor in an xterm, you should start the xterm with the option ‘-cr white’.
If the display is corruped by system log daemon messages or similar, you can at any time during program execution press <Ctrl>-<L> to redraw the screen.
Due to the history of MsgEd TE, it heavily depends on typical PC keyboard combinations like <Alt>-keys, combinations of <Ctrl> with cursor keys, and so on. Not all of them are easy to reflect on a Unix console or in an xterm.
As for the <Alt> keys (<Alt>-<X> and so on): MsgEd TE tries to recognize all sorts of ways in which clients reflect <Alt> or <Meta> key combinations. If that still does not work on your console, besides contacting me so that I can fix it, you can emulate an <Alt> key with the <Esc> key: If you press and release the <Esc> key and then press a letter, MsgEd TE will treat this as if you pressed <Alt> and that letter. However, you have to do this fast, because if no key is pressed after the <Esc> for more than 0.2 seconds, MsgEd TE will assume that you really meant to press a single <Esc> key, which is also frequently used in MsgEd TE.
Some other key combinations, like <Ctrl>-<Left> and so on, are not reproducable in an xterm or on a Unix console at all. Therefore, the sample configuration file sample.cfg contains a bunch of settings that bind those functions that are by default bound to key combinations that cannot be keyed on Unix to other key combinations.
A nasty little problem might occur with the backspace key. If, on your
system, the backspace key deletes the character under the cursor
rather than the character on the left hand side of the cursor, you might have
to turn the BS127 switch on by adding Switch BS127 On to your
configuration file. The sample configuration file already contains correct
settings of the BS127 switch for some widespread Unix consoles.
Also, some xterm variants are really broken. For example, I have seen xterm's reporting code 127 for both Delete and Backspace, so you will only be able to have either Backspace or Delete working. Also, some xterms doe not report codes for <Home> and <End> at all. If you have such an xterm, a tip would be to install rxvt and use msged in an rxvt window instead of an xterm window.
Entering national special characters like cyrillics, the German a dieresis,
or the french accented characters, is always a problem on Unix. If you want
to do that with MsgEd TE, refer to the sample configuration file and the
documentation on the EnableSC keyword (see The EnableSC keyword). The most easiest solution is to put the
EnableSC keyword into the configuration file, but if you do this, you
will loose the <Alt> key combination functionality and will have to
emulate all <alt> keystorkes using the <ESC>-technique explained above.
If all this sounds very clumsy to you, perhaps you might volunteer to create a more Unix-friendly keyboard layout for MsgEd TE. MsgEd TE allows to freely redefine the keyboard layout. See Redifining the Keyboard Bindings, for more information on this. The first person that provides me with a really Unix-friendly set of ‘ReadKey’ and ‘EditKey’ configuration statements will receive special honour in this manual ...
A large part of MsgEd TE and the underlying message API has been made independent of little/big endian or structure packing issues. This means that in principle you can compile MsgEd TE on Alpha, PowerPC, Sparc, or whatever exotic hardware and it will read and write exactly the same binary format files like the Intel versions do. You do not even have to specify any special compile-time switch for compiling on big endian hardware.
However, some things do not yet work on big on non-Intel machines. This includes:
This means that you presently must restrict yourself to a Squish message base and a squish.cfg configuration file if you want to run MsgEd TE on big endian hardware. This will be definietly fixed in a future release.
The UNIX verison of MsgEd TE, by default, presents itself in spartanic
black and white, because this is most compatible with any existing terminal
type. Even if you use the Color configuration keyword to define custom
colors, MsgEd TE still will transform all your color definitions into a
black and white equivalent.
If you want to see MsgEd TE displayed in nice colors, you need to enable extended ANSI color codes:
Switch Colors On # enable ANSI color codes
Include ~/.msged.colors # include the color configuration
Of course you need a terminal that supports ANSI color codes. Among others,
these are the Linux console (but not the Linux xterm!), the FreeBSD console,
the "color-xterm" or "xterm-color" or "nxterm" terminal emulators, and the
FreeBSD xterm. You can use Conditionals to switch the Colors switch
either on or off depending on the TERM
variable. See Conditional Statements in the Configuration File, for more information.
The sample color scheme file color.004, that you copied to ~/.msged.colors during the installation process, contains color settings with sensible values. If, after adding the two lines from the example above to your configuration file, parts of the screen or message text are invisible, your terminal probably does not correctly support ANSI color codes.
By default, the Unix version of MsgEd TE behaves case-sensitively (like any program running on a Unix file system), i.E. it uses all filenames that it reads from configuration file exactly as they are spelled, and all filenames that it creates (i.E. by appending filename extensions) are created in lower case.
This may lead to problems if you are sharing a message base between the Unix versin of MsgEd and DOSish fidonet programs (i.E. fidonet programms running on DOS, OS/2 or Windows, or simply a Windows or OS/2 fileserver that holds the message base). Those programs tend to create a real mess of filenames by mixing both lower-, upper- and mixed-case spelling. If you are running the Unix version of MsgEd in such an environment, you should add the line
Switch AdaptiveCase On
as the first line in your configuration file. This will effectivly make MsgEd behave case-insensitive and should avoid most problems with case sensitivity (see List of available switches).
Sysops that have more than one computer often use network filesystems like SMB (also known as Lan Manager, OS/2 peer services, the Windows Network, et cetera), Novell or NFS to share their message base among multiple computers. Depending on your environment, there are some problems buried into this approach that might cause hidden data loss and might be unaware to you. These problems are not specific to MsgEd TE, but pertain to any Fidonet software that uses the Squish, JAM or Hudson message base format. I feel enforced to devote a section of this documentation to these problems to save you from encoutering severe unexpected problems in your installation, especially as with the addition of Linux or Unix to such a network, the problems tend to increase dramatically. - Another issue in such networks, case sensitivity problems, as already been described above (see About Case Sensitivity Problems).
The issue that we are talking about is access synchronisation. In a multi-tasking or networked environment, it happens that two or more programs simultaneously access the message base. Therefore, the Squish Message API (this is the piece of software that all Fidonet programs internally use to access the message base files) needs a way to ensure that no other Fidonet program can gain access to the message base file while itself is doing vital modifications on it. Otherwise, data could be screwed up or even lost if two programs would modify the same file simultaneously.
As long as your message base resides on a single computer, you do not have a big problem with access synchronisation. On OS/2, Windows NT and DOS, access synchronisation is done via so called record locks, which works reliably. On Linux and other Unix system, access control is performed using so called voluntary locks by all programs that use the SMAPI edition of the Squish Message API. This is not as safe as the "record locks" feature. Voluntary locks can only synchronize programs that use them, i.E. programs that use the SMAPI, like MsgEd TE or hpt. If you wish to use other Fidonet programs on Unix, you should ask the author if he employs voluntary locks for access synchronisation. If he doesn't, do not use his software.
Things get more complicated in a networked environment, because there, not only different applications have to synchronize among themselves, but different computers also have to be synchronized. Or in other words, the network file system that you use must correctly propagate record and/or voluntary locks that have been set on one computer to all other computers.
The SMB network protocol (also known as Lan Manager protocol, or OS/2 Peer Network, or Windows network), in principle, has support for propagating record locks over the net. Tests proved that it works quite well in all systems except Linux (Unix). This means that as long as your network only has OS/2, Windows 3.11/95/NT and DOS (with SHARE.EXE loaded) systems, you do not have to worry about access synchronization.
If you add a Linux box to a SMB network, things get more complicated. For adding Linux to a SMB network, the Samba program is used. The Samba server (as of version 1.9.18.p8, which has been used for all tests described below) has some support for record locks, but it has restrictions. The Samba server will not grant a program running on computer A access to a message base file while a program running on computer B has placed a record lock on this file. However, it will frankly grant a second program running on computer B access to this file even while the first program running on computer B still has a lock on this file. This is a bug in the Samba server. It hope it will get fixed in further releases. - A further shortcoming of the samba server is that it does not convert voluntary locks placed on the Unix side into record locks visible on the OS2/DOS/Windows side. This means that any OS/2 program, for example, can always access the message base file even if a Linux program holds a lock on the file.
Also, neither of the available samba clients (smbfs, rumba) have support for propagating voluntary locks as record locks.
The essence of this is: You cannot savely share a message base between Linux/Unix and Non-Unix systems using Samba. All you can do is place the message base on a Samba server if you assure that no other Linux program accesses the message base, and that only OS/2, DOS and Windows clients connect to the Samba server, and further more that on those clients, only one program at a time tries to access the message base (that is: a client with a multitasking OS that runs the tosser must not have any editor installed, and you should never start up two editors simultaneously on any client).
This is harsh, but true. Write mails to the programmers of Samba and beg them to fix the problem with multiple programs on one clients, and to implement the feature to convert voluntary locks on Unix side into record locks on Non-Unix side. Perhaps the situation will then change in the future.
As for NFS, NFS itself does not support any kind of access synchronization at all (!). Access synchronization on NFS is performed using an additional daemon software called rpc.lockd. So if you have a NFS server that has a functional rpc.lockd daemon and all NFS clients support the rpc.lockd protocol, then you can use NFS to share a message base between multiple computers. The bad news is that I have not seen a working rpc.lockd on either FreeBSD or Linux, and at least the NFS client for OS/2 (as probably all other Non-Unix NFS clients) does not support the rpc.lockd protocol. If you want rpc.lockd to work, you currently must use AIX or Digital Unix or maybe also some other commercial Unix. Not an option for the home user, I fear.
The essence is: You cannot use NFS to share a message base between multiple computers.
Finally for Novell: I do not have any information on Novell networks. I suppose that they natively do support record locking, but I do not know if or how the existing Novell clients for Linux/Unix do support it.
If you do not obey to these three rules, you sooner or later will experiences loss or corruption of mails and mail areas. Sorry to say so.
But what if you absolutely have to share a message base between multiple Linux/Unix or Linux/Unix and Non-Unix computers? There is only one solution to this problem: Use a message base format that does not require access synchronisation. While the Squish, JAM and Hudson message base formats to require access synchronisation because they store multiple mails in a single file, the Fido *.MSG (also known as Opus) message base format does not have this restriction because each mail is stored in a separate file. So Fido *.MSG presently is the only way to go if you want to share your message base between Linux/Unix and Non-Unix or other Unix computers.
This sections lists some shortcomings of the current release MsgEd TE 6.3. Please do not complain to me about these problems, I am well aware of the problems and will try to solve them in the future to the best of my possibility. (If, on the other hand, you want to fix these problems on your own, go ahead and send me the changes you made. They will be greatly appreciated.).
UserList Keyword, for more information.
There are numerous reasons why you might wish to establish contact with me, the author of MsgEd TE.
MSGED_ECHOOS2BBS.GEROS2NET.BBS.GERIf you do not have access to any of these echos, you may of course also contact me via netmail or e-mail at the addresses listed below.
If you are running the precompiled Linux binary, reporting a fatal bug is exceptionally easy. If you experience a crash, simply send me the core file that has been generated. You do not need to try to reproduce it or write extensive descriptions. Simply send the core file, and in most circumstances I will be able to fix the problem.
If you are running any other binary version (like OS/2, DOS, Windows), you will not get a core file on a crash. (On OS/2, you can write me a mail and ask me for sending you a debugging executable. This will require the EMX runtime, but generate core files just like the Unix version does. On DOS and windows, you do not have this option). Write down as much information as you can, try to find a way to reproduce the crash and contact me at the addresses below.
If you want to write a new feature for MsgEd TE, please contact me beforehand to avoid that we do duplicate work. Again, I will appreciate and honor eny efforts done by you. Please note that for writing a MsgEd TE enhancement, you should be familiar with C. Also, MsgEd TE uses a special indentaion style throughout the source code, that I would like you to adhere to.
So here are my addresses if you want to get in contact with me:
This chapter will be supplied in a future revision of this document. It will provide an introduction for beginners on using MsgEd TE.
As long as this chapter is not provided, you must help yourself using the online help. Nearly everywhere in MsgEd TE, you can press Alt-H to get a somewhat context sensitive help screen.
After you have managed to perform basic functions with MsgEd TE, like reading messages, entering new messages, and replying to messages, this chapter will introduce you into some advanced concepts in MsgEd TE that deserve special attention, like how to use a Fidonet-Internet gateway, how to use eight bit character sets, and similar.
This section tells you how to export mail messages. Exporting in this sense includes simply saving the message text into a file, but also printing the message or feeding it into a pipe.
In order to export the message text into a plain text file, you have to
invoke the export reader or editor function. If you did not change the
keyboard binding, this is done by pressing <Alt>-<W>. You will be
shown a menu that looks like this:
+-----------------------------------------+
| Write to File |
| Print |
| Pipe into external Program |
| Cancel |
+-----------------------------------------+
Select the first entry, ‘Write to File’. You then will be shown a dialog box where you can select a file name. You can use the cursor keys to navigate through the directory structure and select a file to be overwritten. If you want to create a new file, press <Tab> to get to the ‘File:’ entry box and enter a new file name.
After that, you will see a menu that asks you how the text should be exported:
+-----------------------------------------+
| As Plain Text |
| Binary (for re-importing into Msged) |
| Cancel |
+-----------------------------------------+
Normally you will want to select ‘As Plain Text’. This produces a nice message header and nicely wrapped paragraphcs. This format is useful for reading with normal editors, for printing etc. The ‘Binary’ format (formerly known as ‘Msged Format’) will not write any headers, and it will not break the paragraphs into lines. This format is useful if you intend to re-import the text into MsgEd TE or into another application that works paragraph-oriented rather than line-oriented (like a word processor).
Note that this dialog box will not be shown if you try to export text while you are editing a message; in this case, the plain text mode will always be used.
When you have made your selection, the file will be written. If you selected a file that already exists. you will see an additional dialog box that asks if you want to append to the file, overwrite it, or cancel the operation.
In order to print a message, press <Alt>-<W>. Select ‘Print’. That's all about it, the message will be printed! But how did MsgEd TE know how to find your printer? Well, on OS/2, DOS and Windows it just uses the standard printer, known as ‘PRN’, which is usually connected to the first parallel port. On UNIX, it calls the ‘lpr’ command with no special options, which will lead to the default queue being used.
If you want to use a different printer for printing mails – for example, you
might have two printers, one for high quality office correspondance, and one
for quick printouts, and want to use the latter one for printing Fidonet
messages –, you can use the Printer keyword in the MsgEd TE
configuration file to select a different printer. See The Printer Configuration Keyword, for more information.
What does piping mean? This feature works as follows: MsgEd TE will start an external command or program and feed the mail text into this command's standard input stream. This feature originally comes from the Unix world. For example, you could pipe the message text into a Perl or Rexx script that analyses the text and does something with it (for example, the script could store the text in a cooking recipe database). The piping feature does not work in all versions of MsgEd TE. It only works in the UNIX version and in those non-UNIX versions that have been compiled with a GNU gcc compiler.
In order to pipe message text into an external program, type <Alt>-<W> and select ‘Pipe into external program’. You will then see a dialog box that prompts you for a command to execute. You can enter any commands or programs in exactly the way as you would enter them at the shell prompt of your operating system. MsgEd TE will execute exactly this command and provide the message contents as standard input to the command. For example, you could enter
cat - >test.txt
This of course is a stupid example, because the same result could be achieved by selecting ‘Write to File’ and specifying text.txt as file name, but it shows how the mechanism works.
After that, you will be prompted for the export mode (plain text or binary). See Saving message text into a plain text file, for information on what this means.
MsgEd TE 6.3 supports forming message areas into message area groups. The main appliance of this feature is to ease arealist navigation - you can have the areas sorted by groups, MsgEd TE can display separators between the single groups, or you can make the area list display only members of a certain group, and switch between the groups using hotkeys. But you can also use the group feature to select different usernames or template files based on which area you are writing in.
The following subsections will first tell you how to set up groups and assign areas to those groups, and will then go on and tell you how you can make use of groups to ease your life with MsgEd TE.
In MsgEd TE, a group is identified by a group name. A group name can be any string and may include spaces etc. The group name is not case sensitive, however. MsgEd TE has no fundamental limit on the number of groups that can be defined.
Each message area can only be member of one group. This means that if you assign an area twice to different groups, it will only be a member of the group that it has been last added.
Setting up groups is very easy if you read all your area definitions form a tosser configuration file (see Reading a Tosser Configuration File (Areafile)). If your tosser stores group information and MsgEd TE supports reading it, then MsgEd TE will automatically take over the tosser's group definitions. This is currently supported for ‘Fidoconfig’ and ‘Fastecho’ type areafiles.
For ‘Fidoconfig’, the names of the MsgEd TE area groups will be the same names as the ‘Fidoconfig’ group names. However, be aware that fidoconfig group names are case sensitive, while MsgEd TE group names are not. So, members of two different groups with names that, in the fidoconfig file, only differ in upper/lower case spelling will be members of the same group in MsgEd TE.
For ‘Fastecho’, the names of the MsgEd TE area groups will be the names that you have defined in fesetup in the ‘System/Group names’ menu. If you did not set up group names for some or all areas, those areas will have a name of ‘Fastecho Group X’, where ‘X’ is the letter that is used to identify the group in Fastecho.
The easiest way to find out about which group names MsgEd TE has created based on the areafile information is to press <Ctrl>-<G> in the message area list. This will show a menu of all groups.
If you do not want to read any sort of group setup from the tosser
configuration file, then you can turn off the UseTosserGroup switch by
adding Switch UserTosserGroup Off to your MsgEd TE configuration
file. This has to be done before the Areafile statement to which this
setting should apply.
If MsgEd TE is not able to read group information from your
Areafile, or if you want to fine-tune that information, or also if you
are defining some or all areas manually in your MsgEd TE configuration
file. This is done using the Group keyword. Here is it's syntax:
Group "groupname" [pattern]
Group "OS/2 Echos" *OS2*
The groupname parameter should be a string that uniquely identifies this group. It may contain spaces if you enclose it in quotation marks, as shown above.
The optional pattern argument specifies a wildcard pattern. The pattern may contain any number of stars and questionmarks, and works like a wildcard on an OS/2 or Win32 command line. This pattern is matched against the area tag (like for example OS2PROG), and all matching areas will be added to that group.
If the pattern argument is omitted, the group will be defined, but no areas will be added to it yet.
There can only be one pattern argument, but this is not a problem, as
the Group keyword is cumulative. This means that if you write
something like
Group "Echos in German Language" *.GER
Group "Echos in German Language" *.024
Group "Echos in German Language" *.AUS
then the group will contain all areas that match at least one of the given patterns.
However, each one area can only be member of a single group. This means that if you add an area to a group that has previously already been added to a different group, that group will lose this area. Example:
Group "German Echos" *.GER
Group "Linux Echos" *LINUX*
Here, the ‘LINUX.GER’ echo area would be in the ‘Linux Echos’ group, and not in the ‘German Echos’ group.
You can put Group statements anywhere in your configuration file. Even
if an area is defined after a Group statement, it will still be added
to that group if the wildcard matches. However, the relative ordering of the
Group file statements may be important: Msged will display
groups (when areas are sorted by group, or in the group menu, see
later) in the order of first mention in the MsgEd TE configuration
file. A group is mentioned either when it's name first appears in a
Group statement, or when it is automatically defined when reading an
areafile.
For example, let's assume you are using fidoconfig and get all group information from the areafile. But you want to put some groups that attract your special interest into a group named ‘Interesting Groups’. Now you have to decide if you want to put see this group before all other groups in the area list, or if you want to see it after all other groups. In the first case, write
Group "Interesting Groups"
Areafile fidoconfig
Group "Interesting Groups" *LINUX* *OS2*
In the second case, omit the definition before the Areafile statement
and simply write
Areafile fidoconfig
Group "Interesting Groups" *LINUX* *OS2*
When you have set up groups, the message area list will make navigation with many areas a lot easier.
The most basic group feature of the area list is that it can display areas
grou-sorted, i.E. first all areas of the first group, then all areas of the
second group, and so on. To achieve this, use the SortAreas keyword as
follows:
SortAreas G
Most probably, you will further want to sort the area inside the group. If, for example, you want to sort all netmail areas to the beginning of each group, and then sort the areas alphabetically by description, you would use
SortAreas GND
Once you have activated sorting areas by group, MsgEd TE will draw horizontal bars between the groups to visually separate them. If you do not like this feature, you can disable it using:
Switch GroupSeparators Off
You can press <Ctrl>-<G> in the arealist and get a list of all groups that have been defined. When you select any of those groups, the area list will then only display areas that are member of this group. Further more, all other MsgEd TE functions, like area scanning, personal mail scan, switching to the next/previous area in message reading mode, etc., will also only work on those groups. MsgEd TE will effectively behave as if only those groups had been defined. (An exception is when moving/copying/forwarding mail or replying to a different area: there you will still get a list of all areas).
You can then again use the <Ctrl>-<G> menu or press the short cut <Alt>-<0> to return to the display of all defined areas. You can also use the shortuts <Alt>-<1> ... <Alt>-<9> to quickly switch between the first nine groups.
This feature is described in the documentation of the GroupSettings
keyword. See The GroupSettings Keyword.
Languages other than English often use special characters besides the normal alphabet. Examples are the accented letters in French or the umlauts in German, or the cyrillic alphabet used in Russia and elsewhere. IBM block graphics are also called special characters. This section will describe what measures have to be taken in order to be able to transmit special characters via Fidonet.
In order to be able to exchange text between computers, it was necessary to agree on a scheme on how to encode letters into numbers, the so called character set. The standard character set for transferring text between a huge variety of computer systems is the ASCII character set. Unfortunately, the ASCII character set is only 7 bit wide and does not leave room for national special characters.
In order to be able to transfer special characters like accents and umlauts, it was therefore necessary to use eight bit wide extended character sets that defines how special characters are encoded.
In contrast to the standard 7 bit ASCII character set, which is a single character set used by nearly all computer systems, there exist several pseudo-standard character sets that are 8 bits wide. All of them contain ASCII as an subset, but they all differ in how they encode special characters. DOS and OS/2 computers typically use the IBM PC character set, but even there, dependent on what country you live in, there are several different code pages of the IBM PC character set. Unix computers and the Amiga in the western world typically use the ISO8859-1 character set, also known as Latin-1. Windows uses IBM PC for console applications, but ISO8859 for graphical applications. The Macintosh uses the Macintosh character set. In Russia, there is a similiar problems: There exist four ways of encoding cyrillics, namedly the KOI8-R fonts, the ISO 8859-5 fonts, the codepage 866 of the IBM PC character set, and Windows Codepage 1251.
The consequence of this is clear: If you write a text on a Unix or Windows computer using special characters like accented letters or umlauts, you cannot expect it to be properly displayed on a DOS or OS/2 computer, and vice versa, unless special measures are taken.
This issue of special characters has been a problem for Fidonet in the past, but it has been solved by the Fidonet standard FSC 0054 and its successor, FSP 1013, so that you can now safely use special characters in Fidonet mail if your message editor supports FSC 0054. FSC 0054 basically works like this:
Every Fidonet editor that wants to be compatible with FSC 0054 must be delivered along with built-in or external character translation tables that tell the editor how it can convert text that contains special characters from one character set to another.
When composing a message using a FSC 0054 compliant editor, you have two choices: By default, the editor allows you to enter the full range of special characters that your computer supports, but when saving the message, the editor will use its character translation tables and convert your text into a 7 bit clean representation that can be displayed on all computers even if they don't support FSC 0054. For example, a German sharp s would be converted into double s, an e with accent would be converted into an e without accent, a cyrillic soft a would be converted to its transliteration "ya", and so on. This is the maximum compatibility mode: It offers you the comfort of being able to write text just as you would in a letter, using all special characters that your language requries, but your mails will still be properly displayed on all computers. This might be an option for German users, but it certainly is not for Russian users, as the transliteration of cyrillic letters is not particularly easy to read.
The other (better) possibility is that your editor leaves the special characters that you typed in as is, or converts them to a common transport charset (like codepage 866 in Russia, or codepage 850 in Europe), but inserts a hidden kludge line, from here on referred to as the charset kludge, into the message, that designates which character the mails stored in the message are composed in. When your message is read on another computer by a Fidonet message reader that also supports FSC 0054, the message reader will see the charset kludge in your mail and then use its charset translation tables to convert your message into the character set that this computer uses. The consequence is that even if your computer and the computer of the receiver use different character sets, everything that you typed in will look just the same on the receiver's screen than on yours, including all special characters that have been typed.
A particular note to all Russian users of Msged: In Russia, it has been commonly agreed on to transport all Fidonet mails in Codepage 866. So you might ask what you do need a charset kludge for - could not just MsgEd TE recode everything to codepage 866 when writing a mail and importing from codepage 866 when reading a mail, and not care about that kludge line? But imagine a user in Germany who wants to read Russian echomails. His mail editor needs a way to know if a mail that it is about to display contains German special letters, or if it contains Russian ones. (Or vice versa, imagine a Russian person who wants to leran the German or English language). Only if Russian mails contain the proper charset kludge (‘CP866’), it will be able to display both languages correctly.
MsgEd TE fully supports FSC 0054. It uses two binary files, a read map and a write map. The read map contains tables that define how to convert all the known transport charsets to the local charset (this even includes transliteration tables for displaying Russian text on Western computers!), and similarly, the write map contains tables that define how to convert the local character set to any allowed transport character sets.
The default name of the character set translation files are READMAPS.DAT and WRITMAPS.DAT, and they are searched in the current working directory when MsgEd TE starts. (On Unix, the exact name and location of these files are determined by the defaults you put into the makefile, or ~/.msged.readmaps and ~/msged.writmaps for the precompiled binaries, while the RPM distribution might use yet other locations). You can change the file names and location to use with the ‘Readmap’ and ‘Writemap’ keywords (see The Readmap and Writemap Keywords).
The binary release of MsgEd TE ships with a variety of read maps and write maps. For each character set or codepage, there is a pair of read map and write map file which contains tables to convert from any charset set to this codepage and back.
Now all you need to do in order to configure MSGED to properly encode
and decode all sorts of special characters is to determine which character
set or codepage your computer is using, and copy the corresponding pair of
read map and write map file to the default name and location as noted above,
or use the ‘Readmap’ and ‘Writemap’ keywords to point Msged to the
correct pair of read map and write map files.
The following tables lists all read map and write map files that MsgEd TE currently includes:
Filename | Type of font / character set / computer
-------------------------------------------------------------------------
READMAPS.850 | Any DOS or OS/2 computer, or Windows computer with the OEM
WRITMAPS.850 | console fonts, that uses Codepage 850. This applies to most
| computers in Western Europe. Some badly configured Linux
| systems might also use this code page.
-------------------------------------------------------------------------
READMAPS.437 | Any DOS or OS/2 computer, or Windows computer with the OEM
WRITMAPS.437 | fonts, that uses the standard codepage 437. This applies to
| most US-American installations, and also to some European
| ones that use Codepage 850 because it has some more IBM
| graphics characters.
-------------------------------------------------------------------------
READMAPS.865 | This is the "nordic" IBM Codepage 865 used in some
WRITMAPS.865 | Northern European countries.
-------------------------------------------------------------------------
READMAPS.866 | This is IBM Codepage 866, used by DOS and OS/2 or Windows
WRITMAPS.866 | text mode applications in Russia.
-------------------------------------------------------------------------
READMAPS.UKR | This is IBM Codepage 1125, used by some DOS and OS/2 or
WRITMAPS.UKR | Windows installations for text mode applications in
| Ukraine and Belorussia.
-------------------------------------------------------------------------
READMAPS.IS1 | This is ISO 8859-1. It is the standard encoding for
WRITMAPS.IS1 | X11 fonts and console fonts on Linux and Unix systems
| in Western Europe.
-------------------------------------------------------------------------
READMAPS.IS5 | This is ISO 8859-5. It is the encoding used for vendor
WRITMAPS.IS5 | shipped additional fonts in Russian editions of commercial
| Unix systems.
-------------------------------------------------------------------------
READMAPS.KOI | This is KOI8-R, used by the cyrillic cronyx font set,
WRITMAPS.KOI | which is in use in almost any Russian Linux or FreeBSD
| installation, and can of course also be installed on
| commercial Unix systems.
-------------------------------------------------------------------------
So, enabling character set translation is easy, but you have to pay attention to use the correct pair of read map and write map file.
If you have the source code distribution of MsgEd TE, the bin subdiretory contains readmaps.dat and writmaps.dat files for all supported code pages. If you are compiling directly out of CVS, you can go to the maps subdirectory and compile and use the makemaps utiltiy to build the proper character set maps.
The following table lists all level 2 transport character sets that MsgEd TE understands when it finds them in mails (meaning all character sets that are defined in the READMAPS.DAT and WRITMAPS.DAT files):
@CHRS-Kludge: | Conventional Name: | Used by these computers:
--------------+-----------------------+---------------------------
LATIN-1 2 | ISO 8859-1 | Western Unix, Amiga, Windows GUI
MAC 2 | MAC | Macintosh computers
CP437 2 | IBM PC, Codepage 437 | DOS, OS/2, Windows console
CP850 2 | IBM PC, Codepage 850 | International / European versions
| | of DOS, OS/2 and Windows.
CP865 2 | IBM PC, Codepage 865 | Nordic versions of DOS, OS/2, Win
CP866 2 | IBM PC, Codepage 866 | Russian OS/2, DOS, Windows
CP1125 2 | IBM PC, Codepage 1125 | Ukrainian and Belorussian
| | OS/2, DOS, Windows
Apart from that, MsgEd TE also understands the (outdated)
@CODEPAGE kludge line.
Most READMAPS.DAT and WRITMAPS.DAT files define some more
charset names, like KOI8-R, ISO-5, and so on, but these kludge
lines are not intended for message transport, but only as an internal name
for MsgEd TE to see what charset your computer uses locally.
There are quite some other (though incorrect or obsolete) charset kludges in
widespread use in fidonet. The most prominent one is IBMPC 2.
Originaly, IBMPC 2 meant the DOS codepage 437, but in the meantime, it
has been used to simply denote the codepage that a "IBM" computer is
typically using. This means that if a Russian user has a kludge that says
IBMPC 2, he probably means CP866 2, while if a German user has
IBMPC 2, he probably means CP850 2.
Msged supports use of those outdated or incorrect charset kludges with the
CharsetAlias command. A Western European user should
probably put the following comand into his config file:
CharsetAlias IBMPC CP850
An American user might prefer
CharsetAlias IBMPC CP437
A Russian user needs a whole bunch of commands:
CharsetAlias IBMPC CP866
CharsetAlias +7_FIDO CP866
CharsetAlias RUFIDO CP866
Once FSC 0054 is activated, MsgEd TE will be able to correctly display all mails that have been created with one of the characters sets listed above, as long as they contain the proper charset kludge line.
Unfortunately, quite some still don't - do tell their authors to correct
their setup! Until those users fix their editors, MsgEd TE offers you
two options. The one is the ‘AssumeCharset’ keyword, which sets a
default character set kludge name for mails that do not contain such a kludge
line. See The AssumeCharset keyword, for more
information. The other option is the <Alt>-<T> key combination that
you can press in message reading mode. You will get a menu that allows you to
select from all supported codepages and character sets. You can use this menu
if you must read a mail that contains a wrong character set kludge line, or
one that does not contain such a kludge and does not meet the assumption you
made with ‘AssumeCharset’. See Miscellaneous other Reader Functions, for more information.
Now that you have set up MsgEd TE so far, you are able to read almost all mails with correct 8 bit characters, and mails that you write yourself may also contain any special characters, but MsgEd TE will convert them into a 7 bit ASCII character set when you save them.
If you want to retain special characters in your mail by adding a charset
kludge (which is highly recommended), you have to do two things. First, you
have to define which character set to use for saving your mails
. See The OutputCharset Keyword, for information on
how to do this. In most cases, you will simply want to add the following line
to your configuration file:
OutputCharset IBMPC
Although it would be better to use CP437, CP850, CP865 or CP866
(depending on your location), most readers still don't support this, so using
IBMPC might be better for the moment. If you use IBMPC,
MsgEd TE will emit an addtional CODEPAGE kludge line to make
clear which codepage you actually are using.
Exporting in
IBMPC charset will even work on a Linux box, just if you were wondering.
Then, you have to tell MsgEd TE in which areas it is allowable to send mails with special characters and charset kludges. MsgEd TE will only write special characters into areas that have the ‘8’ flag set. If you are importing your message area configuration from a tosser configuration file, you can simply put the following line to the beginning of your configuration file:
AreaFileFlags 8
(If you already have an AreaFileFlags statement, just add the ‘8’
character to its parameters). See The AreaFileFlags Keyword, for more information.
This will allow MsgEd TE to use special characters in conjunction with a charset kludge in all message areas imported from a tosser configuration file.
If you only want to enable special characters for a few areas, you have to define these areas manually, giving each of them the ‘8’ flag individually. The same applies if you have to define your areas manually for other reasons. See Manual Area Definition, for more information on this.
MsgEd TE has built-in support for Fidonet to Internet Gateways, allowing for seemless coexistence of Fidonet mail and Internet mail. When you use MsgEd TE to talk to your Internet gateway, you do not even have to know about all the nasty details of gateway addressing - MsgEd TE does the job for you. This makes MsgEd TE the ideal choice as an editor to give to new users that want instant e-mail access without having to care for klumsy gateway addressing rules.
There are various ways of designing Fidonet to Internet gateways. The most common is the Gatebau standard, which among others is implemented in the excellent gateway software Fidogate by Martin Junius. You can find more information about Fidogate at http://www.fido.de. Various other gateway programs more or less conform to this standard as well.
Addressing a Gatebau compatible gateway works like this: The gateway has its own node- or point number. When you wish to write an e-mail using a standard Fidonet editor, you have to address your netmail to this gateway node number. As receiver's name, you can use the real name of the receiver, or you can use ‘UUCP’, if the real name of the receiver is unknown. Some not-so-smart gateway software requires that you always use ‘UUCP’ as receiver's name. - In order to tell the gateway the e-mail address that the mail should be delivered to, the very first line of your message must contain the e-mail address of the receiver, preceded by ‘To:’. The e-mail address can be specified in three different forms. Here are three possible first lines of gateway-addressed netmails:
To: juser@somedomain.com
To: juser@somedomain.com (Joe User)
To: Joe User <juser@somedomain.com>
The last of these forms is not supported by some older gateway software. - The ‘To:’-line must be followed by an empty line, and then you can begin with your message text. A complete e-mail addressed to an internet gateway at ‘2:99/999.0’ could look this:
==========Message Header==================
From: Bill Sysop, 2:99/123.0
To: UUCP, 2:99/999.0
Subject: This is a test e-mail
==========Message Body====================
To: juser@somedomain.com (Joe User)
Hello Joe!
This is a test.
Regards,
Bill.
Receiving e-mail from the gateway is similar: You receive an e-mail from the gateway node or point, and in the mail boday, the first line will contain a ‘From:’-line which designates the e-mail address the mail was from. Sometins, the ‘From:’-line is followed by a ‘Reply-to:’ line, which indicates that the sender wishes to receive any answers at the e-mail address shown in the ‘Reply-to:’-line rather than at the e-mail address shown in the ‘From:’-line. Here is an example:
==========Message Header========================
From: Joe User, 2:99/999.0
To: Bill Sysop, 2:99/123.0
Subject: Re: This is a test e-mail
==========Message Body==========================
From: Joe User <joe@some-machine.somedomain.com>
Reply-To: Joe User <juser@somedomain.com>
Hello Bill!
I received your test e-mail without problems.
Regards,
Joe.
This interface works with every stone-age Fidonet editor, but it is clumsy. When replying to an e-mail that came through a gateway, for example, you would have to remember the sender's e-mail address, and when writing the reply, you would have to manually insert a correct ‘To:’-line, just to name one problem.
Therefore, MsgEd TE can do the work for you. If properly configured, MsgEd TE will to the job of interpreting and inserting ‘From:’, ‘Reply-To:’ and ‘To:’ lines. With gateway support turned on, writing an e-mail with MsgEd TE is just as easy as writing a fidonet netmail. In the following, we will see how to configure MsgEd TE for gateway support and how to use these features.
In order to do the gateway addressing stuff for you, MsgEd TE needs to know which gateway you wish to use for sending e-mail. MsgEd TE will recognise gated e-mail no matter which gate it comes from, but it must be told which gateway can be used to send replies and new e-mail, because most gateways require that you pay some sort of registration fee before you can use them for sending mail.
The UUCP keyword is used to tell MsgEd TE the node number of your
internet gateway (see The UUCP Keyword). It simply takes
this node numer as argument. Example:
UUCP 242:4900/99.0
The UucpName keyword is used to tell MsgEd TE the name that must
be in the receiver's name field in a netmail sent to the gateway. For older
gateways, you should use
UucpName UUCP
If your gateway is running Fidogate or another more advanced gateway program, you should use
UucpName *
This enables real name mode, i.E., mail addressed to the gateway will have the real name of the receiver in the receiver's name field instead of the pseudo name ‘UUCP’. The advantage of this is that your message templates will generate strings like ‘Hello Joe!’ instead of ‘Hello UUCP!’ ...
If you want to insert Reply-To lines into outgoing mail, and if your gateway
supports them, of course, you might also wish to use the ‘UucpReplyTo’
keyword. Reply-To lines are used to tell the receiver's software that replys
should be directed to an alternative e-mail account instead of the one you
are mailing from. See The UucpReplyTo Keyword, for more information.
There is yet another task to be done before you can use the gateway addressing features of MsgEd TE. For historical reasons, the gateway addressing features are disabled by default, and you have to enable them on a per-area basis.
Unless you have special needs, it is best to enable the gateway addressing
features for all areas, because a lot of fidonet areas are gated to
internet somewhere. You do this by adding the ‘u’ flag to every area
that you have manually defined in the MsgEd TE configuration file, and
by specifying AreaFileFlags u at the beginning of the configuration
file in order to set the ‘u’ flag for all area definitions that are
imported from your tosser configuration file. See Defining Message Areas, for more information on message area
flags.
Once you have configured MsgEd TE with the data of the gateways that you
wish to use and turned on the ‘u’ flag for all areas, writing e-mail is
very simple. When entereing a message, you just have to enter a valid e-mail
address instead of a user name. If MsgEd TE recognises a valid e-mail
address, it will not look up this name in the nodelist or prompt you for a
node number, but it will automatically address the mail to the configured
gateway nodenumber and generate the necessary ‘To:’-line. The
‘To:’-line will not even be shown to you, unless you have the
ShowNotes switch on (see List of available switches).
Reading e-mail that comes from any internet gateway is equally simple. If the
‘u’ flag is set for an area, MsgEd TE will automatically recognise
From: and Reply-To: lines and hide them from you. Instead of
displaying the gateway pseudo user name and node numer, it will display
the e-mail address that the mail is coming from in the message header field.
MsgEd TE also supports newsgroups, i.E. echomail areas that are being received from an internet gateway, as long as the ‘u’ flag ist turned on for these areas. In newsgroups, MsgEd TE will handle mails (postings) just as in netmail areas, i.E. it will display the sender's e-mail address in the message header. If you do a private reply (i.E. a reply to a netmail area using <Alt>-<N>), the e-mail reply will correctly be addressed to your favorite internet gateway.
This chapter gives a complete listing of available keystroke combinations in MsgEd TE. After that, you will find instructions on how you can redefine the keyboard to suit your preferences.
Please note: MsgEd TE traditionally uses a DOS-ish PC keyboard with <Alt> key and function keys. Unix users should refer to the Unix installation notes before reading this chapter (see Notes on UNIX keyboard input).
The arealist screen is the screen that normally shows up right after you start MsgEd TE. It lists all areas that you have defined in the configuration file (see Defining Message Areas).
The arealist screen can be navigated with the cursor keys, or you can also navigate through the area list by simply typing in the first few letters of the area name that you are looking for.
In addition, the following commands are available in the arealist screen:
The keyboard setup of the Arealist Screen cannot be modified by the user.
When you press <Enter> or <Right> in the arealist screen, you will
enter message reading mode. (An exception to this is if you have turned the
DirectList switch on. See List of available switches, for more details. In this case, you will enter the message list
mode instead). In the message reading mode, one message is displayed at a
time. You can scroll through the message, write new messages, jump to other
messages of the same message area, jump to other message areas, and invoke
numerous special functions.
All functions that are accessible from this mode have a unique name. Most functions are prebound to a reasonable keycode combination, but you can redefine the keyboard mapping by assigning other keycode combinations to these function names (see Redefining the Keyboard).
down, bound to: <Down>up, bound to: <Up>help, bound to: <Alt>-<H>next, bound to: <Right>previous, bound to: <Left>first, bound to: <Home>slast, bound to: <End>link_to, bound to: <Ctrl>-<Right>u-next, bound to: <Ctrl>-<I>link_from, bound to: <Ctrl>-<Left>next_area, bound to: <+>prev_area, bound to: <->list, bound to: <Alt>-<L>last, not pre-bound to any keyastart, not pre-bound to any keyhome, not pre-bound to any keyback, not pre-bound to any key.link_to or link_from functions. Untested.
newmsg, bound to: <Alt>-<E> or <Ins>reply, bound to: <Alt>-<R>quote, bound to: <Alt>-<Q>repoth, bound to: <Alt>-<N>followup, bound to: <Alt>-<U>change, bound to: <Alt>-<C>edithdr, bound to: <Ctrl>-<H>move, bound to: <Alt>-<M>delete, bound to: <Alt>-<D> or <Del>scan, bound to: <*>scan_unscanned, bound to: <#>pmail, bound to: <Alt>-<P>spmail, not pre-bound to any keysearch, bound to: <Alt>-<F>hdrsearch, bound to: <Alt>-<Z>search, but only scans message headers.
view, bound to: <Alt>-<V>config, bound to: <Alt>-<S>chngaddr, bound to: <Ctrl>-<W>chnodel, bound to: <Ctrl>-<N>name, bound to: <Ctrl>-<U>Name
configuration keyword, you can use this function to select the name to use
when writing messages. If you have any GroupSettings keyword in your config,
this selection will only last until you enter a new area, because in such a
scenario, the username which is used is defined by the area that you are
in. If you don't have any GroupSettings keyword in your config, this selection
will last until you make a different one. See The GroupSettings keyword, for more information.
export, bound to: <Alt>-<W>selchs, bound to: <Alt>-<T>AssumeCharset keyword (see The AssumeCharset Keyword.
An example would be if you have configured your computer with ‘AssumeCharset 850’ because you usually write in a Western European language, but ocasionally read Russian echomail. Then, if the Russian mail does not have a charset kludge, you would need to press <Alt>-<T> and manually select ‘CP866 2’ in order to view the proper transcription of the cyrillic text.
The selection that you make lasts until you make a differnt one, or until you
quite MsgEd TE.
shell, bound to: <Alt>-<O>dos, bound to: <!>null, not pre-bound to any key.exit, bound to: <Alt>-<X>, <Alt>-<A> and <Esc>MsgEd TE has a built in message editor. It is suggested that, before you start using an external editor for writing messages, you should at least try to use the internal message editor, because it is best suited for composing FTN-style messages. The internal message editor is highly configurable, so you should be able to use the internal message editor with the same keyboard setup as your preferred external text editor.
In the following, you will be shown a complete list of available message editor functions. These functions are pre-bound to sensible keystrokes, which are also listed in the following table. Each message editor function has a unique name, and using this name, you can bind this function to any keystroke that you might estimate to be adequate. Instructions on how to do this will be given in the following section (see Redefining the Keyboard bindings).
left, right, up, downwordleft, wordrightpgup, pgdngobol, goeoltop, bottomfirst, lasttab, pre-bound to: <Tab>TabSize keyword
in the configuration file (see The TabSize Keyword).
newline, pre-bound to: <Enter>, <RET>backspace, pre-bound to: <BS>del, pre-bound to: <Del>deleol, pre-bound to: <Alt>-<K>delline, pre-bound to: <Alt>-<D>, <Ctrl>-<Y>emacskill, pre-bound to: <Ctrl>-<K>deleol, i.E. it kills all characters from the
current cursor position to the end of the line, but if issued in an empty
line, it removes that line. This is just what pressing
<Ctrl>-<K> does in the GNU Emacs editor.
killword, pre-bound to: <Ctrl>-<T>undel, pre-bound to: <Ctrl>-<U>delline function. It will not
restore single charactres that have been killed with del,
deleol, killword, emacskill or similar functions.
zap, pre-bound to: <Alt>-<L>These functions provide cut'n'paste functionality:
anchor, pre-bound to: <Alt>-<A>cut, pre-bound to: <Alt>-<C>anchor to select
a text block), i.E., it will delete all selected characters and store them in
an internal clipboard. Text that previously was stored in the clipboard will
of course be discarded.
paste, pre-bound to: <Alt>-<P>cut function) at the current cursor
position.
unblock, pre-bound to: <Alt>-<U>anchor function will be
removed, that is, any previously highlighted text will again be displayed
normally.
abort, pre-bound to: <ESC>bytecount, pre-bound to: <Alt>-<B>edithdr, pre-bound to: <Alt>-<E>export, pre-bound to: <Alt>-<W>insert, pre-bound to: <Ins>import, pre-bound to: <Alt>-<I>null, not pre-bound to any key.oscmd, pre-bound to: <Alt>-<1>setup, bound to: <Alt>-<T>shell, bound to: <Alt>-<O>toggleq, bound to: <Alt>-<Q>quit, bound to: <Alt>-<S>
If you are dissatisfied with the default keyboard bindings, you can easily
change the keyboard layout. Each of the message reader and message editor
keyboard functions that have been listed on the previous pages can be
assigned an arbitrary keystroke using the ReadKey and EditKey
configuration keywords. The syntax of these commands is as follows:
EditKey keycode function-name
ReadKey keycode function-name
The keycode parameter designates wich keystroke you want to redefine. In order to find out the key code matching a certain keystroke, invoke the executable of MsgEd TE with the ‘-k’ option. You can then press the desired keystroke, and MsgEd TE will print out the key code that you have to use as keycode parameter in the configuration file. Here is an example session:
[R:\mailer\msged]msgedp -k
Displaying keyboard scan codes in hexadecimal form.
Press any key or key combination, or 'q' (lowercase 'Q') to exit.
Key: 0x2100
Key: 0x0071 (q)
I pressed <Alt>-<F> and q to reproduce this output. From the output, we can see that <Alt>-<F> has the keycode ‘0x2100’, and q has the keycode ‘0x0071’. Keycodes might vary depending on your hardware and operating system. Also, on UNIX consoles sometimes keys are not mapped correctly at all, in which case different key combinations might have the same key code. If you find one where this is problematic, contact me for a bug report.
Now that you know the proper keycode, you can assign it to any reader or editor function. See Keyboard Commands and Functions in Message Reading mode, for a complete list of available keyboard functions for message reading mode. See Keyboard Commands and Functions in the internal Message Editor, for a complete list of available keyboard functions in the built-in message editor.
As an example, let us assign the keystroke <Alt>-<F> to the ‘wordright’ editor function:
EditKey 0x2100 wordright
With this line in your configuration file, you will be able to press <Alt>-<F> in order to move the cursor to the beginning of the next word.
MsgEd TE has to be configured using a configuration file. This is a plain text ASCII file containing a list of keywords, settings and switches that define the behaviour of MsgEd TE. The configuration file is named msged.cfg and should normally be placed in the current working directory of MsgEd TE. (On Linux/Unix, it is named .msged instead and placed in your home directory).
This chapter describes the syntax of the configuration file and lists all avilable keywords and switches in alphabetical order.
Each line in the configuration file should start with a keyword. Each keyword can be followed by zero or more free-form parameters.
A special case of a keyword is the ‘switch’ keyword. Using the ‘switch’ keyword, a switch can be turned either on or off. see Switches, for more information.
When parsing the config file, lines that start with a semicolon or with a semicolon preceeded only by whitespace are treated as comments.
Within the configuration file, you may use environment variables. Enclose the name of the environment variable within percent signs. For example, if you give a command like ‘"Areafile %MAILBOX%\squish\squish.cfg"’, the string ‘%MAILBOX%’ would be replaced with the value of the environment variable ‘MAILBOX’.
You can also disable or enable certain parts of the configuration file based on the value of environment variables or on the operating system by using Conditionals. See Conditional Statements in the Configuration File, for more information.
The following keywords can be used in the configuration file. Keywords are generally case-insensitive.
Address AKA
Address 2:2476/418.0
The Address command specifies your FTN network address.
AKA is a FTN network address with up to five dimensions. The
Address keyword can be repeated as often as is desired to specify
multiple addresses.
Alias alias "name" address [attribute ["subject"]]
Alias tobias "Tobias Ernst" 2:2476/418.0
Alias tobi "tobi@bland.fido.de" UUCP
Alias af "Areafix" 2:2476/418.0 p "PASSWORT"
Aliases are used to simplify the entry of new messages. When you enter a new message and type in the previously defined alias into the name field, all the other fields will be filled in with the values that you have provided in the alias definition. You must at least specify the sysop's name in quotation marks and the corresponding FTN address in up to five dimensions.
Alternatively, you may specify ‘UUCP’ as address. In this case, the name field is interpreted as an internet e-mail address and the mail is addressed to the corresponding gateway.
Optionally, you may also specify one or more message attributes and a message subject. The attribute field is a combination of one or more of the following letters:
phcknNote that you must always specify at least one message attribute (at least ‘n’) if you want to specify a subject.
This keyword is presently undocumented.
AreaExcl pattern
AreaExcl ALT.BINARIES.*
This keyword is used to exclude certain areas from the area selection menu. All area names that match pattern will not be displayed in the area selection menu and thus will not be accessible. The pattern parameter may be a simple area name or a wildcard pattern containing the joker characters ‘*’ and ‘?’.
You must specify the AreaExcl keyword in the configuration file
before the Squish, Fido, Quick and
Areafile keywords.
These keywords are documented in the section about area configuration (see Reading a Tosser Configuration File (Areafile)).
AssumeCharset charset
AssumeCharset IBMPC
In Fidonet mail, mails that contain special characters must carray a charset kludge line (see Using Special Characters - The FSC 0054 Charset Kludge). However, still a good percentage of fidonetmail contains special characters, but no charset kludge line. Also, people often use wrong charset kludge names.
By default, MsgEd TE will replace all special characters with question
marks in mails without charset kludge or with unknown charset kludge,
because MsgEd TE does not know how to properly translate such special
characters. If you do not like this, you can use the AssumeCharset
keyword to specify that MsgEd TE should assume that all special
characters in mails that do not contain a charset kludge, or have a unknown
charset kludge, have been composed using the character set charset,
and translate the special characters accordingly.
In Germany, for example, nearly all mail that contains special characters but does not contain a charset kludge has been composed using the IBMPC character set, so it makes sense to specify ‘AssumeCharset IBMPC’ here.
In Russia, it is best to use ‘AssumeCharset CP866’.
CharsetAlias charsetInMail charsetAsKnownToMsged
CharsetAlias IBMPC CP850
As already noted in the previous section, a lot of mails in Fidonet contain
charset kludges that do not adhere to the current FTSC standard for 8-bit
character transport, FSP1013. Using the CharsetAlias keyword,
you can tell MsgEd TE how to map character set kludge names
commonly found in mails to their official names.
The most prominent example is the IBMPC charset kludge. This kludge
line is now obsoleted and should be replaced by CPxxx charset
kludges, where xxx stands for the codepage that is used. MsgEd TE
only knows about the new CPxxx charset. Therefore, you need to
use CharsetAlias to tell MsgEd TE how to interprete a
IBMPC charset kludge. Now this is difficult, because, if the
IBMPC charset kludge is not followed by a @CODEPAGE kludge
line, you do not know which codepage the author of the mail has
used. According to FSC0054, he should have used codepage 437, but in
Western Europe for example the majority of users put IBMPC charset
kludge lines into their mails, but actually use codepage 850, and in Russia
the same applies for codepage 866. This means that you have to do
assumptions. A users who reads mainly texts in Western European languages
should probably use CharsetAlias IBMPC CP850, while when you intend to
read Russian echomail, CharsetAlias IBMPC CP866 is probably the right
thing to do.
Also, some users are simply using fantasy names for the CHRS kludge
line. The following commands have also proven to be handy:
CharsetAlias +7_FIDO CP866
CharsetAlias RUFIDO CP866
CharsetAlias ASCII CP437
Color item foreground _background
Color MainNorm White _Black
Use this to customize the colors that MsgEd TE uses. For a list of available color values and items, refer to the sample color scheme files.
If you are using the Unix version of MsgEd TE, you must also switch on the
Colors switch in order to get a non-monochrome display. See Colors in the Unix version, for more information.
Colour is an alternative name for the keyword Color
(see The Color Keyword.
CurStart row
CurEnd row
CurStart 5
CurEnd 7
This keyword is used to control the shape of the cursor (only on terminals and operating systems that support it). On typical DOS-like consoles, the cursor constis of 8 rows, labelled top-down from zero to seven. You can specify a cursor start row and a cursor end row. The MsgEd TE default values of 6 (start) and 7 (end) result in a standard "underline" cursor.
If you are using MsgEd TE with a monochrome display adapter like MDA,
MGA or HGC, the cursor consists of 14 rows instead of 8. There, you will have
to use the CurStart and CurEnd keywords to produce a sensible
cursor shape. Values of 11 for start and 12 for end are suggested for mono
display adapters.
Domain 5d-address
Domain 8:123/45@rbbs
Messages sent with the destination domain equal to the domain of one of the
configured domain gates will always be sent to the domain gate with a @DOMAIN
kludge inserted into the message. To enable domain gating, you must
configure all domain gates you are using in your config file by using a
Domain keyword with the full 5D address of the domain gateway
(including the domain that this gate is gating for) as 5d-address
parameter for each domain gate. You also must have the Gate config
verb set to either ‘both’ or ‘domains’. See The GAte Keyword, for more information.
With this done, MsgEd TE will gate any messages being saved with a destination domain listed as one of the gates. Note that for this to occur, the destination domain must be different than your own.
Confused? Luckily enough, most users don't have to deal with domain gating ...
EditKey key function
This keyword is used to redefine the keyboard layout in the internal message editor. See Redefining the Keyboard, for more information.
Editor program-name
Editor c:\boxer\b2.exe
This command allows you to specify an external editor to use when writing messages. The editor program (specified as executable filename with full path as the program-name parameter) must accept a filename as the first and only parameter.
Before you decide to use an external editor, you might first want to look at
the built-in editor of MsgEd TE. Using the EditKey keyword, the
built-in editor is highly configurable to emulate the keystroke combination
that you are used to use from your preferred external editor, and you can
safe a lot of unnecessary overhead and gain a lot of comfort when using the
internal editor as compared to the external one.
EnableSC [string]
(The example from above will only look correct in the TeX (.DVI or .PS or .PDF) edition of this document.)
This keyword is only relevant on UNIX. On UNIX, when using a VT100, xterm, or similar terminal, <Alt> or <Meta> key combinations generate the same key codes like national characters with ASCII values greater than 127. This is a problem, because on the one hand, MsgEd TE relies on combinations of normal keys with Alt, but on the other hand, you probably want to use national special characters in your mail.
By default, the UNIX version of MsgEd TE enables all <Alt> key combinations and disables all national special characters.
You can revert this behaviour by specifying EnableSC without
parameters. This will cause MsgEd TE to interpret all high ASCII
keycodes as national special characters, instead of <Alt> key
combination. You'll then have to use the <ESC> key to emulate all
<Alt> key cominations. This is probably what users of complete
high ASCII alphabets, like the cyrillic alphabet, will wnat to do.
On the other hand, if your language only has few special characters, you can
also use the EnableSC keyword to selectively enable some national
special charcters. All special characters that occur in the string
given as argument will be interpreted as charcters rather then <Alt> key
combinations.
The example from above enables all German national charcters. The only relevant <Alt> key combination that you will loose by enabling those characters is <Alt>-<V> (“show notes”). This function is also available by pressing <Alt>-<K> (“show kludges”), so that isn't a problem.
Note that you will have to use an editor that allows the input of national
charcters in order to generate the necessary configuration file
entry. vi should be able to do this, as well as joe -asis. If
you are not able to type those characters in vi, you should not even try to
type them in MsgEd TE ...
If you need information on how to set up a FreeBSD system to correctly process special national characters, you can f`req syscons.tgz at 2:2476/418.
This keyword is described in the section about manual message area definition (see Manual Area Definition).
FreqArea area-tag
FreqArea NETMAIL
This keyword defines the message area where file request messages will be written when the <Ctrl>-<F> function is invoked. If not defined, ‘NETMAIL’ is the default areatag. Only one file request area may be defined.
FreqFlags flag [flag ...]
FreqFlags CRA K/S
This keyword defines the flags that are set for file request message generated using the <Ctrl>-<F> feature. If not defined, ‘DIR K/S’ is the default. The ‘FRQ’ flag will be appended in any case, so will the local message area flags (usaually ‘PVT LOC’). Any flags defined in FSC 0053 are electible, yet the only ones that are useful for file request messages are listed below.
HLD place file request on hold for the caller CRA crash delivery, dial out as soon cost setup permits it IMM immediate deilivery, dial out immediately DIR direct mail, you have do dial out manually K/S kill the file request mail after it has been sent
You should at least specify one flag out of ‘HLD CRA IMM DIR’, because if none of these is present, the file request will be routed and consequently be ignored by the destination system.
If you want to specify multiple file request flags, separate them by white spaces, as shown in the example above.
Function number keystrokes
Function 11 \0x17D:\\text\\*.*^M
A function key macro is a predefined keystroke sequence that is assigned on a function key. If you press this function key, MsgEd TE will do exactly what it would have done if you have typed in all the keystrokes of this macro manually.
The following function key numbers (to be used as the number parameter) are available:
01 .. 1011 .. 2021 .. 3031 .. 40Note that function key numbers 11 through 40 might not work on Unix.
When using key scancodes in a macro, you must escape them with a backslash character (‘\’). If you wish to have a literal backspace character appear in the macro string (e.g. if it's needed as part of a path to a file), use two backslash characters, like in the example above.
The example from above will assign <Shift>-<F1> to display a pick list of the files in the D:\TEXT directory. After the list is displayed, you may select a file to import into a message while in Msged's internal editor. Note that control characters in a macro such as ^M (Enter) must be written in UPPER case.
Gate what
Gate Zones
Gate Domains
Gate Both
Gate Ask
The what parameter to the Gate keyword specifies if
MsgEd TE should do zone gating (Gate Zones), domain gating
(Gate Domains), or both (Gate Both). If you specify Ask
as parameter (this is also the default), you will be asked if you want to use
zone gating for each inter-zone mail that you write.
This has nothing to do with internet gateways!
Domain gating is explained in detail in the section about the Domain
keyword (see The Domain Keyword).
Zone gating works like this: If you write a mail to a node in a zone different from your own, and zone gating is enabled, the mail will not be addressed to the receiver in the other zone, but it will be addressed to that zone's zone gate (which also has an address inside your own zone). The address of the true receiver will be encoded in an @INTL kludge line.
If you don't have a direct inter-zone link set up in your tosser, you may
always enable zone-gating on with the Zone parameter. All mail that
crosses zone boundaries will then be sent via the zone gate, which is by far
the most reliable mail to send inter-zone mail. If, on the other hand, you do
have a direct inter-zone netmail link, you need the Ask parameter,
because then you must decide for each netmail individually if it shall be
sent directly via this link, or (probably because it is for a zone not
covered by this link, or because the link partner has not agreed to forward
mail not destined for himself) must be sent via the zone gate.
Turning zonegating off with the None parameter is not at all
recommended. If you send inter-zone mail wihtout zone-gating, there only need
be one single tosser on the routing path which does not recognise INTL
kludges, and the mail will probably disappear. So, don't turn off zonegating
unless you have direct links for the destination zones you are writing mail to.
Group "groupname" [pattern]
Group "OS/2 Echos" *OS2*
This command is used to set up area groups and add areas to those groups. See Manually Defining and Assigning Groups, for a full documentation on how to use this keyword. See Configuring and Using Message Area Groups, for an overview on the group concept of MsgEd TE.
GroupSettings "groupname" name-index template-index
GroupSettings "OS/2 Echos" 0 1
This command allows you to select different user names and/or template files based on the group a message area belongs to. For example, you might wish to use a different signoff in OS/2-related areas (probably stating your TeamOS/2 number) than in other areas. Or, if you are moderator in a certain area, you might want to use the user name "Moderator" instead of the user name that you are using in normal areas.
The groupname parameter to the GroupSettings command specifies
the name of the group. See The Group Keyword, for
information on how to define groups and add areas to those groups.
The name-index parameter then specifies the index number of the user
name that should be used for all areas in this group. User names are counted
from zero upwards, so if you have two or more Name keywords in your
config file, the name specified with the first Name keyword will have
an index number of 0, the second will have 1, and so one. See The Name Keyword, for more information.
The template-index number defines which message template file should
be used for areas belonging to this group. The first message template file
that you have specified with the Template keyword has number 0, the
second has number 1, and so on. Note that if you want to specify multiple
template files, you have to repeat the Template keyword for each
file. The Template keyword itself can only take one argument.
See The Template Keyword, for more information.
HelpFile file-name
HelpFile e:\fido\msged\msghelp.dat
Specify the complete path and file name of the compiled MsgEd TE help file here. It is usally named msghelp.dat, or ~/.msged.help on Unix.
Include file-name
Include scheme.001
The file specified with the file-name parameter will be read in and parsed as a normal config file. This is often used for including color scheme configuration files.
This keyword is described in the section about manual message area definition (see Manual Area Definition).
Lastread lastread-file
Lastread lastread
The lastread-file parameter of this keyword specifies the name of the
default “lastread file” that is used to store lastread pointers for Fido
*.MSG areas. This keyword gives the default filename for those username
entries without individual lastread files configured via the Name
keyword. See The Name Keyword, for more information.
If you do not specify this keyword, a default value of ‘lastread’ is assumed, which is a very resaonble default. Hence, you normally do not need this keyword.
MaxX columns
MaxY rows
MaxX 80
MaxY 25
The MaxX and MaxY keywords are used to define the screen or
text window size MsgEd TE is running in. Normally this will be
autodetected and MsgEd TE will automatically use the full window
size. For example, on OS/2, you could execute ‘MODE CO100,40’ and then
start MsgEd TE, and it will automatically use 100 columns and 40 rows.
In some cases, however, the autodetection fails, or you might not want
MsgEd TE to use the full screen size. In this case, you have to define
the screen or window size manually with the MaxX and MaxY
parameters.
MountDir unix-path dos-path
MountDir /mnt/c c:\
This keyword is used to tell the Unix version of MsgEd TE how it can translate DOSish pathnames found in squish.cfg, fastecho.cfg or even msged.cfg files that are mounted via NFS, rumba or smbfs from a DOS, OS/2 or Windows machine.
Suppose you are having a message base that is stored in ‘c:\msgbase’ on your OS/2 or Windows machine. Also suppose that your complete C: drive on the OS/2 or Windows machine is mounted as /mnt/c on the UNIX machine. (The Windows machine and UNIX machine can be two distinct machines connected via network, or a single machine with multi boot, where UNIX can mount the OS/2 or DOS partitions).
You can then install MsgEd TE on the Unix machine and let it read in the
same configuration files that are also used on the OS/2 or Windows
machine. Simply put MountDir /mnt/c c:\ into your configuration
file. When MsgEd TE is running on OS/2 or Windows, it will ignore the
keyword, but when it is running on Unix, it will know how to translate the
DOS-like filenames found in the corresponding configuration files into file
names that are correct for the UNIX system.
Please note that you can have only one MountDir statement in the
configuration file.
Name "name" [lastread-file [user-offset]]
Name "Tobias Ernst"
Name "Joe Sysop" lastread 0
Name "Jane Sysop" lastread 1
You can specify your user name as the name parameter inside quotation
marks here. You can specify more than one user name by repeating the
Name keyword. Then, you can select which name to use during program
execution by pressing <CTRL>-<U>.
Optionally, you can use the lastread-file parameter to specify the name of the file that stores the lastread pointers in Fido *.MSG areas. This one should be named ‘lastread’ for the sysop. If you configure other users with the same config file, e.g. your wife, son etc., you should give them separate lastread file names, so that each person can have individual last read pointers.
As a third parameter, you can specify a user-offset for each individual name. This is used for all message base formats excpet *.MSG. Here, all users share the same lastread pointer file (with a fixed name that cannot be configured), but each user has a different offset into this file where he can store his personal lastread pointer.
Normally, the sysop has a user offset of zero (which is the default for the user-offset parameter), and each BBS user has his user number as user offset. However, if you have two or more sysops (in this context, this simply means persons accessing your message base directly with MsgEd TE instead of using the BBS), you must manually assign unique user offset numbers for each person.
NodePath path-name
NodePath e:\fido\nodelist
MsgEd TE can use compiled version 7 nodelists to perform nodelist
lookups. All files pertaining to all version 7 nodelists, i.E. the compiled
index files and the raw nodelist files, must be stored in the V7 nodelist
directory. The NodePath keyword is used to tell MsgEd TE that all
v7 nodelist files reside in the directory named
path-name. See The Nodelist Keyword, for more
information.
Nodelist domain-name base-name sysop-file
Nodelist fidonet nodex sysop.ndx
MsgEd TE can use compiled version 7 nodelists to perform nodelist
lookups. With the Nodelist keyword, you specify the v7 nodelists that
MsgEd TE should use. All three parameters are mandatory.
The domain-name parameter specifies the name of the domain that is
used when picking which nodelist to use for address lookup if the zone number
is not unambiguous. The base-name parameter specifies the base name of
the index file minus the extension (e.g. ‘nodex’ for ‘nodex.idx’),
and sysop-file is the name of the sysop lookup file. You must not
specify any path names for the latter two parameters - these files must
always reside in the directory pointed specified as argument to
NodePath. See The NodePath Keyword, for more
information.
Normally, you will compile all raw nodelists that you have into a single v7 index. In this case, simply use the example from above. You will only have to bother about separate indices, domain names and the like if you have two distinct othernets with identical zone numbers.
Origin string
Origin We love MsgEd TE!
The origin line terminates an echomail and tells the sender`s FTN address. Thus it has an important technical function. On the other hand, the origin line also leaves space for about 55 bytes of free-form text. They can be used to place your BBS system's name there, but you can also place other meaningful or meaningless messages there. The text that you specify as the string parameter may include whitespace characters. It will simply be copied into the origin line, but be aware of the fact that MsgEd TE might have to truncate the text in order to prevent the origin line from getting longer than 79 characters.
You can use macro tokens in the origin line to provide some sort of dynamic information. The macros will be expanded to their value when the message is saved. The following macros can be used:
@N@F@L@Y@D@DD@DW@DM@DY@D4@DC@T@S@A@I@Q@@In MsgEd TE, you can also specify more than one Origin keyword in
the configuration file. MsgEd TE will then automatically select a random
line out of those that you have specified each time that it has to generate
an origin line. This feature is called origin shuffling.
Outfile file-name
Outfile export.txt,t
This keyword is used to configure the default file-name that should be used as a default selection for exporting mails as text by pressing <Alt>-<W>.
OutputCharset charset
OutputCharset IBMPC
This specifies which character set should be used for writing messages with special characters (like umlauts, accents, cyrillic letters, IBM graphics). The mail will be converted into the given charset, and the proper charset kludge will be appended. This does only apply to areas which have the ‘8’ flag set, because in all other areas, the messages will always be converted into a 7-bit ASCII representation.
The charset that you specify as charset argument must be a level 2 charset, and a matching translation table must be contained in the writmaps.dat file. If there isn't such a table, you will only see this from the fact that the written message will contain 8-bit characters, but no charset kludge(!). So be careful not to misspell the option.
See Using Special Characters like Umlauts or Cyrillics - The Charset Kludge, for more information on the concept of
charset kludges. You can list all charset kludges that are listed in this
section as arguments to the OutputCharset keyword, but usually
IBMPC is the right option to choose, according with a proper
CharsetAlias definition (see The ChrasetAlias Keyword). Msged TE will then also emit a proper CODEPAGE kludge. A
Russian user will probably want to use CP866. Once the CPxxx
charset kludges have found more widesprad use in Europe, OutputCharset
CP850 should replace OutputCharset IBMPC also in Western European
countries.
The character set that you use for output does not need to match the charset that your computer is using internally; MsgEd TE will do all necessary conversion.
Printer printer
; On UNIX:
Printer -Phplj4
; On OS/2, DOS, Windows:
Printer LPT3:
This keyword is used to configure the printer that MsgEd TE will use when printing a message (<Alt>-<W>). The usage of this keyword depends on your platform:
On OS/2, DOS and Windows, it specifies the special device filename for
printing. The default value is PRN. Other values that make sense are
LPT1:, LPT2: and so on.
On UNIX, MsgEd TE prints by piping the message text into the lpr
command, and the Printer keyword is used to configure additional
options to the lpr command. By default, no additional options are
used. If, for example, you do not want to use the default queue, but the
queue named ‘hpjl4’, you would use Printer -Phplj4 in your
configuration file.
PrivateNet fakenet-number
PrivateNet 12345
PrivateNet keyword. However, if you are operating a point system
whose boss node uses a "fakenet" to service points, this keyword should be
used.
The fakenet-number parameter specifies the private net number number to use for non-4D points. The fakenet point scheme was designed to work with systems which were unable to support true points, such as BinkleyTerm 2.40 and lower. The actual "fakenet" number and address must be assigned to you by your boss node.
This keyword is described in the section about manual message area definition (see Manual Area Definition).
QuickBBS path-name
QuickBBS e:\fido\hmb
In order to use a hudson message base (also known as Quick BBS message base),
you have to specify the path where the HMB files are stored using the
path-name parameter of the QuickBBS keyword. You must specify
the QuickBBS keyword in the configuration file before any Quick
or AreaFile keyword.
Quote quote-string
Quote _&>_
When quoting a mail, every line of quoted text will be prefixed with quote-string. The following tokens inside the quote string have special meanings:
&_^*Following common fidonet practice, you should use ‘_&>_’ as quote string.
QuoteRight column
Quoteright 75
The column argument specifies the right margin to use when quoting text. Because quoted text - in contrast to normal text - is stored with a carriage return after each line, you should not specify a value greater than 75 in order to assure that the text can be displayed on standard 80 columns displays without problems.
ReadKey key function
This keyword is used to redefine the keyboard layout in message reading mode. See Redefining the Keyboard, for more information.
Readmap filename
Writemap filename
Readmap /usr/local/share/msged/readmaps.is1
Readmap /usr/local/share/msged/writmaps.is1
or
Readmap c:\msged\readmaps.850
Writemap c:\msged\writmaps.850
These keywords are used to tell MsgEd TE where to find the character set translation map files. See Using Special Characters like Umlauts or Cyrillics - The Charset Kludge, for a detailed explanation.
Right column
Right 79
The column argument specifies the right margin to use when writing normal text. Normally, there is no reason to use this parameter, as MsgEd TE will always simply use the width of the window or console it is running in. Please note that because of the way text is stored in Fidonet messages (carriage returns are only placed at the end of a paragraph), it is no problem to use right margins higher than 80. Even then, users with only 80 columns will still be able to read your message nicely formatted.
RobotName name
RobotName Areafix
Using the name parameter of the RobotName keyword, you can
specify names of robot machines like Areafix, Allfix, VoteMgr and so on. Each
RobotName keyword only accepts a single name parameter, but you
may repat the RobotName keyword as often as necessary.
The reason for defining the names of common fidonet robots is the following: When writing a mail that is addressed to a user name that matches one of the defined robot names, MsgEd TE will not insert the usual message template. (VoteMgr will be confused if the first line in your Message is "Hello VoteMgr" instead of the expected meta command ...).
Scan
If this keyword is specified, MsgEd TE will automatically scan all message areas on startup.
SoftCrXlat ascii-code
SoftCrXlat 72
Fidonet, historically, has a problem with the character with ASCII code 142 (0x8D). The FTS 0001 document says the following about this code:
So called 'soft' carriage returns, 8DH, may mark a previous processor's automatic line wrap, and should be ignored.
Despite of the fact that I do not know any single mail editor which adds stray 0x8D characters into a mail, without the SoftCrXlat keyword, MsgEd TE behaves exactly like this: It ignores any 0x8D that it finds in a message, i.E. it simply does not display it.
This may be a problem for you because some languages need to use that character. For example, in codepage 866, this code represents the cyrillic big en, or in codepage 437, it is an i with accent grave.
Specifying the SoftCrXlat keyword changes the behaviour of MsgEd TE in two ways. First, as soon as this keyword is present and has a non-zero numerical argument, Msged will no longer ignore any 0x8D character in the input, but display it as a normal letter. So if other people use those characters in their mails, you will be able to see them.
Second, if you yourself type a character which, in the transport character set that you have chosen (see The OutputCharset Keyword), would result in a character with hex code 0x8D, it will be replaced with the character that has the ASCII code which is specified as argument when the message is being saved. In the example above, any 0x8D would be replaced with a character with code 72, which is the latin big H. This would be the ideal setting for a user in Russia, who has to use codepage 866 as transport character set, because the latin big H looks exactly like the cyrillic big en.
So a Russian user who specifies "SoftCrXLat 72" will be able to see any big en character that other users write, and any big en character that he writes will be replaced with it's low-ASCII-look alike, thus avoiding problems at other message readers.
Now suppose that you don't want to translate the 0x8D character
to any other value. If your language uses the i with accent grave, for
example, there is no other equivalent of this character, so you could only
change it to an i without accent grave, which you might not like. In this
case, you can also instruct MsgEd TE to keep the 0x8D character as is,
by setting SoftCrXlat 141 (141 is the decimal representation of
0x8D). With SoftCrXlat 141, the 0x8d character becomes an ordinary
character for MsgEd TE, i.E. it does not behave different to any other
character any more.
However, be aware of the fact that this might cause problems on other systems that behave according to FTS 0001 and ignore any 0x8D characters. Another option specifically for the language that needs the i with accent grave would of course be not to use codepage 437 or 850 as transport character set, but to use Latin-1 (ISO 8859-1). In this charset, all printable characters are at non-critical positions.
SortAreas criteria
SortAreas GND
Normally, MsgEd TE displays all message areas in the order in that they have been defined in the configuration file and/or in the area files.
With the SortAreas keyword, you can instruct MsgEd TE to sort the
areas by certain criteria. The criteria parameter is a string that
consists of letters each specifying a sort criterium. The leftmost letter is
the most significant. The following letters can be used to define sorting
criteria:
NTDGThe meanings of ‘D’ and ‘T’ may vary depending on which area file you imported the area from. T is the true area tag, while D is what you actually see on screen. You will usually wish to use D, because ordering by what you see seems to be more logical than ordering by what you don't see.
The ‘G’ criterium works on MsgEd TE area groups. An area can belong
to a group either because you used the Group statement to add it to a
group, or because the group setting has been imported from a tosser
configuration file. When areas are sorted by group, those areas that do not
belong to any group will come first, followed by the members of the group
that has been defined first, then those of the group that has been defined
after that one, and so on.
Please note that the arealist feature of displaying Group separators can of
course only work if the ‘G’ ciretrium is the first criterium in your
SortAreas statement.
This keyword is described in the section about manual message area definition (see Manual Area Definition).
SwapPath file-name
SwapPath c:\temp\msged.swp
Use the filename and path to your swapfile as value vor the file-name parameter. This is only for DOS users but it should definitely be used. If you don't use it, you must return to the Msged directory before returning to the editor.
This keyword is explained in the section about configuration switches (see Switches).
Tabsize size
Tabsize 8
When you enter a message and press the <TAB> key, it will be expanded
into the number of white space characters that you have specified as
size argument to the Tabsize keyword. <TAB> characters in
other messages will not be expanded.
Template file-name
Template msged.tpl
The template file is used to define standard "hello strings", signoff
messages, and much more. See the provided sample template file for
information on how to do this. Specify the filename of your template file as
the file-name parameter to the Template keyword.
You can specify multiple template files by repeating the Template
keyword on a new line for each filename, but the Template keyword
itself can only take one argument. See The Group Keyword,
for applications of this.
TossLog file-name
TossLog echotoss.log
The log file named file-name will contain a list of area tags of all areas into which you have entered messages. Such files are usually named echotoss.log or confmail.out and are used by tossers to accelerate the scanning process. In MsgEd TE, the echotoss log file is updated immediately as soon as you have entered a new message.
UserList filename
UserList e:\nodelist\fidouser.lst
The fido user list file is a text file that contains all fidonet sysop names
and the corresponding node numbers. It is used for looking up node numbers by
sysop name. A fido user list file is typically named fidouser.lst. You
can specify up to two fido user list files by repeating the UserList
keyword.
Note that even when you are using a version 7 lookup, it is still preferable
to also have a fidouser.lst file and to use the UserList
keyword, because only the fidouser list file lookup routines of MsgEd TE
can deal with multiple matching node numbers for one sysop name (they will
present you a list to select from), while the V7 lookup routines currently
cannot do this.
The exact format of a fido user list file is as follows: Each line in this
file must have eactly the same length. Sysop names are left justified and
node numbers are right justified. Node Numbers must come after column 40. The
file must be sorted alphabetically in a way like the C strcmp()
function would do it.
UserOffset user-offset
UserOffset 0
See The Name Keyword, for information about the meaning of
the user-offset parameter and lastread pointer principles. The
UserOffset keyword specifies a default user offset number valid for
those users that do not have their individual user offset number configured
in their Name statement.
UUCP address
UUCP 242:4900/99.0
The address parameter designates the FTN address of the gateway that your are using to send Internet/Usenet e-mail. See Using MsgEd TE for e-mail and newsgroups, for more information.
UucpName name
UucpName UUCP
Some Internet gateway software requires that mail addressed to the gateway
must be addressed to a specific user name in order to be gated into the
Internet. This specific user name is usually ‘UUCP’, and you can specify
it as the name parameter to the UUCP keyword.
If your gateway is using a better gateway software, like Fidogate, it will not have this restriction. Instead, such gateway software uses the name fields in the FTN header to exchange real name information. In this case, you should specify ‘UucpName *’, which tells MsgEd TE that the gateway software allows any name to be put into the FTN header field.
See Using MsgEd TE for e-mail and newsgroups, for more information.
UucpReplyTo email@address
UucpReplyTo user@some.domain.com (Joe Sysop)
The Internet e-mail standards specified so-called ‘Reply-To:’ header lines. The presence of such a header line speicifes that any reply to this message should not be sent to the sender of the mail, but to the alternate e-mail account that is specified in the ‘Reply-To:’ header.
A common scenario is the following: You have two e-mail accounts, one at home and one at your university or at your office. You have set up the account at your university to send copies of all incoming messages to your account at home. Then you want, of course, that all replies to any e-mail you write are directed at your university account, because you can read any mail that arrives at the university both at the university or at home, while an e-mail that you receive at home won't be visible at the university. Therefore, if you are writing an e-mail from your home account, you want to insert a ‘Reply-To:’ header line that points at your university account.
If you sepcify the ‘UucpReplyTo’ configuration keyword, Msged will insert such header lines whenever a netmail is created that is addressed to your UUCP gateway. The e-mail address that you specify as arugment to the ‘UucpReplyTo’ keyword may also include realname configuration in parentheses, like shown in the example above. The header line that is created by the example above would look like
Reply-To: user@some.domain.com (Joe Sysop)
Please note that of course the whole thing can only work if your gateway
software can recognise Reply-To: headers in fido netmail. As always,
Fidogate can, while others probably can't.
Writemap filename
See The Readmap and Writemap Keywords, for more information.
Switches are used to configure the behaviour of MsgEd TE. In contrast to a full configuration keyword, which is used to pass detailed parameters to MsgEd TE, a switch toggles a simple state that can be turned on or off. Switches are usually used to switch certain features on or off.
To turn a switch on or off, you can use the Switch keyword, which has
the following syntax:
Switch switch-name On
Switch switch-name Off
The switch-name parameter must be the name of a valid switch (a complete list of switches follows below). The first line from above turns the selected switch on, the second turns it off. (You knew it before, did'nt you? <g>).
For example, in order to turn the SEEN-BYs switch on, you would add
the following line to your configuration file:
Switch SEEN-BYs On
The following switches are available:
AdaptiveCaseAdaptiveCase switch is only relevant if you are running the
Unix/Linux version of Msged. It should be turned on if you are accessing
DOSish file systems (via Samba, NFS or the FAT or HPFS file system drivers),
from Msged running on Unix, or if DOS programs have access to your Unix file
system. DOSish fidonet programs usually create a really messed up message base
with mixed case spelling (i.E. it might contain both .MSG,
.msg and .Msg file name extensions in a single netmail
directory). If the AdaptiveCase switch is turned on, each time that
Msged tries to open or create a file, it will first do a search over the
directory to determine the correct spelling of a file. This enables Msged
to cope with such mixed spelling as it is often found in DOSish message
base directories. - On the other hand, if only Unix programs have access to
your message base and the message base is stored on a Unix file system, you can turn this
switch off. This will give you a little performance improvement and save you
about 200 kilobytes of memory (which is otherwise used for directory
caching). Default: Off.
ArealistExactMatchArealistExactMatch switch, any substring is matched in an area
search; you don't have to type an area name from the beginning. Default: On.
ChopQuoteBS127BS127 switch on. You will probably want to enclose the Switch
BS127 On statement in a Conditional that tests if the TERM
environment variable is set to Linux. See Conditional Statements in the Configuration File, for more information. Default: Off:
Carthydelete_line function of
the internal message editor, which is usually bound to <Alt>-<D> and
<Ctrl>-<Y>, for the special case that you delete the very last line
of a message. If the switch is on (default behaviour), the last line will be
cleared, but the cursor will remain there. This way, if you are in the middle
of a message and press <Ctrl>-<Y> multiple times intending to zap the
rest of the message, you will never delete anything that is above the line
where you started to press <Ctrl>-<Y>. If you turn the switch off
(behaviour of older versions of Msged TE), the last line will be deleted
completely, and the cursor will be moved to the previous line. The switch
name ‘Carthy’ is an appreviation for the function description,
“Cut And Remain THere when pressing
Alt+Y on the very last line”. Or well ... the true reason is
that there was a user named Matt Mc_Carthy who really got mad about the old
behaviour of the editor, so I implemented the switch and the new behaviour
for him. Default: On
ColorsColor
configuration keyword, nor include any color scheme file, as long as this
switch is disabled. See Colors in the Unix version, for more
information. Default: Off for Unix, On for all other versions.
ConfirmDateArvdDirectListDMoreDomainMsgidDomainOriginEchoFlagsEditCROnlyEditTearLinesEditOriginLinesExtFormatGroupSeparatorsSortAreas Keyword,
for information on how to make MsgEd TE sort your area list by area
groups. See Configuring and Using Message Area Groups, for an
introduction on how to use groups with MsgEd TE. Default: On.
HardQuoteImportFNImportFN switch off. Default: On.
LowerCaseLowerCase switch on, MsgEd TE will convert all
file names that it reads from the configuration file or from any areafile to
lower case before it attempts to read to, write from, or create any
file. This switch is not very helpful - if you think you need it, you should
probably use AdaptiveCase instead.
MSGIDsNetmailViaOpusDateOriginsPseudoGraphicsQQuotesRawCCSaveCC switch is turned on.
Then, if RawCC is on, the raw cc: msg is saved (along with the cc:
header that you typed in, so that if you re-edit the message, also all carbon
copies will be re-generated). Otherwise, the first formatted cc: will NOT be
marked kill/sent and will therefore remain as a future reference, but the
original raw message will not be saved. Default: On.
RealMsgNReceiveAllNames and ReceiveAllAddressesRvd flag of a
netmail is turned on, indicating that the mail has been received (read) by
you. When these switches are turned on, the flag is set whenever the
destination address of the mail matches any of your AKAs, and whenever the
destination user name of the mail mathes any of the user names that you have
configured with the Name keyword. Default: Both On.
You should turn off ReceiveAllNames if you have configured multiple
user names that belong to different persons (i.E. you and your girl friend /
boy friend <g>). In this case, only the user name that currently is active
will count when determining if the message is addressed to you or not. You
can switch the active user name by pressing <Ctrl>-<U>.
RightNextUnreadAreaSaveCCSeen-BysShowSeenBys switch. See below.
ShadowsShowAddrShowCRShowEOLShowCR switch
is also turned on. Default: Off.
ShowNotesShowOriginsShowSystemShowTearlinesShowSeenBysShowTimeSOTEOTDomainOrigin and SOTEOT
configuration switches are enabled, MsgEd TE will exit and suggest to
disable one or the other. Default: Off.
SquishLockSquishLock switch is turned on, MsgEd TE will lock every
message area that is entered (and of course unlock it when it is left), thus
effectively denying access to this area to any other program. This will
result in a considerable speed increase when browsing message areas, but it
has the drawback that the tosser will not be able to toss to an message area
as long as it is open in MsgEd TE. Also, some other problems have been
observed with this switch in network environments. So you'd best leave this
switch off unless you are running your Fido system on a non-networked, single
tasking DOS machine.
Note that this switch has nothing to do with data integrity concerns. MsgEd will of course lock the Squish Message Base when writing a message in order to insure data integrity even if the SquishLock switch is turned off.
The default value of the SquishLock switch is Off (in contrast to the
mainstream MsgEd 4.30, where it is turned on by default).
StatBarTearlinesTZUTCTZUTC switch to
off. Default: On.
UseLastrUseMouseUsePIDUseTosserGroupsAreafile or not. If turned on, and if the areafile
contains group information that can be read by MsgEd TE (currently this
is the case for Fastecho and Fidoconfig type area files), then each group
defined in your areafile (tosser configuration) will become a MsgEd TE
group, and all areas that according to the tosser configuration are member of
this group will also be members of this group in
MsgEd TE. See Configuring and Using Message Area Groups. Default: On.
XXLTearlineIf you use MsgEd TE with the same configuration file on different operating systems, you will probably want to make some settings in the configuration file dependent on the environment you are currently running in. This is where Conditionals come into place. A Conditional can be used to include a certain part of the configuration file only if a certain version (OS/2, DOS, ...) of MsgEd TE is running, or only if an environment variable has a certain value.
The easiest form of a Conditional is as follows:
IF condition
configuration statements ...
ENDIF
The condition parameter can simply be an operating system name like ‘OS/2’ or ‘Linux’. You will soon see other conditions that can be formulated (see Conditions that can be tested). For the moment, we will always use operating system names as conditions.
For example, the following statement will only be evaluated on OS/2:
IF OS2
Editor c:\boxer\b2.exe
ENDIF
In addition, you can specify that an alternate block of statements should be evaluated if the condition was not true:
IF OS2
;OS/2 version of the Boxer Editor
Editor c:\boxer\b2.exe
ELSE
;DOS version of the Boxer Editor
Editor c:\boxer\b.exe
ENDIF
If you want to test for multiple configurations, the ELSEIF statement is handy. Instead of writing a complicated statement like
IF OS2
Editor c:\boxer\b2.exe
ELSE
IF UNIX
Editor /usr/bin/vi
ELSE
;Must be DOS
EDITOR c:\boxer\b.exe
ENDIF
ENDIF
you can simply write:
IF OS2
Editor c:\boxer\b2.exe
ELSEIF UNIX
Editor /usr/bin/vi
ELSE
Editor c:\boxer\b.exe
ENDIF
For compatibility with other Fidonet editors, the ELIF command can be
used instead of the ELSEIF command.
As you might already have guessed from the examples, conditionals can be
nested down to any depth, that is, inside an IF - ENDIF -
block, you can start another IF block, and so on.
We already saw that operating system names can be used as conditions for the
IF command. Below, you see the complete list of conditions that can be
used:
IF OS2IF OS/2IF DOSIF DOS16IF 386IF W32IF UNIXIF LINUXIF 0IF 0 and ENDIF
around such a part of the configuration file.
IF 1IF variable=valueIF HOSTNAME=mycomputer
will be true only if you have set HOSTNAME=mycomputer in your
config.sys file, or if you have given the set
HOSTNAME=mycomputer command on the command line before starting
MsgEd TE.
Here are some more useful examples for Conditionals in the configuration file:
IF DOS16
Swappath c:\temp\msged.swp
ENDIF
IF OS2
Origin "Warp 4, Mister Sulu!"
ELSEIF W32
Origin "My employer forces me to use Windows ..."
ELSEIF DOS
Origin "DOSwidanja!"
ELSEIF UNIX
IF LINUX
Origin "Penguins ahead!"
ELSE
Origin "UNIX - a professional's choice"
ENDIF
ENDIF
IF UNIX
;By default, switch colors off (might cause problems with
;VT100 and xterm), as well as shadows (too slow)
Switch Shadows Off
Switch Colors Off
IF TERM=linux
;The peculiarities of the Linux console ...
switch bs127 on
switch colors on
ENDIF
IF TERM=vt220
switch colors on
ENDIF
IF TERM=ansi
switch colors on
ENDIF
ENDIF
One of the most important tasks in configuring MsgEd TE is to tell it
where it can find the message areas that you wish to read and to write
to. There are basically two ways to do this: You can either manually define
each area in the configuration file using the Quick, Fido and
Squish keyword, or you can tell MsgEd TE to read in the
configuration file of your tosser. The latter method saves you much work, but
sometimes you will ned to use the manual method to do some fine-tuning.
It is advisable to put all keywords that have to do with area configuration
at the end of your configuration file, because other keywords (like
QuickBbsPath, MountDir, et. al.) that change the behaviour of
the area definition keywords will only work if they are read in before the
area definition keywords.
You can manually define a message area by putting a line of the following format into your configuration file:
format flags "description" path areatag [address]
Except for the address parameter, all parameters are mandatory. The meaning of these parameters is as follows:
m- netmail area,e- echomail area,l- local mail area.
8- allow 8 bit characters with the proper@CHRSkludge,u- enable internet gateway support for this area,n- this flag is obsolete.
p- private,h- hold,k- kill/sent,d- direct.
Here are some examples:
Fido mup "Fidonet Netmail" e:\fido\netmail 2:2476/418.0
Squish eu "MsgEd Support" e:\fido\sq\msged MSGED_ECHO
Squish eu8 "OS/2 Debate" e:\fido\sq\os2deb OS2.DEBATE.GER
Squish eu "c't conference" e:\fido\sq\ctger CT.GER 21:492/2851.0
Quick lp "To Sysop Area" 1
MsgEd TE can read your area configuration from a tosser configuration file. Supported tossers currently include:
This saves you much work: You only have to declare an area once in the tosser configuration file, and MsgEd will automatically always display all areas that are configured in your tosser configuration file.
The following three keywords are used to perform this goal:
AreaDesc [how] what ...
AreaDesc tag
AreaDesc tag desc
AreaDesc upper tag asis desc
The tosser configuration file normally stores two sorts if information about
a message area: its canonical area tag, like MSGED_ECHO, and a
description of the area topic, like International Msged support
conference. The AreaDesc keyword is used to tell MsgEd TE how to
make up the arealist entry of each area from this information.
The what parameter specifies what to include. TAG means to use
the areatag, and DESC means to use the description. You can specify
both parameters separated by a blank like in the example above, in which case
both information will be displayed, separated by a dash.
The how parameter is a modifier for all following what parameters
and specifies how this information should be displayed. It can be
ASIS, which means to display it as in the config file, or it can be
UPPER, which means to display anything in upper case, or LOWER,
i.E. display everything in lower case letters.
The default value if no AreaDesc keyword is given is asis tag desc.
AreafileFlags flags
AreafileFlags 8u
There is one big problem with reading echo definitions from tosser
configuration files: Those files do not contain all information that can be
specified in a manual area configuration. Certain features of MsgEd TE
need a flag that has to be set for each area in order to enable that feature.
For example, in order to be able to write mails with umlauts, cyrillic
characters etc., you must set the 8 flag for each area, designating that
high ASCII characters are allowable therin. This is where you use the
AreafileFlags keyword.
The flags parameter has the same syntax as the flags parameter of
the Fido, Quick and Squish keywords (see Manual Area Definition).
You must specify the AreaFileFlags keyword before the
AreaFile keyword which it should apply to. Then, all areas imported
from the area files will have the specified flags.
If you want only a few, but not all areas form an areafile to have some
flags, you can manually redefine areas with the syntax described in the
preceding section. For this to work, the manual redefinition must come
after the AreaFile keyword. Vice versa, if you want almost all
areas from an areafile to have a certain flag, but want a few exemptions, you
should use the AreaFileFlags and AreaFile keywords to import
all areas from the areafile with the specific flag set. After that, you can
redefine some areas manually without this flag.
Note: Using AreaFileFlags to globally turn on the ‘u’ flag
probably won't hurt you. On the other hand, you should only use
AreaFileFlags to globally turn on the ‘8’ flag if you know that
the moderators of the echo areas that you are posting in do not forbid
8-bit-codes.
Areafile type filename
Areafile Fastecho c:\fastecho\fastecho.cfg
Areafile Squish c:\squish\squish.cfg
Areafile AreasBBS c:\squish\areas.bbs
Areafile GEcho c:\gecho
Areafile Fidoconfig
This keyword tells MsgEd TE which areafile to use. The type parameter designates the type of tosser configuration file to use. It can be ‘Squish’, ‘Fastecho’, ‘GEcho’, ‘fidoconfig’ or ‘AreasBBS’. The filename parameter specifies werhe to find the tosser configuration that should be read. It's useage depends on the type of your tosser:
The path to and filename of the configuration file, like
c:\fastecho\fastecho.cfg.
You must specify the path to your GEcho installation directory rather than a
configuration file name, e.g. c:\gecho. Only GEcho 1.20 is supported.
According to the Husky policy of doing things, the path to the fidoconfig file is read from the default value or from the ‘FIDOCONFIG’ environment variable. Hence, for fidoconfig, the second parameter of this keyword is not used to configure the path to the config file. Instead, it is used to configure how the config file should be treated. This can be:
Only the mail area configuration (echo-, local and netmail areas) is read from fidoconfig, i.E. the fidoconfig file is only used like any other areafile. This is also the default behaviour if you omit the second parameter.
If you specify ‘Areafile Fidoconfig Settings’, MsgEd TE will read as much configuration settings from the fidoconfig file as possible. Among other things, this is the user name(s), the Fido AKA(s) and the echotoss log file position. Mail area configuration, on the other hand, is not read.
With this setting, both the general configuration settings and the mail area configuration will be read from fidoconfig.
The fidoconfig routines are able to follow include statements inside the fidoconfig file automatically.
The path to and name of the configuration file, like in
c:\squish\squish.cfg. Plase note that only the area definitions from
this file itself will be read. If the Squish configuration file references
another areas.bbs file, you have to define it separately for
MsgEd TE using a second Areafile statement.
This appendix provides information on how to compile the source code of MsgEd TE. Most of the information of this chapter applies to all supported platfroms (including Unix, OS/2, Windows and DOS).
This appendix only covers stand-alone compilation of MsgEd TE. You can also decide to build MsgEd TE in the Husky environment, i.E. link MsgEd TE against the fidoconfig library and use the huskymak.cfg compile configuration file. If you want to do this, please refer to the compliation and installation instructions which are provided by the Husky team. They can be found in the file INSTALL in the huskybse package.
In the following we are assuming you don't want to deal with huskymak.cfg, don't want to download fidoconfig etc., but simply build a standard MsgEd TE executable for your operating system. It will still be able to read a fidoconfig type configuration file, as MsgEd TE also has it's own fidoconfig access routines.
Besides the source code of MsgEd TE, which is supplied in msged-te-6.3.tar.gz or in MSGTE63S.ZIP, you need the source code of the special edition of the Squish Message API, from here on called Smapi, that is required to build MsgEd TE.
Unfortunately, there are a lot of different versions of the Smapi floating around. The best choice would be if you would use the same version of Smapi that I used to compile the binary releases. for MsgEd TE 6.3, this is Smapi 1.6.3, which can be obtained as smapi-2.5.tar.gz or as smapi25.zip. You should be able to obtain these files from the same location you got MsgEd TE from.
Alternatively, you can use any newer Smapi from the Husky development stream. All other versions of the Smapi or the Msgapi32 are probably not suited for building MsgEd TE. They are definitely not suited if you want to compile for Unix.
After you have obtained SMAPI163.ZIP and MSGTE6_S.ZIP, unzip them into two directories at the same level. The files in the archives stick to the 8.3 notation, so you can even do this on FAT drives. You should use either Info-ZIP for unpacking these files, or use pkunzip with the ‘-d’ option, because the MsgEd TE archives contains subdirectories.
On OS/2, this could look as follows:
[C:\] mkdir compile
[C:\] mkdir compile\smapi
[C:\] mkdir compile\msged
[C:\] cd compile\msged
[C:\COMPILE\MSGED] unzip c:\download\msgte63s.zip
[C:\COMPILE\MSGED] cd ..\smapi
[C:\COMPILE\SMAPI] unzip c:\download\smapi25s.zip
If you use the version in .tar.gz format, you don't need to make the subdirectories - the .tar.gz files already contain them. So, on Unix, it would probably look like this:
~ $ mkdir ~/compile
~ $ cd ~/compile
~/compile $ tar xzf ~/downloads/msged-te-63.tar.gz
~/compile $ tar xzf ~/downloads/smapi-2.5.tar.gz
MsgEd TE does not provide a configure skript. It rather provides
a set of different makefiles. You “configure” the source code by selecting
the makefile of your choice.
The following compilers and target operating systems are supported:
Makefile | Platform
-------------+-----------------------------------------
makefile.bcd | DOS with Borland C++ 3.1 or Turbo C
makefile.bco | OS/2 with Borland C 2.0
makefile.bcw | Windows 95/NT with Borland C++ 4.0
makefile.djg | DOS/386 with DJGPP GCC 2.7.2
makefile.emo | OS/2 with EMX 0.9c GCC 2.7.2
makefile.ibo | OS/2 with IBM CSET/2 or Visual Age C++
makefile.rxw | 95/NT with RSXNT + EMX GCC 2.7.2
makefile.unx | Any UNIX, BSD or Linux with any compiler
makefile.bsd | FreeBSD with GCC
makefile.lnx | Linux with GCC
makefile.mgw | 95/NT via Mingw32 cpd (running on Unix)
The following makefiles are also provided, but they are not supported, either because I do not have the appropriate compilers or because I cannot give support for some special features they are using. I try to update these makefiles along with the others, but I cannot make any promises.
Makefile | Platform
-------------+----------------------------------------------
makefile.hco | OS/2 with Metware High C
makefile.qcd | DOS with MS Quick C
makefile.wcd | DOS with Watcom C
makefile.wcw | NT with Watcom C
makefile.wco | OS/2 with Watcom C
makefile.wcx | DOS/386 with Watcom C
There is also a file which is simply named Makefile. This file is for building using a huskymak.cfg environment, and will not be described in this manual.
Msged has to know where to find its primary configuration file and the character set translation files. You must tell this at compile time (the location of all other configuration files can then be configured in the primary configuration file). The following paths are selected per default:
What file DOS/WIN/OS2 UNIX
=========================================================
Configuration file msged.cfg ~/.msged
Charset Input Map readmaps.dat ~/.msged.readmaps
Charset Output Map writmaps.dat ~/.msged.writmaps
These path's will be different if you compile via huskymak.cfg.
On Non-Unix systems, you normally do not need to change the default (which is finding everything in the current directoy). On Unix, you might want to change the locations if you are administrator and want to provide a system-wide default configuration (that can then include files in the user home directory if necessary). You can do this by redefining variables in the Makefile. Just have a look at the first three lines of makefile.unx to see how it works.
Now that you have done all necessary preparations, compilation is easy:
make -f
MAKEFILENAME (replace MAKEFILENAME with the name of the makefile that
you have selected in the previous step). This will generate a library, the
name of which depends on the makefile you used. For instance
libsmapiunx.a or smapiibo.lib.
make -f
MAKEFILENAME (again substituting the proper makefile name). This will
genereate the executable, whose name depends on the makefile you used. For
instance msgedp.exe or msged or msged.exe.
ranlib smapiunx.a. Then change back to the Msged directory and try
again.
After you have created the executables, you need to create some other files, namedly the compiled online help file, the character set translation files, and the manual.
To compile the help file, call the MsgEd TE executable with the ‘-hc <infile> <outfile>’ options. On OS/2:
[C:\COMPILE\MSGED] msgedp -hc msghelp.src msghelp.dat
and on Unix:
~/msged $ ./msged -hc msghelp.src msghelp.dat
In order for MsgEd TE to behave smoothly in environments where mails with special national characters are received and/or transmitted (i.E.: everywhere in Europe, both Western Europe and particularly in Russia), you must create readmaps.dat and writmaps.dat files that match your local character map settings. On Unix, this is easily done thanks to the shell expansion feature:
~/msged $ cd ~/msged/maps
~/msged/maps $ gcc -o makemaps makemaps.c
~/msged/maps $ ./makemaps LATIN-1 *.CHS *.chs
(If you have misconfigured your Unix to use CP850 or CP437 instead of ISO-9660, you should enter ‘IBMPC’ instead of ‘LATIN-1’ in the example above).
On OS/2, DOS and NT it is a little more cumbersome. First, you have to compile the makemaps.c file with your C compiler. Then, you have to specify all character map files that are to be included into readmaps.dat and writmaps.dat manually:
[C:\COMPILE\MSGED] cd c:\compile\msged\maps
[C:\COMPILE\MSGED\MAPS] icc makemaps.c
(...)
[C:\COMPILE\MSGED\MAPS] makemaps CP437 IBM_ISO.CHS ISO_IBM.CHS
IBM_ASC.CHS IBM_MAC.CHS MAC_IBM.CHS IBM_850.CHS 850_IBM.CHS 866_IBM.CHS 1125_IBM.CHS
Finally, you may want to create the documentation in your favourite output format. This requires quite some prerequisite software to be installed on your system, so you probably might simply want to grab MSGTE6_M.ZIP.
But if you really want to compile the manual by hand, proceed as follows: Change to the doc/manual subdirectory:
[C:\COMPILE\MSGED\MAPS] cd \compile\msged\doc\manual
or on Unix:
~/msged/maps $ cd ~/msged/doc/manual
There, you have various options. You can type:
make infomake htmlmake dvimake infYou have now created all files that are necessary to install MsgEd TE. See Installation Procedures and Release Notes, for information on how to install these files.
AdaptiveCase: List of SwitchesAddress: AddressAlias: AliasAlterfunc: AlterfuncAreaDesc: AreadescAreaExcl: AreaExclAreafile: AreafileAreafileFlags: AreafileFlagsArealistExactMatch: List of SwitchesAssumeCharset: AssumeCharsetBS127: List of SwitchesCarthy: List of SwitchesCharsetAlias: CharsetAliasChopQuote: List of SwitchesColor: ColorColors: List of SwitchesColour: ColourConfirm: List of SwitchesCurEnd: CurStart/CurEndCurStart: CurStart/CurEndDateArvd: List of SwitchesDirectList: List of SwitchesDMore: List of SwitchesDomain: DomainDomainMsgid: List of SwitchesDomainOrigin: List of SwitchesEchoFlags: List of SwitchesEditCROnly: List of SwitchesEditKey: EditKeyEditor: EditorEnableSC: EnableSCExtFormat: List of SwitchesFido: Manual Area DefinitionFreqArea: FreqAreaFreqFlags: FreqFlagsFunction: FunctionGate: GateGroup: GroupGroup: Manual GroupsGroupSeparators: List of SwitchesGroupSettings: GroupSettingsHardQuote: List of SwitchesHelpFile: HelpFileImportFN: List of SwitchesInclude: IncludeJam: Manual Area DefinitionLastread: LastreadLowerCase: List of SwitchesMaxX: MaxX and MaxYMaxY: MaxX and MaxYMountDir: MountDirMSGIDs: List of SwitchesName: NameNetmailVia: List of SwitchesNodelist: NodelistNodePath: NodePathOpusDate: List of SwitchesOrigin: OriginOrigins: List of SwitchesOutfile: OutfileOutputCharset: OutputCharsetPrinter: PrinterPrivateNet: PrivateNetPseudoGraphics: List of SwitchesQQuotes: List of SwitchesQuick: Manual Area DefinitionQuickBBS: QuickBBSQuote: QuoteQuoteRight: QuoteRightRawCC: List of SwitchesReadKey: ReadKeyReadmap: ReadmapRealMsgN: List of SwitchesReceiveAllAddresses: List of SwitchesReceiveAllNames: List of SwitchesRight: RightRightNextUnreadArea: List of SwitchesRobotName: RobotNameSaveCC: List of SwitchesScan: ScanSeen-Bys: List of SwitchesShadows: List of SwitchesShowAddr: List of SwitchesShowCR: List of SwitchesShowEOL: List of SwitchesShowNotes: List of SwitchesShowOrigins: List of SwitchesShowSeenBys: List of SwitchesShowSystem: List of SwitchesShowTearlines: List of SwitchesShowTime: List of SwitchesSoftCrXlat: SoftCrXlatSortAreas: SortAreasSOTEOT: List of SwitchesSquish: Manual Area DefinitionSquishLock: List of SwitchesStatBar: List of SwitchesSwapPath: SwapPathSwitch: SwitchesTabsize: TabsizeTearlines: List of SwitchesTemplate: TemplateTossLog: TossLogTZUTC: List of SwitchesUseLastr: List of SwitchesUSeMouse: List of SwitchesUsePID: List of SwitchesUserList: UserListUserOffset: UserOffsetUseTosserGroups: List of SwitchesUUCP: UUCPUucpName: UucpNameUucpReplyTo: UucpReplyToWritemap: ReadmapXXLTearline: List of Switches