home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-09-03 | 112.2 KB | 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.
-
-