GEMini Atari

home *** CD-ROM | disk | FTP | other *** search

/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / bbs / fn132bin / fdman / chapter.03 < prev next >

Wrap

Text File | 1991-09-03 | 115KB | 2,364 lines

Chapter 3: User Command Reference 24 3 User Command Reference This chapter documents in gory detail the basic single-key and multi-key extended commands that all users have access to. Most of this information is present in a more terse format in the online menus and help files, which you should encourage your users to read often in order to make the best use of Fnordadel's capabilities. Don't be surprised, however, when they ignore all the documentation available to them in favor of doing things inefficiently or complaining that they can't figure out how things work. Users are like that. The chapter will deal will single-key commands first, then multi-key, and finish with miscellaneous functions. 3.1 Single-key User Commands The Fnordadel single-key commands will allow you and your users to carry out the majority of your activities on the system. They do the things people most often wish done, and have therefore been streamlined so they don't get in the way. This has the side effect of making them inflexible, but flexibility is what the multi-key commands (coming up soon) are for. 3.1.1 Room prompt commands Users hitting the `?' key at a room prompt will see something like the following list of commands: MESSAGES: [E]nter message [F]orward read [N]ew messages [O]ld messages [R]everse read [=]read headers of new messages [#]message number NAVIGATION: [B]ackup from this room [G]oto next room with new messages [K]nown rooms list [M]ail room direct [S]kip room [U]ngoto from this room [+]next room (new messages or not) [-]previous room (new messages or not) [>]next floor [<]previous floor OTHERS: [C]hat with Sysop [D]ownload file [H]elp Chapter 3: User Command Reference 25 [I]nformation on this room [L]ogin (Must do this!) [T]erminate (Goodbye) [U]pload file [Z] Forget this room [.] prefixes extended commands. [;] prefixes floor commands. [!] prefixes door commands. 3.1.1.1 Entering and reading messages You and (more importantly) your users will be spending a lot of time entering messages, and reading ones posted by other users. There is one basic way to enter messages, but several ways to read them, reflecting the differences between old and new messages in a room. [E]nter message This command is one that will be heavily used on your system, with any luck. When executed, it will take the user straight into message entry mode, unless the current room is the Mail> room. (In Mail>, the system will first ask for the name of a user to whom the message will be sent, privately.) If the right combination of user __net privileges__ and room status exists, the system will make the message __networked__, automatically. See Section 8.4 [Roomsharing], page 112. An opening help message will be displayed by the system just before going into the editor, unless the user has set __expert mode__ on (see Section 3.5 [User Configuration], page 56). This message can be altered, but we recommend keeping it a bit on the verbose side, since the Fnordadel editor is not like very many others out there. For full details on the message editor, see Section 3.4 [The Message Editor], page 52. [F]orward read This command is infrequently used. It will cause the system to display all messages in the current room, starting with the oldest and ending with the newest. Users will rarely be concerned with the ancient history that this command will dredge up, but it's there for the curious. Message display is automatically placed in `more' mode if the current room is Mail>, or the user has configured `more' mode to be used by default. See Section 3.6 [More Mode], page 59. [N]ew messages This command is the most frequently used, and will cause the system to display all new messages in the current room, in the order they were entered. If the user configuration flag ``show last old message on [N]ew'' is set, the last old message in the room (if any) will be displayed first, followed by the new messages in normal fashion. See Section 3.5 [User Configuration], page 56. Chapter 3: User Command Reference 26 Message display is automatically placed in `more' mode if the current room is Mail>, or the user has configured `more' mode to be used by default. See Section 3.6 [More Mode], page 59. [O]ld messages This command is the opposite of [N]ew, and allows for reading old messages in the room, in reverse order of entry. It is often used, since it will quickly show the discussion leading up to the room's newer messages. Message display is automatically placed in `more' mode if the current room is Mail>, or the user has configured `more' mode to be used by default. See Section 3.6 [More Mode], page 59. [R]everse read This command is like [O]ld, and is the opposite of [F]orward. It starts displaying messages with the newest one in the room, and works backwards from there. Message display is automatically placed in `more' mode if the current room is Mail>, or the user has configured `more' mode to be used by default. See Section 3.6 [More Mode], page 59. [=]headers of new messages This command allows users to quickly skim through the new messages in the current room, viewing only selected header information from each message (for example, ``91Aug19 7:38 am from: Mr. Neutron''). The Sysop and Co-Sysops will be shown somewhat more information than will regular users or Aides (e.g. ``176641 (176641) 91Aug31 3:19 pm: from Not Quite Cricket'', where the first two numbers are the local and original message ID numbers, respectively). In the Mail> room, the "from:" information will be replaced by "to:" information, for those messages entered by the user seeing the headers. Additional information will be shown on the console if citadel is started with the `+debug' option. Subject lines will also be shown for net messages originating on STadel systems that were sent over with subjects. This command never uses `more' mode to display headers. Also, it is not of much use in anonymous rooms, where there is no header information to speak of. [#]message number This command will probably be rarely used by anybody. What it does is allow a user to read a specific message in a room, by supplying its message ID number. Message ID numbers can be obtained by Co-Sysops using `=', described above, or `.R=', described in Section 3.2.2.1 [Multi-key message reading commands], page 39. Normal users can only get message ID numbers in anonymous rooms, where they are a normal part of each message header. Chapter 3: User Command Reference 27 3.1.1.2 Navigating between rooms In order to use all of those commands you learned about in the previous section, you will probably want a way to move about among the rooms on the system. Take it from us, the Lobby> room can get boring real fast. [B]ackup from this room This command is equivalent to the old [U]ngoto command, and allows the user to reverse the effects of the last few goto and/or skip commands. [B]ackup returns the user to the room he/she left prior to entering the current room. New messages in the room exited are not updated in any way; normal use of [G]oto or [S]kip will return the user to these rooms once more. All messages in each room re-entered via [B]ackup, which were new when the user last entered the room, are re-marked as new. [B]ackup can be used several times in succession. The system currently keeps track of the 16 most recently-visited rooms for use by [B]ackup/[U]ngoto. [G]oto next room with new messages This command will take a user to the next room on the system that has at least one new message in it, and mark all of the messages in the room being left as old. When there are no more new messages in any room accessible to the user, [G]oto returns to the Lobby> room and will continue to do so however many additional times it is executed. For non-experts, a message will be displayed stating that there are no more new messages. This command is the main one you and your users will employ to move around the system. You should make sure that you and they understand its use. For an example of improper commands to use for general movement, see [+] and [-], coming up. It is important that [G]oto (or its big brother .G(oto); see Section 3.2.3 [Multi-key navigation commands], page 47) be used so that messages read in rooms visited are marked by the system as being old for future visits to the room. If this is not done, users will see the same messages over and over again, which is a waste of their time and system time. [K]nown rooms list This command will display a list of all rooms known to the user executing it. For the Sysop, this list will be all existing rooms. For a user with Aide or Co-Sysop status, this list will contain most existing rooms, missing only invitation-only rooms to which the Aide has not been invited, and those rooms which the Aide or Co-Sysop has used [Z]forget to forget about. For normal users, this list will just contain regular public rooms, and the odd private rooms to which they may have been invited. The list is broken into two groups, the first of which is rooms containing new messages, and the second of which is rooms containing no new messages. Private rooms are marked with with an asterisk (`*'), and will never show up in the [K]nown list unless the user has access. Forgotten rooms will also never show up again unless Chapter 3: User Command Reference 28 the user unforgets them. See Section 3.1.1.3 [Other room prompt commands], page 29. Finally, if the user is in floor mode, only rooms on the current floor will be displayed. To see all rooms, use the ;K(nown floors) floor command (see Section 3.3 [Multi-key User Floor Commands], page 51), or the .K(nown) extended command (see Section 3.2.3 [Multi-key navigation commands], page 47). See Section 3.2.4 [Other multi-key commands], page 49, for the command to view forgotten rooms, .Z(list-forgotten). [M]ail room direct This command is a short-cut method of doing a .S(kip) mail command. It takes the user directly to the Mail> room, but does not mark any messages in the current room as ``old''. This allows the user to return to the room later and find it just as he/she left it before heading to Mail>. [S]kip room This command acts like [G]oto, taking the user to the next room with new messages (or the Lobby room if no new messages remain). The difference is that the messages in the room being departed are not marked by the system as being old, whether the user has read them or not. This command permits users to return to an interesting discussion later, even during another login hours or days ahead, and again read ``new'' messages to review what was said. Due to the way that Fnordadel keeps track of which messages in a room are new to a user and which aren't, users who persist in skipping through rooms, signing off, and coming back later, will find that Fnordadel slowly starts marking skipped messages as being old. As a general rule of thumb, messages that were entered after a user's previous call, but before the current call, can be skipped 8 times, after which they will become old. Makes perfect sense, right? [U]ngoto from this room This command reverses the action of the user's last room navigation command, such as [G]oto or [S]kip, or their multi-key extended siblings. See [B]ackup in this section for more details. This command will not be available if the Sysop started citadel with the command-line option `+backup'. In such cases, the [U]pload command replaces the [U]ngoto command. (In either case, [B]ackup is always available.) This difference causes some confusion, but was implemented because some people would rather have the old [U]ngoto than a quick way to upload files. You pick! [+]next room [-]previous room These commands send the user to the next or previous room on the system, *whether there are new messages in it or not*. If the user is operating in floor mode, these commands will not leave Chapter 3: User Command Reference 29 the current floor, but will loop from the last room on the floor back to the first one, or vice versa, as appropriate. These commands operate like [S]kip, in that they do not mark any messages as old in the room being left behind. For this reason, you may wish to delete these commands from the list of basic commands produced by hitting `?'. We have observed inexperienced users falling into the trap of using them for all their room navigation, rather than [G]oto. Thus they read the same messages again and again each time they call, wasting a lot of time. [>]next floor [<]previous floor These commands take the user to the first room of the next or previous floor on the system, if the user is in floor mode. If the user is on the last floor, [>]next will take him/her to the first floor; similarly, the [<]previous command from the first floor will wrap around to the last floor. No messages are flagged as old in the room left behind. See Section 2.3 [Floors], page 17, for a look at floors. 3.1.1.3 Other commands There remain several single-key commands that don't fit the above two command categories (message processing and room navigation). Don't forget about them, though, because several are essential to everybody's life, liberty and happiness. [C]hat with Sysop Users wanna talk with the Sysop? This is the command. Users calling for a chat will either be told that the Sysop is being paged, or if he or she has turned the chat option off (see [C]hat toggle in Section 5.1 [Sysop Special Functions], page 75), they will see a message the contents of which live in the `nochat.blb' file in the system's help file directory, #helpdir. If a user has Aide status, the chat flag can be over-ridden by a special Aide command. See Section 4.1.2 [The .A(ide) command], page 63. If the Sysop does not answer the chat call, a `*' flag is put on the status line to let him know somebody wanted a chat. See Section 13.4.6 [Status line], page 162. [D]ownload file This is a quickie synonym for the extended command .R(ead) <protocol> F(ile), which sends files to a user by his/her default transfer protocol (see Section 3.5 [User Configuration], page 56). Fnordadel will prompt for the names of the files to send. Note that this only works in directory rooms that permit user downloads, of course. See Section 3.2.2.2 [Multi-key file reading commands], page 43, and Chapter 12 [File Transfers], page 147. Chapter 3: User Command Reference 30 [H]elp Okay, so you've given up. You're tired of Fnordadel assuming you want to be treated like an adult, and instead want to be coddled in a mammoth maze of menu-driven madness! Well, this command won't quite do that, but it's close. When you hit `H', you'll get a brief listing of basic, single-key commands in a somewhat narrative format. This is simply a text file called `dohelp.hlp' in #helpdir, and like any of the `.hlp', `.blb' or `.mnu' files in that directory, the Sysop may modify it to suit his or her tastes using any text editor capable of saving ASCII text. Note that you may branch out to other help screens. At the bottom of the [H]elp list, you are told that you can either hit a carriage-return (which will take you back to the room prompt) or type one of several letters to take you to other, more detailed help screens. Most of the other screens work in the same fashion. Note also that any help file may be [P]aused just like any other text being output from the system. Finally, we realise that you, as Sysop, have a mind like a steel trap and won't ever need any of this help stuff. When we say ``you'' above, we of course mean other users. [I]nformation on this room This command allows users to view an optional information file, which (presumably) tells them something about the current room, followed by the total and new numbers of messages in the room. The info file is formatted exactly like a normal message, and has as its header the file's date and time of last modification, and the user name of the modifier. See Section 4.1.2 [The .A(ide) command], page 63, for the Aide commands that deal with room information files. Room information is optional for each room. There is one information file per room, and they all live in #roomdir with the room data files. Aides and Co-Sysops will also be shown some extra information about the room, duplicating the details that the [V]iew command displays during room editing. [L]ogin This command is how all users get onto the system in the first place. Depending on the setting of the #getname parameter in `ctdlcnfg.sys', when [L]ogin is executed the system will either prompt for a password or for both a user name and a password. This second possibility is popularly known as ``paranoid mode'' and is used by Sysops who wish to discourage people from attempting to guess passwords at random. It's much easier to guess a password which could get you into any user's account than it is to guess a password of a particular user's account. [T]erminate This command logs users off the system properly. As with many commands, it will ask for confirmation. There are, of course, many ways for a user to leave the system improperly. For a look at them, see Section 13.2.1 [The call-log], page 152. Chapter 3: User Command Reference 31 [U]pload file This is a quickie synonym for the extended command .E(nter) <protocol> F(ile), which lets a user upload a file by his/her default transfer protocol (see Section 3.5 [User Configuration], page 56). Fnordadel will prompt for the name of the file and a short description. Naturally this only works in directory rooms that permit user uploads. See Section 3.2.1.2 [Multi-key file entry commands], page 36, and Chapter 12 [File Transfers], page 147, for more information. If the user executing the command is not an expert, the system will prompt for a file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. This command will only be available if you started citadel with the command-line option `+backup'. If you didn't, the [U]ngoto command replaces [U]pload. (In either case, [B]ackup is always available.) This difference causes some confusion, but was implemented because some people would rather have [U]ngoto than a quick way to upload files. You be the judge. [Z]Forget this room If users find that the conversation in a particular room fills them with ennui, they can __forget__ the room simply by using this command at the room's main prompt. The room will no longer show up in their list of known rooms, and they will no longer be taken to it by any single-key navigation command, for example [G]oto. In this manner, users may tailor the sometimes vast numbers of different discussions on a Fnordadel down to a smaller number that actually interest them. In order to remember, or __unforget__, this room later on, if this is ever desired, users can execute the multi-key command .G(oto) roomname, discussed in Section 3.2.3 [Multi-key navigation commands], page 47, where roomname is the full and complete name of the room to which they wish restored access. This works fine for both normal public rooms and hidden rooms, but if a user forgets an invitation-only private room, this method will not regain access to that room. See Section 2.2 [Rooms], page 15. Note: The Sysop can not forget rooms. [.] prefixes multi-key commands [;] prefixes floor commands We'll get to these in the next main sections, Section 3.2 [Multi-key User Commands], page 32, and Section 3.3 [Multi-key User Floor Commands], page 51. [!] prefixes door commands See Chapter 9 [Doors], page 126, for the complete scoop. Chapter 3: User Command Reference 32 3.1.2 Pseudo commands There are four single-key pseudo-commands that users will see and use all the time. They control output from Fnordadel whenever something is being displayed. The commands are: [J]ump This control command causes the system to jump to the start of the next paragraph in whatever is being displayed. This is a good way to skip ahead through long-winded messages to find a part later in the text. [P]ause This control command is used all the time. It pauses output, and waits of the user to press another key to restart things. Certain keys pressed while output is paused allow for message deletion, movement, or journalling. See Section 3.7 [Deleting Messages], page 60, Section 4.1.4 [Aide message deletion and movement], page 68, and Section 4.2.2 [Message journalling], page 72. The `^S' (Control-S) key will do the same thing as [P]ause. [N]ext This command will cause the system to abort the display of the current item and start the next one. The only situation in which this command makes sense is while reading messages in a room. The `^O' (Control-O) key will do the same thing as [N]ext. [S]top This command will halt output from the system and return the user to a command prompt. In some cases when Fnordadel is displaying important information, the [S]top command will be ignored to ensure the user sees what is being sent. 3.2 Multi-key User Commands The multi-key commands seem endless, but there really is a finite number of them. It's the options that are endless. Before explaining in more detail, the best piece of general advice is ``don't be afraid to experiment with these commands''. You can't hurt Fnordadel much, and you'll be getting hands-on training to boot. Besides, you should be making backups anyway. Multi-key commands start with a mode character. For normal extended commands, the character to use is `.'. Executing the `.?' command will produce a list of multi-key commands something like the following: .B(ackup) roomname .E(nter) ? .E(nter) M(essage) .E(nter) N(et-message) .E(nter) L(ocal-message) Chapter 3: User Command Reference 33 .E(nter) [XYWV] [MNL] X(modem) Y(modem) W(xmodem) V(anilla) .E(nter) H(eld-message) .E(nter) F(ile) file.ext .E(nter) [XYWV] F(ile) file.ext X(modem) Y(modem) W(xmodem) V(anilla) .E(nter) C(onfiguration) .E(nter) O(ption) configoption .E(nter) P(assword) .E(nter) R(oom) .G(oto) ? .G(oto) roomname .H(elp) ? .H(elp) topic .K(nown) ? .K(nown) [DHNP] <CR> .K(nown) [DHNP] R(ooms) roomname D(irectory rooms) H(idden rooms) N(etwork rooms) P(ublic rooms) .R(ead) ? .R(ead) A(ll) .R(ead) G(lobal) .R(ead) N(ew) .R(ead) O(ld) .R(ead) R(everse) .R(ead) [MUL+-~=XYWVC] [AGNOR] M(ore) U(ser) username L(ocal) + (After) date - (Before) date ~(not) =(headers) X(modem) Y(modem) W(xmodem) V(anilla) C(apture) Chapter 3: User Command Reference 34 .R(ead) D(irectory) *.doc .R(ead) E(xtended directory) *.foo .R(ead) [M+-XYWVC] [DE] files.ext M(ore) + (After) date - (Before) date X(modem) Y(modem) W(xmodem) V(anilla) C(apture) .R(ead) F(ile) foobar.txt .R(ead) [+-XYWVCT] [FB] files.ext + (After) date - (Before) date X(modem) Y(modem) W(xmodem) V(anilla) C(apture) T(ext) .R(ead) H(eader) foo.arc .R(ead) I(nvited) .R(ead) S(tatus) .R(ead) # (message number) .S(kip) ? .S(kip) roomname .T(erminate) ? .T(erminate) S(tay) .T(erminate) Q(uit-also) .T(erminate) P(unt) .T(erminate) Y(es) .U(ngoto) roomname or .U(pload) file.ext .Z (list forgotten) The above list of commands will now be dealt with in similar logical groupings as used in the single-key commands section. (Due to their respective size, we will split the `enter' and `read' commands into their own sections.) Note: There are some additional extended commands that are documented in later chapters, as they are not accessible by normal users. Also, there are some extended commands that are not documented at all, for a variety of reasons other than because we forgot. In the case of these latter commands, they are usually identical to existing single-key commands, and Chapter 3: User Command Reference 35 we don't wish to give people an excuse to be less efficient than they should be. Also, such commands might be removed at any time, as the whim takes us, so don't build your life around them. 3.2.1 Enter commands Just as with single-key commands, there are extended commands for entering information to the system. However, much greater flexibility is possible with the extended .E(nter) command. One reason is that it can be used to enter a variety of things, including messages, files, user configuration settings, and more. Another reason is that many of these things can be entered either interactively or via a transfer protocol. 3.2.1.1 Entering messages There are several ways to enter messages, based on the type of message to be entered and how it is to be entered. .E(nter) M(essage) This is the basic multi-key message entry command. See Section 3.4 [The Message Editor], page 52, for details on the message editor. The command allows normal entry of a message in a room. It is identical to the single-key [E]nter command. The system may make the message a networked message, if the right combination of user net privileges and room status exists; otherwise, the message will be non-networked. .E(nter) N(et-message) This form of the command allows a user to attempt to explicitly enter a __networked__ message. There are several reasons why the system may not permit this. Firstly, the current room might not be a shared room. Network messages can't be used in non-networked rooms. (Note that Mail> is considered to be a networked room even though the Sysop can't explicitly share it with any other nodes.) Secondly, the user may not have the requisite privileges in a given room to enter a networked message. In normal shared rooms, the user must have been given network privileges by the Sysop; see Section 5.2 [User Status Commands], page 80. (This can be done automatically using the #allnet parameter in `ctdlcnfg.sys'; see `ctdlcnfg.doc' for details.) Finally, in the Mail> room, the user must have enough long-distance credits (supplied by the Sysop, of course) if the destination system is designated long-distance by the Sysop. Normally, l-d credits are not used; however, to control l-d mail traffic the Sysop may define l-d net costs in `ctdlcnfg.sys' (see `ctdlcnfg.doc', parameters #ld-cost and #hub-cost), and assign credits to users (see Section 5.2 [User Status Commands], page 80). Chapter 3: User Command Reference 36 .E(nter) L(ocal-message) The .E(nter) L(ocal-message) command allows a user to force a message to be __local__, i.e. non-networked, in rooms that the Sysop has set up to automatically ``nettify'' all messages entered. Such auto-net rooms are convenient, but now and then users may wish to post comments that should not be sent across the net. This is especially true of users who have Aide, Co-Sysop or Sysop status, since Fnordadel treats all networked rooms as if they were auto-netted, for these classes of users. .E(nter) [XYWV] [MNL] This class of commands gives users the ability to compose their messages on their own systems using any editor or word processor that can save text to an ASCII file, and then upload the results to Fnordadel as a message. When Fnordadel has received the entire transmission, it places the user into the message editor to allow for any needed touch-up work. The individual command types (M(essage), N(et-message) and L(ocal-message)) are subject to the same restrictions described in Section 3.2.1.1 [Multi-key message entry commands], page 35. Here are the currently available transfer protocols: X(modem) Y(modem) W(xmodem) V(anilla) The first two protocols will be used almost exclu- sively. For details about the various protocols, see Section 12.2 [File Transfer Protocols], page 147. Note that Wxmodem may not be available, since we may have disabled the code we inherited due to problems we haven't had inclination to fix. .E(nter) H(eld-message) This command allows a user to continue editing a message that was previously saved in the held buffer by the [H]old command in the message editor (see Section 3.4 [The Message Editor], page 52). A message held in one room may be continued in another, reheld and restarted later, and so on. The Sysop can set the `ctdlcnfg.sys' #keephold parameter to make Fnordadel preserve users' held messages between login sessions. If this is done, held messages are stored in files in the directory #holddir specified in `ctdlcnfg.sys'. A user may have only one held message at a time. Users may also continue held messages from the `more' prompt (see Section 3.6 [More Mode], page 59). 3.2.1.2 Entering files There are fewer .E(nter) commands related to files than messages, mainly because the system does not distinguish between different types of files. A file is a file is a file. Chapter 3: User Command Reference 37 .E(nter) F(ile) file.ext This is the basic file uploading command, and allows users to transfer any sort of file to your system, providing that they have access to a directory room that permits user uploads. The transfer protocol used defaults to the user's defined default protocol (see Section 3.5 [User Configuration], page 56 for the command to set the default). The system will prompt for the name of the file to upload, and a short description. See Chapter 12 [File Transfers], page 147, for more. As usual, if the user executing the command is not an expert, the system will prompt for a file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. .E(nter) [XYWV] F(ile) file.ext This modification of the above command allows the user to specify a file transfer protocol to use in uploading a file. As always, if the user executing the command is not an expert, the system will prompt for a file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. Here are the supported protocols: X(modem) Y(modem) W(xmodem) V(anilla) The first two protocols will be used almost exclu- sively. For details about the various protocols, see Section 12.2 [File Transfer Protocols], page 147. For other details on file transfers, see Chapter 12 [File Transfers], page 147. Note that Wxmodem may not be available, since we may have disabled the code we inherited due to problems we haven't had inclination to fix. 3.2.1.3 Entering other information There are several .E(nter) commands that have nothing to do with messages or files. However, they involve sending information to the system, so the Citadel Gods decreed that they be .E(nter) commands. .E(nter) ? This command simply displays one of Fnordadel's many help files, which contains a brief list of the many .E(nter) options. .E(nter) C(onfiguration) This command calls up a menu that allows a user to change the configuration data that he/she supplied when first logging onto the system. All user options may be altered in this menu except for name and password. Note that some of the options in this menu are not settable by the user when he/she first logs in, if the ``Are you an expert?'' question is answered with `no'. In such cases, some of the more esoteric options are given default Chapter 3: User Command Reference 38 values by the system, and then left well enough alone until the user stumbles across them in `.EC'. See Section 3.5 [User Configuration], page 56. .E(nter) O(ption) configoption This command is a short-cut way for a user to change one of his/her configuration options. It avoids going through the menu in the .E(nter) C(onfiguration) command. The configoption option can be any command available in the `.EC' menu, and will produce the same prompt and take the same answers. .E(nter) P(assword) This command allows a user to change his/her password. We recommend that all users periodically change their passwords to guard against so-called ``hackers''. .E(nter) R(oom) This command allows a user to create a new room on the system. A parameter in `ctdlcnfg.sys' (see #all-room in `ctdlcnfg.doc') permits the Sysop to allow this command to be used either by all users, or only by users with Aide or Co-Sysop status. If a normal user executes this command, he/she will be able to create only normal rooms and hidden rooms. Invitation-only status, directory status, and all other attributes can only be set by an Aide or Co-Sysop. Or the Sysop itself, of course. If there is no space for the new room (see the #maxrooms parameter in `ctdlcnfg.doc'), it will look for any temporary non-shared rooms that are currently empty. If one such room is found, Fnordadel will purge it to make way for the room being created. If no killable rooms are found, the system will display a message to the effect that no space is available, and abort the operation. This command also gives users a chance to create the initial room info file using the message editor. The contents of this file are shown to users when they use the [I]nfo command. See Section 3.1.1.3 [Other room prompt commands], page 29. The Sysop can define a `ctdlcnfg.sys' parameter called #infook, which controls whether all users or only Aides and Co-Sysops are allowed to create info files. Another parameter called #infomax controls the maximum size of info files. 3.2.2 Read commands As with the .E(nter) command detailed above, there is also a very flexible .R(ead) command. It permits users to read messages, download files, and display other kinds of information, with an even larger array of options than available with .E(nter). Chapter 3: User Command Reference 39 3.2.2.1 Reading messages Since Citadels were originally highly discussion-oriented, the oldest and most used .R(ead) commands deal with messages. A large collection of options allows users to read messages in strange and wonderful ways. .R(ead) A(ll) The .R(ead) A(ll) command is the same as the single-key [F]orward command, and demonstrates one of the few instances in which the single-key commands aren't consistent with the extended commands. `.RF' is for the .R(ead) F(ile) command, so `A' for A(ll) was used instead. Oh, by the way, this command displays all messages in the current room, starting with the oldest. .R(ead) G(lobal) The .R(ead) G(lobal) command does not have a single-key equivalent. This command will cause the system to display all new messages in all rooms on the system, returning the user to the Lobby> room when done. This command is not frequently used, but can be beneficial for the odd person who likes to peruse messages at great length. Using the message downloading capabilities of Fnordadel (described in Section 3.2.2.1 [Multi-key message reading commands], page 39, and in Chapter 12 [File Transfers], page 147), in conjunction with G(lobal) allows a user to quickly transfer all new messages to his/her own system, where they can be read at leisure without monopolizing the BBS. Of course, lurkers (users who always read but never post) can use the G(lobal) command, too, since it allows them to see everything with a minimum of key-strokes expended. We tend to discourage such activity whenever possible, on philosophical grounds. .R(ead) N(ew) The .R(ead) N(ew) command is the extended equivalent of the single-key [N]ew command, and displays all new messages in the room, from oldest to newest. .R(ead) O(ld) The .R(ead) O(ld) command does the same as the single-key [O]ld command, and displays only old, previously-read messages in reverse order, from newest to oldest. .R(ead) R(everse) The .R(ead) R(everse) command acts just like the single-key [R]everse command, and displays all messages in the room in reverse order, from newest to oldest. .R(ead) [MUL+-~=XYWVC] [AGNOR] The previous five basic message-oriented .R(ead) commands can be supplemented with various options to make life easier and/or more interesting. These options can frequently be used in conjunction with each other to produce compounded effects that Chapter 3: User Command Reference 40 literally boggle the imagination. Well, our imaginations, anyway. Here, then, are the currently available modifiers: M(ore) The M(ore) modifier is a relatively recent addition to Citadel, which historically has been anti-menu in philosophy. We guess it's true that one can have too much of a good thing, even if it's philosophy. What M(ore) does for users is cause Fnordadel to display messages in `more' mode. The system pauses after each message displayed by any of the reading commands, to permit the digestion of what was just read, and/or the entry of a few other commands, without breaking out of the message-reading sequence. Hitting `?' at the `more cmd:' prompt should produce a list that looks like this: [A]- this message again [B]ackup to previous message [D]elete this message [H]- continue held message [N]ext message (also <SPACE>, <CR>) [R]eply to this message e[X]it message reader (also [Q]uit, [S]top) For details on this option, see Section 3.6 [More Mode], page 59. U(ser) username This .R(ead) modifier allows for the reading of just those messages from a specific user. If in the Mail> room, messages both from and to the specified user will be shown. After all modifiers have been supplied and one of the message-reading commands (`[AGNOR]') is chosen, Fnordadel will ask for a user name. Entering a full or partial user name here will then limit message display as described. If the name given does not match the author (or recipient, in the case of the Mail> room) of any message, nothing will be displayed. This modifier may be inverted when used in conjunction with the `~' modifier; see Section 3.2.2 [Multi-key read commands], page 38. In such cases, it will show all messages *not* to or from the specified user. L(ocal) This option is usable only in a shared room (remember that Mail> is shared). It limits messages being displayed to those that were entered on this system, ignoring all messages that may have come in over the network from other systems. Chapter 3: User Command Reference 41 This modifier may be inverted when used in conjunction with the `~' modifier; see Section 3.2.2 [Multi-key read commands], page 38. In such cases, it will show all messages *not* originating on this system (i.e. all those that came in over the network). + (After) date This option, and the following one, allow the user to qualify the system's message display by giving date boundaries. With the + (After) option, the user may specify that messages must be after a given date, which will be prompted for after all other options are entered and a message-reading command (`[AGNOR]') is given. The format of the date is the same as all dates displayed by Fnordadel, `YYMMMDD', where `YY' is the year, `MMM' is the English abbreviation of the month, and `DD' is the day. Example: `90Oct05'. The year, `YY', may be ommitted, and the current year will be assumed. If the entire date is omitted (i.e., the user just hits `<CR>' in response to the prompt), the system will use the date and time of last call. + (After) and - (Before) can be used together. See the next section for details. - (Before) date This option is the reverse of the above option, and specifies that all messages be prior to a given date. The year can be omitted, to indicate the current year should be used. If the entire date is omitted (i.e., the user just hits `<CR>' in response to the prompt), the system will use the date and time of last call. + (After) and - (Before) can be used together, if desired, to specify a range of dates. The range is inclusive. So, for example, entering `.R+-A' and answering `91Jan10' for the ``after'' date and `91Jan15' for the ``before'' date, would net you all messages entered on or after 91Jan10, and on or before 91Jan15. The system does no checking to ensure that the two dates form a sensible range. Thus, if you reversed the two dates in the above example, the system would search long and hard and find nothing. ~(not) This modifier works on certain other modifiers and commands, and allows the user to negate or invert the normal meaning of the resulting command. ~(not) currently has an effect when followed by M(ore), U(user), L(ocal) or I(nvited) (with the .R(ead) I(nvited) command, described later). When followed by itself, it does what you'd expect, and negates itself. Useful, eh wot? Chapter 3: User Command Reference 42 The ~(not) M(ore) sequence is useful in Mail>, or if a user has the `more' prompt enabled by default in his/her configuration, and wishes to read some messages without using `more'. The ~(not) U(ser) sequence will display all messages *except* those to or from the specified user. The ~(not) L(ocal) sequence, usable only in a shared room, will display only messages that did not originate on this system. The ~(not) I(nvited) sequence, usable only in a private room, will list all users who do not have access to the room. =(headers) This modifier is similar in purpose to the single-key [=]new headers command. It tells Fnordadel to display only the headers of the messages that are shown. Users with Aide, Co-Sysop or Sysop status will see somewhat different header information than will regular users. For a full description, see Section 3.1.1.1 [Entering and reading messages], page 25. X(modem) Y(modem) W(xmodem) V(anilla) The above four options shouldn't be surprising in what they mean. They permit users to download a selection of messages (optionally qualified by other .R(ead) modifiers) using a standard file transfer protocol. The resulting text file can be read or edited on the user's own system. For details about the various protocols, see Section 12.2 [File Transfer Protocols], page 147. Note that Wxmodem may not be available, since we may have disabled the code we inherited due to problems we haven't had inclination to fix. C(apture) This .R(ead) option permits users to capture the selected messages into the held buffer, rather than display them on the screen. This feature is generally used to capture a single message into the buffer, for purposes of quoting at some length from it. .R(ead) # (message number) This command will probably be rarely used by anybody. What it does is allow a user to read a specific message in a room, by supplying its message ID number. Message ID numbers can be obtained by Co-Sysops using `.R=', described in this section. Normal users can only get message ID numbers in anonymous rooms, where they are a normal part of each message header. Chapter 3: User Command Reference 43 3.2.2.2 Reading files As time went by, and more people started using Citadels as general-purpose BBSes, the need for file-transfer capabilities grew. Thus a number of file reading commands were added (and continue to be expanded upon), which more or less parallel appropriate message reading options. .R(ead) D(irectory) *.doc This command enables users to get a list of files in a directory room. The list is sorted alphabetically by file name, and the size of each file is listed. After all files have been shown, the total number of bytes taken by them will be displayed. Users on the system console will also be shown the total bytes free in the room, and what directory the room is linked to on the storage device. A single file name or mask containing wild-card characters may be supplied with the command. The system will search the directory for all matches to the value entered, if any, and display them. The normal wild-cards (`*' to match any sequence of characters, and `?' to match any single character) may be used. If the user executing the command is not an expert, the system will prompt for the file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. .R(ead) E(xtended directory) *.foo This command is like the one above, with the difference that a description will be displayed for each file, if there is one defined. The system will automatically request a short description from users who upload files to the system, but if files are put into the room in any other fashion, the Sysop will need to manually create descriptions for them in the directory's .fdr file. See Section 12.1 [File Directories], page 147. Again, a single file name or mask containing wild-cards may be supplied with the command. The system will search the directory for all matches to the value entered, if any, and display them. The normal wild-cards (`*' to match any sequence of characters, and `?' to match any single character) may be used. If the user executing the command is not an expert, the system will prompt for the file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. .R(ead) [M+-XYWVC] [DE] files.ext The directory commands described above have some options to improve their usefulness. As above, if the user executing the command is not an expert, the system will prompt for the file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. M(ore) This facility, a recent addition, gives to file operations some of the same functionality that M(ore) has given to message operations in the past. We call the use of M(ore) with file transfers the __file browser__, since it lets users browse through Chapter 3: User Command Reference 44 directories of files, one at a time, and do various things with them. Hitting `?' at the Browse cmd: prompt should display a list like this: [A]- view this entry again [B]ackup to previous file [C]lear batch list [H]eader listing of ARC, LZH, ZOO file [M]ark this file for batch transfer [N]ext file (also <SPACE>, <CR>) [U]nmark a file [V]iew batch list e[X]it the browser (also [Q]uit, [S]top) See Section 12.3 [The File Browser], page 148, for a full treatment. + (After) date This option will cause the system to request a date from the user. Only those files with date stamps after the given date will be shown. The date format is the same as used by the rest of Fnordadel, `YYMMMDD'. The year, `YY', may be ommitted. See Section 3.2.2.1 [Multi-key message reading commands], page 39, for other details. + (After) and - (Before) can be used together. See the next section for details. - (Before) date This option, if you can't guess, will cause the system to display only those files with date stamps prior to the user's given date. See Section 3.2.2.1 [Multi-key message reading commands], page 39. + (After) and - (Before) can be used together, if desired, to specify a range of dates. The range is inclusive. So, for example, entering `.R+-A' and answering `91Jan10' for the ``after'' date and `91Jan15' for the ``before'' date, would net you a list of all files uploaded on or after 91Jan10, and on or before 91Jan15. The system does no checking to ensure that the two dates form a sensible range. Thus, if you reversed the two dates in the above example, the system would search long and hard and find nothing. X(modem) Y(modem) W(xmodem) V(anilla) The above four options are the standard transfer protocols you've no doubt come to love. Their use with `.RD' or `.RE' permit users to download a directory listing (optionally qualified by other .R(ead) modifiers) using a standard file transfer protocol. The resulting text file can be examined Chapter 3: User Command Reference 45 on the user's own system at his/her leisure. For details about the various protocols, see Section 12.2 [File Transfer Protocols], page 147. Note that Wxmodem may not be available, since we may have disabled the code we inherited due to problems we haven't had inclination to fix. C(apture) This .R(ead) option permits users to capture the selected directory listing into their held message buffers. It is probably best suited for use in shared rooms where you wish to let other systems know about files on-line on your system. Users actually calling your system can do a `.RE' command themselves, so why enter a redundant message? .R(ead) F(ile) foobar.txt This command, usable only in a directory room, will cause Fnordadel to display the contents of the specified file on the user's terminal. Hopefully, the user will only do this for text files, since binary or compressed files are not very interesting to read. No formatting to the user's configured screen width is done, so if the text file is formatted with lines longer than the user's terminal can display, a mess will result. See the T(ext) modifier in Section 3.2.2.2 [Multi-key file reading commands], page 43, for a way around this. As mentioned before, if the user executing the command is not an expert, the system will prompt for the file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. .R(ead) [+-XYWVCT] [FB] files.ext The .R(ead) F(ile) command, like the message-reading commands, has many modifiers to increase your joy in using Fnordadel. They can frequently be strung together to increase your confusion. Finally, as if that wasn't enough, a special variant of the command, .R(ead) B(atch file), is available for downloading multiple files at a time, using Xmodem or Ymodem. As mentioned before, if the user executing the command is not an expert, the system will prompt for the file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. Now, here are the available modifiers: + (After) date - (Before) date The above two modifiers work just like they do with directories and message display. See Section 3.2.2.1 [Multi-key message reading commands], page 39, for details on how to do it. X(modem) Y(modem) W(xmodem) Chapter 3: User Command Reference 46 V(anilla) The above four protocol modifiers work in the same fashion as they do in other instances, with the addition that if Xmodem or Ymodem is chosen, the user may also do a batch file transfer. See Chapter 12 [File Transfers], page 147, for details. C(apture) This modifier works like the C(apture) modifier for message-reading commands. It allows the contents of one or more text files in a directory room to be sent to a user's held buffer, there to be mangled at his/her whim. Note that the system can't tell a text file from a binary or compressed file, so be careful what gets captured. Also note that only the first 10000 characters of the file(s) will be captured; this is the maximum Fnordadel message size. T(ext) This modifier allows users to view the contents of text files with the normal Fnordadel formatting tricks done to them. If a text file is properly formatted, the results will be lovely to behold. If it isn't, however, the results will be heinous. The typical problem encountered is with paragraphs not being indented on the first line; Fnordadel will run them into the previous paragraph just as it will with messages typed on the system. Batch downloads This is a fun feature for file-mongers to use, as it allows them to download multiple files via one single solitary .R(ead) command. The command must be used after the X(modem) or Y(modem) modifiers, or the user will get something that says B(inary file) and doesn't do anything useful. Standard Ymodem batch protocol is supported. The user may supply several different file names after the command, any of which may contain standard wild-cards `*' and `?'. Alternatively, if the user has compiled a list of files to batch-transfer, using the file browser (see Section 12.3 [The File Browser], page 148), he/she can just hit `<CR>' instead of entering any file names. The entire batch list will then be transferred. .R(ead) H(eader) foo.arc This command, which can be used only in a directory room, will display the header information for any .arc file in the room. Callers may use this to get an idea of the contents of an .arc file before downloading it. The .arc format is the only one supported by Fnordadel ``out of the box''. However, the Sysop can define special door programs that will enable users to execute this command for additional formats, such as .zoo and .lzh. See Section 9.3.2 [Archiver doors], page 130, for more information on doing this. Also consult `ctdlcnfg.doc'. Chapter 3: User Command Reference 47 As mentioned before, if the user executing the command is not an expert, the system will prompt for the file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. 3.2.2.3 Reading other information .R(ead) ? This command, predictably, will cause the system to display a brief help file about the .R(ead) command. Naturally, the Sysop will have configured the help files properly so as to make this possible. .R(ead) I(nvited) This command, usable only in hidden or invitation-only rooms, will show the user executing it a list of all users with access to the room. The command may be inverted using the `~' modifier, in which case the list will contain all users lacking access to the room. See Section 3.2.2.1 [Multi-key message reading commands], page 39, for details on `~'. .R(ead) S(tatus) This command will display for the user some mostly meaningless and occasionally esoteric status information about the system. Try it and you'll see what we mean. We also added some useful data about various privileges possessed and the values of various user call limits. 3.2.3 Navigation commands After reading the perhaps bewildering set of possibilities available with .E(nter) and .R(ead), you should be pleased to find that room navigation is a more straightforward affair. However, true to form, the multi-key navigation commands offer a few things not available with their single-key counter-parts. .B(ackup) roomname This command provides a way to leave the current room (without updating any of its messages as ``old'') and return to a previously-visited room. Any messages in the second room, if ``new'' at the time of login and now marked as ``old'', are unmarked, and may again be read using [N]ew. .B(ackup) is the multi-key sibling of the [B]ackup command (see Section 3.1.1.2 [Navigation], page 27), and is functionally identical to the .U(ngoto) command (see below). .U(ngoto) may not be available on any given Fnordadel, so be aware that .B(ackup) is always there. .G(oto) ? This is identical to the single-key command [K]nown-rooms. See Section 3.1.1.2 [Navigation], page 27. Chapter 3: User Command Reference 48 .G(oto) roomname This command allows the user to leave the current room (at which time Fnordadel will mark all messages in the room as ``old'', i.e. as having been read), and proceed to another room. The difference between this command and the single-key [G]oto command is that here the user gives a room name explicitly, and the system will go there whether it has new messages in it or not. [G]oto only goes to rooms containing new messages. In order to be more useful, the .G(oto) command allows sub-strings of room names to be used. Thus, the roomname value can be just a few sequential characters from anywhere in a room's name, and Fnordadel will find it and go there. If two or more rooms match the sub-string, the system will go to the first one as appearing in the known rooms list. .K(nown) ? This command will display a short list of the available .K(nown) options. .K(nown) [DHNP] <CR> The basic command .K(nown) <CR> command is like the single-key [K]nown command, and displays a list of rooms accessible by the current user. This command differs from the single-key version in that the list may contain rooms from any floor, whether the user is operating in floor mode or not. Also, the list will not be separated into groups of rooms based on presence or absence of new messages in The rooms. See also Section 3.1.1.2 [Navigation], page 27, ([K]nown-rooms); Section 3.2.4 [Other multi-key commands], page 49, (.Z(list forgotten)); and Section 3.3 [Multi-key User Floor Commands], page 51, (;K(nown floors)). The command can be further augmented by several options: D(irectory rooms), H(idden rooms), N(etwork rooms) and P(ublic rooms). The options can be mixed and matched in any order, and will restrict the types of rooms shown by .K(nown) to those matching *all* the options. That is, for a room to be shown, it must match each attribute entered by the user. So `.KD<CR>' will show all directory rooms, while `.KDH<CR>' will show all directory rooms that are also hidden. .K(nown) [DHNP] R(ooms) roomname This command will display for the user a list of known rooms matching the roomname value entered. Fnordadel searches for all room names containing the sequence of characters in the entered string and lists them. The room type options [DHNP] described in the previous section are available, and work the same way. .S(kip) ? This command will display a short help screen concerning the use of the .S(kip) command. (Assuming the help files are in order, of course.) .S(kip) roomname This command is to the single-key [S]kip command as .G(oto) is to the single-key [G]oto command. It allows the user to leave Chapter 3: User Command Reference 49 the current room and proceed to another one as specified by the roomname value. roomname may be just a few characters of the room's full name, and Fnordadel will properly find it and go there. As with .G(oto), if more than one room's name matches the entered value, the system will go to the first one as appearing in the known rooms list. The difference between .S(kip) and .G(oto) is the same as that between [S]kip and [G]oto. Namely, .S(kip) does not mark any messages in the current room as having been read by the user. The user may return to the room later the same session, or on the next call, and find the same new messages awaiting. See Section 3.1.1.2 [Navigation], page 27, on [S]kip. .U(ngoto) roomname This command is identical in function to .B(ackup), and the multi-key counter-part of [B]ackup/[U]ngoto. The command provides a way to leave the current room (without updating any of its messages as ``old'') and return to a previously-visited room. Any messages in the second room, if ``new'' at login time and subsequently marked as ``old'', are unmarked, and may again be read using [N]ew. This command will be unavailable if citadel is started with the `+backup' command-line option. In such a case, the .U(pload) command is active, and .B(ackup) must be used by people who wish to do this sort of ungotoing. 3.2.4 Other multi-key commands Finally, there are a few additional miscellaneous multi-key commands that will prove useful from time to time. .H(elp) ? Assuming the system help files are set up properly, this command will take the user to the main help menu, and present the list of topics about which help is available. .H(elp) topic This command short-cuts the above main help menu, and goes directly to the topic topic as entered by the user. The list of available topics can be seen by using the command .H(elp) ?. .T(erminate) ? This command will show the user a list of available options with the .T(erminate) command. These options allow the user more flexibility in how the system treats his/her exit, than does the single-key [T]erminate command. .T(erminate) S(tay) This command allows the current user to log off the system, updating all necessary records concerning what rooms were visited, what messages were read, and so on. The only difference from the normal [T]erminate command is that Fnordadel will not cause the modem to hang up on the user. This allows Chapter 3: User Command Reference 50 him/her, or another person sitting there, to then sign on with another account, without having to dial the system back and possibly get beat to the punch by the hundreds of other loyal users trying to call. .T(erminate) Q(uit-also) This command behaves the same as [T]erminate. Why anybody would want to use it is beyond us. .T(erminate) P(unt) This command is another useful one. After executing it, the system will log the user off and hang up the modem as usual. However, the system does not update any room-related records, such as what rooms were visited or forgotten, or what messages were read. In other words, it's just like the user never called. This is good if a user has an interruption force a termination before everything was read or written, and wants to call again later and see everything the way it was for the current call. Configuration changes made using `.EC' or `.EO' are not lost, and the receipt flags on messages in Mail> are also permanently updated (i.e., authors or mail to you will be able to tell you read their messages even though you left using P(unt)). .T(erminate) Y(es) This command, like .T(erminate) Q(uit-also), is just the same as [T]erminate. One day we really must eliminate some of this repetitive redundancy. .U(pload) file.ext This command is the extended counter-part to the single-key command [U]pload. It behaves identically. See Section 3.1.1.3 [Other room prompt commands], page 29. This command is only available if citadel is started with the `+backup' command-line option. Otherwise, the .U(ngoto) command is active. As usual, if the user executing the command is not an expert, the system will prompt for a file name; otherwise, no prompt is given, and the system will wait for the file name to be typed on the command line. .Z (list forgotten) This command fills the gap left by [K]nown, .K(nown) and ;K(nown), by giving the user a list of rooms that he/she used [Z](forget) to forget about. This allows the user to regain access to those rooms, by using .G(oto) and the full room name, to return to a room. Once done, the room will be unforgotten. One thing that this command won't do is list forgotten hidden or invitation-only rooms. If the user forgets a hidden room, he/she can still get back to it by using .G(oto) with the room's full name, but that name will have to be remembered or obtained without any help from Fnordadel. Invitation-only rooms can't be entered again unless the user is reinvited. Chapter 3: User Command Reference 51 3.3 Multi-key User Floor Commands In addition to the extended commands described above, there are some multi-key commands that apply specifically to floors. These are signified by starting the command with the `;' character to indicate that a floor command is about to happen. As with `.?', `;?' will show a list of available extended floor commands. It should look like this: ;C(onfigure floor mode) ;G(oto) floorname ;K(nown floors list) ;R(ead) floor w/ all .R(ead) options ;S(kip all rooms on this floor) ;Z (forget this floor) ;> (move to next floor) ;< (move to previous floor) ;C(onfigure floor mode) This is a quickie way to switch from floor mode to normal mode (or vice versa). The current state of floor mode will be saved for subsequent logins. This can also be done in the `.EC' menu or with the `.EO' command---see Section 3.2.1.3 [Other multi-key entry commands], page 37, and Section 3.5 [User Configuration], page 56. ;G(oto) floorname This command takes a full or partial name of a floor, and takes the user to the first room in said floor, if found and accessible by the user. Any new messages in the room being left via ;G(oto) are marked as old, as per usual. ;K(nown floors list) This is the most commonly used floor command. It prints a nice formatted list of all floors in the system, and which rooms are on which floor. The list is printed in two parts: first, the floors containing rooms with unread messages, and second, those floors without such rooms. A floor will be listed as having rooms with unread messages no matter how many such rooms are on the floor; there may be only one. If none of the rooms on a floor are accessible to a user, he/she will not be shown any information about the floor. ;R(ead floor) This command is like .R(ead), but traverses all rooms on the current floor looking for messages. All .R(ead) options are usable, although G(lobal) in particular wouldn't make sense since it goes after all rooms on the system. If the user isn't in floor mode, this command will have exactly the same effect as .R(ead). ;S(kip this floor) This command causes *all* rooms on the current floor with unread messages to be marked as skipped. The user is taken to the next floor containing unread messages. Chapter 3: User Command Reference 52 ;Z (forget this floor) This is a fairly dangerous command, in that it causes all rooms on the current floor to be forgotten (a la the [Z]forget command). The user is taken to the base floor after executing this command. See Section 3.1.1.3 [Other room prompt commands], page 29. ;> (move to next floor) ;< (move to previous floor) The ;> (next) and ;< (previous) commands are identical to the single key [>]next and [<]previous commands. See Section 3.1.1.2 [Navigation], page 27. 3.4 The Message Editor As mentioned earlier, the Fnordadel message editor is rather unlike the editors on most other systems. The big difference is that a message, to Fnordadel, is just a long string of characters up to 10000 in number. In most other systems, a message is a series of lines, each of which is a string of characters that usually can't exceed 80 (or so) in number. Message editing on such systems can be cumbersome, since every command works on the message lines. Sadly, the editor's concept of lines rarely meshes with the user's concept of sentences and paragraphs. This causes trouble when text needs to be deleted or added to the message. In Fnordadel, there are no message ``lines'', just straight text. The only thing that Fnordadel recognizes is the concept of a paragraph. Paragraphs are separated by a carriage-return in the text, followed by at least one space. This is a crucial fact that causes people a lot of confusion, so it will be emphasized: If a `<CR>' is typed and *not* followed by at least one space, Fnordadel will throw the `<CR>' away, and replace it with a simple space character. This permits the system to format things nicely for users with a different screen width than the author, no matter how many spurious `<CR>' characters the author may enter. Line-based editors usually do not work this way. While entering the text of a message, Fnordadel doesn't worry about making it look pretty by doing word-wrap, i.e. preventing whole words from being broken on the right-hand margin of the user's screen while he/she types. Fnordadel performs no pretty formatting on the message until it is actually displayed, at which time it will oblige the user reading it by formatting everything neatly out according to the configured screen width. At various times during the course of entering a message, it is likely that a user will want to do things such as display the text entered so far, perform some edits, or save the message. To get out of message entry mode, the user must enter two `<CR>s' in a row. He or she will then be sitting at the main message editor prompt, which also shows the current room name (for those forgetful types). Pressing `?' will generate this list: Chapter 3: User Command Reference 53 Editing: [B]lock replace text [D]elete text [I]nsert paragraph break [K]ill text block [R]eplace text Control: [A]bort entry [C]ontinue [H]old Message for later [L]ocal save [N]etwork save (shared rooms/mail) An[O]nymous message toggle [P]rint formatted [S]ave message [B]lock replace text This command allows the user to replace a large chunk of text with something else. When it is invoked, Fnordadel will prompt for the starting and ending strings of text which ``frame'' (and are included in) the block of text to be replaced. If the two strings do not match a block of text somewhere in the message, Fnordadel will say as much and return to the editor prompt. Otherwise, the system will prompt for the replacement text, which is limited to about 200 characters in size. The user may just hit a carriage-return here to cause the block of text to be replaced with nothing (i.e. deleted). When the replacement text is entered, Fnordadel will then echo back to the screen the entire block of text it found as a match for the starting and ending search text. The system will display a little bit of additional text before and after the matching block to give an idea of the context surrounding the block, so the user can make sure the right stuff is going to be replaced. Following will appear a prompt: Replace this one? (Y/N/[A]ll/[Q]uit): At this point, the user may enter `Y' to cause the replacement, or `N' to cancel it. In either case, the system will search for another match to the starting and ending text. If found, the prompt will appear again. If the [A]ll option is chosen at some point, the system will then automatically search out and replace all remaining instances of the starting and ending text, starting with the block currently displayed. The process is unstoppable, so be sure it's what is desired. The [Q]uit option will cancel the current replacement being asked about, and stop the system from looking for any remaining candidates. Once the searching stops, by [Q]uit or because there are no more matches, the system will report how many matches were found and how many were actually replaced. Chapter 3: User Command Reference 54 One thing to note about all of the Fnordadel delete/replace commands is that they search for text in reverse, from the end of the message towards the start. This is done because, in general, users want to change the text they typed recently more often than the text they typed awhile ago. [D]elete text This command permits the user to specify a single (usually short) text string to be deleted from the message. If the string is found, it will be echoed back for confirmation, with some surrounding text for context. As with [B]lock replace, a prompt will appear allowing [A]ll instances to be deleted, or the process to be [Q]uit. [I]nsert paragraph break So you've written a 10K message and just realized that you didn't put a single paragraph break in it? Bad form, you're sure to lose face. You can correct the faux pas using this command. Simply invoke it and supply a short text string that uniquely identifies the place in your message where you want a paragraph break. Fnordadel will find the string, and insert a break just before it. That's *before*, not after. Note that the system does not, at the moment, prompt the user when it has found a match for the search string. Be careful not to insert breaks in spurious loca tions. [K]ill text block This command is the deletion equivalent of [B]lock replace, and works in a similar fashion. The sole change is that [K]ill doesn't ask for replacement text, since there isn't going to be any replacement except hard vacuum. [R]eplace text This command is the replacement equivalent of the [D]elete text command above. It functions in the same manner as [B]lock replace, but requests only a single (usually short) text string to search for. [A]bort entry This command permits the user to throw the message away if he or she has second thoughts about it. The system will prompt for confirmation before tossing the message. Ain't that considerate? [C]ontinue This command allows the user to resume message entry where it was left off. The two carriage-returns entered to escape from message entry mode before are not kept around, so message entry will continue immediately after the last character typed before the two `<CR>'s. The last few words of the text so far are redisplayed so the user can recapture his or her train of thought. Chapter 3: User Command Reference 55 [H]old message for later This command is very handy when used properly. [H]olding the message will store it in a temporary buffer where it can be retrieved later using the .E(nter) H(eld-message) command (see Section 3.2.1.1 [Multi-key message entry commands], page 35), or using [H]eld message from `more' mode (see Section 3.6 [More Mode], page 59). Meanwhile, however, after pressing `H', the user is returned to the room prompt and can go about normal activities like reading other messages and moving to other rooms. The held message does not have to be continued in the room in which it was originally started; it can be resurrected and saved into any other room, even Mail>. This command is particularly useful for replying to several different messages within a single message. The user may enter a reply to one message, [H]old the reply, and continue reading additional messages and tacking replies onto his/her own existing message. This is usually considered to be good form, especially if posting a series of replies in a networked room. One message is easier to transmit than many, and also will take up fewer valuable slots on other variants of Citadel that can only store a fixed number of messages in each room. Each held message is squirreled away in a disk file, from where it is retrieved when the user continues it. A `ctdlcnfg.sys' parameter called #keephold lets the Sysop choose to have Fnordadel throw away each hold file when the user who saved it logs out, or to keep the hold file until the user continues his/her message. This could be any time in the future (unless the user's account scrolls off the system before he/she continues the message), so the hold files might take up quite a bit of space. If this happens, the Sysop can delete them manually from GEM or a command shell. [L]ocal save This command allows a user to force Fnordadel to save a message as a non-networked message, in a room that might otherwise automatically send the message out over the network. It is typically used when entering a reply to something that should be kept local due to being of purely local interest, or just plain snarky in tone. Other Sysops on the network usually won't like to see either type of message coming from your system. This command works in the Mail> room, as well. If a message has been entered to a user residing at another system on the network, hitting `L' allows redirecting the message to a user on the local system instead. [N]etwork save This command has the opposite effect of [L]ocal save, above. One additional restriction, however, is that not all users may have the necessary status to make a message go out over the network. This depends on the #allnet parameter in `ctdlcnfg.sys'. If #allnet is not set, the Sysop must grant Chapter 3: User Command Reference 56 network privileges to users on an individual basis. See .E(nter) N(et-message) in Section 3.2.1.1 [Multi-key message entry commands], page 35, #allnet in Section 8.1.2 [Optional networking parameters], page 98, and Section 5.2 [User Status Commands], page 80. As with [L]ocal save, [N]etwork save works in Mail>. If users wish to send mail to long-distance systems, they will need __long-distance network credits__ in addition to network privileges. An[O]nymous message toggle In rooms which are anonymous, author names and the dates/times of entry are normally not stored or shown with messages. If a user wishes to unquestionably identify a message as his or her own, however, this command will override the normal anonymity of the room and put a standard header on the message. See Section 2.2 [Rooms], page 15, and the .A(ide) E(dit) command in Section 4.1.2 [The .A(ide) command], page 63, for more on anonymous rooms. [P]rint formatted This command will display the message text entered so far, nicely formatted to the user's configured screen width. Message display can be manipulated using [P]ause, [J]ump, etc., as usual. [S]ave message Here's where all the hard work pays off! [S]ave the message and then sit back and wait for all the plaudits and applause to come pouring in. Just don't forget to duck the tomatoes and rotten eggs from the unenlightened. 3.5 User Configuration There is an ever-increasing list of personal configuration options that a Fnordadel user can set. Some of them (all of them, if a user claims Citadel expertise) are set when each user first logs into the system. If they ever need changing, there exist the .E(nter) C(onfiguration) and .E(nter) O(ption) commands. `.EC' is a menu-driven; each option in its menu can also be set directly by `.EO'. See Section 3.2.1.3 [Other multi-key entry commands], page 37. The list of options is as follows: [A]uto new [E]xpert mode [F]loor mode [L]inefeeds switch [N]ulls [O]- show last old message on [N]ew [P]ause between messages [R]unning count of msgs while reading [T]- show time of message creation [V]iew configuration [W]idth of screen Chapter 3: User Command Reference 57 e[X]it [Y]- set default transfer protocol [A]uto new This flag tells the system whether it should automatically show the user all new Lobby> messages after he or she logs in. Most Citadels do this whether you like it or not. We didn't like it, so we took it out. After much protest, we put it back in as a configurable thing. The default the first time this question is posed (when a new user first logs in) is set by the `ctdlcnfg.sys' parameter #defautonew. [E]xpert mode This parameter allows a user to control Fnordadel's behavior in some ways. In general, an experienced user is shown far less verbose information in terms of command prompts and automatic help messages. The default the first time this question is asked (during login) is ``no''. [F]loor mode This option allows the user to control whether he/she will use the system in floor mode. If ``no'', the system will appear to be one big unorganized collection of rooms. If ``yes'', rooms will be grouped by their defined floors, if there are any. The default here is ``yes''. See Section 2.3 [Floors], page 17, for a description of floors, and Section 3.3 [Multi-key User Floor Commands], page 51, for commands to use them. The default the first time this question is asked (during login) is set by the `ctdlcnfg.sys' parameter #deffloormode. [L]inefeeds switch This parameters allows a user to tell Fnordadel whether each line output by the system should be ended with just a carriage-return (`<CR>') character, or both a `<CR>' and a line-feed (`<LF>'). On some terminals (mostly ancient ones), a `<CR>' character only causes the cursor to return to the left margin, not to advance a line as well. Thus the `<LF>' characters might be needed. The default here the first time through (during login) is ``yes'', to output both `<CR>' and `<LF>'. [N]ulls This is the number of non-displaying ASCII ``null'' characters that Fnordadel will output at the end of each line on the screen. This capability, which is mostly not understood by users these days, allows them to cause Fnordadel to slow output down for them. (Nulls are non-displaying characters, but they still take time to send over the modem.) Users with fast modems (2400 bps and higher) can use this feature to help them read what's being sent without having to hit the [P]ause key until it breaks. The initial default value (during login) is 0 nulls. [O]- show last old message on [N]ew This option allows the user to specify whether Fnordadel should show the last old (i.e. previously read) message in a room, if there is one, each time the [N]ew command is used. Users with memory problems might want to answer ``yes'', and use Chapter 3: User Command Reference 58 the last old message to remind them of the discussion. The first-time default answer here (during login) is controlled by the `ctdlcnfg.sys' parameter #deflastold. [P]ause between messages This option allows a user to specify the `more' prompt to be automatically used by all message-reading commands. See Section 3.6 [More Mode], page 59, for details about the `more' prompt. Note that `more' mode is never the default for file-reading commands. Also note that the `more' default can be overridden using the `~' modifier with .R(ead); see Section 3.2.2.1 [Multi-key message reading commands], page 39. The default value to this flag when a new user signs on is initially controlled by the `ctdlcnfg.sys' parameter #defreadmore. [R]unning count of msgs while reading This parameter allows a user to tell Fnordadel to show him/her a running downward count of the number of messages remaining to be read, while using any message-reading command. The count is shown in the message header as ``(n left)'', where ``n'' is the number of messages still to be read. This option's initial default value for new users is set with the `ctdlcnfg.sys' parameter #defnumleft. [T]- show time of message creation This option allows the user to control whether Fnordadel will display message creation times in message headers, or just creation dates. The default here when new users login is set by the `ctdlcnfg.sys' #defshowtime parameter. [V]iew configuration This command does the obvious, and displays the user's current configuration settings. [W]idth of screen This is the user's terminal's line width in characters. Fnordadel imposes a range limit of 10 characters minimum, 255 characters maximum. Most users these days will have an 80-character screen width. Due to the way Fnordadel formats information for display, it's a good idea to set this value to 1 less than the actual width. Thus an 80-column user would answer 79. Doing this prevents the odd spurious blank line from showing up. The default value here is whatever the Sysop has defined as the system's screen width (see width parameter in `ctdlcnfg.doc'). e[X]it Another obvious command. This one exits the menu and returns the user to the room prompt. Any changes made in the menu are updated into the user's log entry. [Y]- set default transfer protocol This command allows the user to set a default transfer protocol. The choice may be made from: Xmodem, Ymodem and Wxmodem. Chapter 3: User Command Reference 59 Wxmodem may not be available, since we don't believe the code works anyway, and have never bothered to fix it. The protocol specified here will be used with the [D]ownload, [U]pload (if the Sysop has made it available) and .E(nter) F(ile) commands. All are documented in this chapter. See also Chapter 12 [File Transfers], page 147. The default value used for this option when users first login is ``Xmodem''. 3.6 More Mode As mentioned in Section 3.2.2 [Multi-key read commands], page 38, one of the message-reading options available is called M(ore). To recap briefly, with `more' mode, the system pauses after each message displayed by any of the message-reading commands, to permit the digestion of what was just read, and/or the entry of a few other commands, without breaking out of the message-reading sequence. M(ore) is used by default by all of the message-reading commands when the user is in Mail>. There is also a user configuration option that will make the system default to `more' mode all the time, in all rooms, with both single- and multi-key commands. See Section 3.5 [User Configuration], page 56. Hitting `?' at the `more cmd:' prompt will display a list of available options: [A]- this message again [B]ackup to previous message [D]elete this message [H]- continue held message [N]ext message (also <SPACE>, <CR>) [R]eply to this message e[X]it message reader (also [Q]uit, [S]top) [A]- this message again This M(ore) command will cause the system to redisplay the message just read, for further critical examination, or for the short of memory. [B]ackup to previous message The command backs up one message, and shows what has gone before. The command does nothing if there is no previous message. Note that if reading new messages, one can not back up into those that are old. The reverse is also true. [D]elete this message This command allows users to delete messages. See Section 3.7 [Deleting Messages], page 60, for more. [H]- continue held message This M(ore) command is quite useful, as it permits the user to jump into the held buffer and add to a message already in progress. Once the desired additions have been made to the Chapter 3: User Command Reference 60 message, it can be held again or saved, and the system will resume the message-reading cycle where it left off. [N]ext message (also <SPACE>, <CR>) This command, or its equivalents, will cause the system to move on to the next message in the sequence. When there are no more messages to be read, the user is returned to the regular room prompt. Messages entered by the user during reading are not shown, if reading in an old-to-new direction. [R]eply to this message This command permits the user to start a new message which will be in reply to the message just read. In all rooms except Mail>, the reply has no special significance. In Mail>, however, the system will automatically address the new message to the author of the message to which the user is replying. As with all messages, the user can [H]old it if so desired. Whether it is held or saved, the system will return to the message-reading cycle where it left off. The system may prevent the reply for a variety of reasons: the would-be recipient of the message is no longer in the user log; the message must be netted to reach the recipient, and the replier doesn't have net privileges or sufficient l-d credits; the message must be netted but the system can't recognize the destination net node; etc. e[X]it message reader (also [Q]uit, [S]top) This command halts the message-reading cycle immediately and returns the user to the room prompt. There are a few additional M(ore) commands available to users with Aide, Co-Sysop or Sysop status. They permit moving, copying and journalling messages, and other more esoteric things. See Section 4.1.4 [Aide message deletion and movement], page 68, Section 4.2.2 [Message journalling], page 72, Section 4.2.3 [Promoting local messages to net messages], page 73, and Section 5.3.3 [Mail receipt flag], page 84. Also, use of M(ore) can be negated when the modifier is used in conjunction with the `~' modifier; see Section 3.2.2.1 [Multi-key message reading commands], page 39. 3.7 Deleting Messages Users who enter messages may find, from time to time, that it is necessary to delete one for some reason or other. Fnordadel permits regular users to delete messages, with the following restrictions: o A message must have been authored by the user trying to delete it. o A message in a normal room (i.e., not Mail>) must have been entered by the user during his or her current login session, to be deletable. Once the user logs out, all messages in normal rooms become locked. Only an Aide, Co-Sysop or the Sysop can delete them then. Chapter 3: User Command Reference 61 o A message in the Mail> room can be deleted by the author at any point, provided that the intended recipient has not read the message yet. Fnordadel keeps track of whether Mail> messages are read or unread by their recipients; once the recipient has seen the message, there is no point deleting it. Assuming that the above restrictions permit a user to delete a given message, there are two ways to carry out the deletion: 1. While reading messages normally - Use normal message-reading commands (e.g. [N]ew or [R]everse) to display the desired message on screen, and [P]ause the system somewhere in the body of the target message's text. - While the system is paused, hit `D' for [D]elete. - The system will resume displaying the message through to its end, then display a prompt like this: [D]elete [A]bort? - To delete the message, hit `D'. To abort the process, hit `A'. 2. While reading mesages using `more' - Since the above method can be cumbersome, or down-right difficult in the case of small messages that scroll by before you can pause the system, users may also select the [D]elete command from the .R(ead) M(ore) prompt. See Section 3.6 [More Mode], page 59. - The rest proceeds as above.