It doesn't look like an easy job, for sure. I didn't realize that there was useful info in there that wasn't in the documentation until maybe a week in. Now I just let people know to check there and in the command reference, since there's some useful bits in there too.
My documentation of new features goes into the "whatsnew" file with each build I release, and then into the whatsnew section on the Wiki, and eventually it will find its way into a more organized place on the Wiki.
Its a bad way to do things, mostly because of how infrequently I work on the structured part of the Wiki. The information is out there its just not always easy to find depending on what you're looking for.
Documentation is certainly unintuitive because of that.
1. The shell field isn't intuitive partially because by default it has Windows commands in it, so I think it's already correct and working. (intuitive)
The default event examples are not specific to Windows or anything really, they're just examples. You could use them for any OS Mystic runs on or not use them at all.
2. Then I find that it's not processing FTN events properly, but the 'mis server' window and logs don't show any errors about it not finding mutil or fidopoll or both. (intuitive)
Mystic events log and track previous results of every event it runs. Shell events are listed in the event window with a "time until execution" and when they do execute it shows that its running, shows exactly what commands it is executing, and then shows you the result reported back by the OS. All of that is logged and in the UI.
There is only so much Mystic can track when executing an unknown user configured command line as an event, and it does just about everything it can. Do you see it run on the screen and logs? If so what is the result?
MIS can only show that an event ran, what it tried to run, and if the OS says it ran successfully. If it says it ran successfully then you'd need to look at the logs of the program it ran.
3. Nothing tells me how it's supposed to look for Windows vs Linux, and
The commands for everything in Mystic are the same regardless of OS so there really isn't much to document as far as differences in how Mystic works.
4. So through Mystic Guy videos, I can kind of tell that there are supposed to be files showing up that when processed disappear. So I determine that if fidopoll runs right, files will show up, and if
they're processed by mutil those files will disappear. (documentation)
I am assuming you're watching the YouTube series on how to setup FidoNet network on a Pi. In the video it goes through the various steps and shows log files and what should be in the log files. It pulls for mail manually with fidopoll to show the mail exchange is setup properly. Have you done all of this stuff and did it all work?
If the messy documentation combined with this video series isn't sufficient, then what do you feel should be added to make it better?
5. Okay, so there must be something wrong with my shell field. What are the pipes for? Are they actually piping anything, or is it like ';' in Linux? It's not using & or && like Windows expects, so I'm extra
confused. Does it need spaces? Commas? (intuitive and documentation)
Here is the documentation for the semaphore/shell type pasted from the Wiki. It seems clear enough to me but I suspect you never saw it. Finding it *IS* unintuitive because its tucked away in the WHATSNEW section on the Wiki (I
left an update to TYPE1 out because this message is already getting long)
TYPE1: Semaphore
================
This event type listens for one or more "semaphore" files, and will execute
a command line if one or more of the semaphore files are found. Prior to
executing the command line, MIS will also delete the detected semaphores.
The following options are used for Semaphore type events. Any other
options not mentioned here can be ignored for this type:
Active - If yes this event will be active. Set to No to disable.
Description - This can be any description you want.
Exec Type - This is one of BBS, Shell, or Semaphore
Semaphore - This defines the semaphore filename to "look" for. If
there is no path included, Mystic will automatically look
in the configured semaphore directory. In addition, more
than one semaphore file can be monitored by using a pipe
symbol to separate them (|). For example:
Semaphore: echomail.out|netmail.out
The above example will look for the existance of EITHER
echomail.out or netmail.out in the configured semaphore
directory. If either file is found, the event will remove
the semaphore files and then execute the event.
Semaphore: c:\mybbs\somefile.txt
The above will list for the c:\mybbs\somefile.txt and
trigger the event if it is found.
Shell - This is the command line which will be executed when the
event is triggered. Similar to the Semaphore detection,
this can have one *or more* executions per event each
separated by a pipe. If no path is supplied, MIS will
default to the root Mystic BBS directory. For example:
Shell: domail.bat
The above example will execute domail.bat in the root
Mystic BBS directory.
Shell: mutil export.ini|fidopoll send|mutil import.ini
The above will execute 3 command lines in a row:
mutil export.ini
fidopoll send
mutil import.ini
If we put it all together we can get something like this:
Active: Yes
Description: Send outgoing echomail
Exec Type: Semaphore
Semaphore: echomail.out|netmail.out
Shell: mutil export.ini|fidopoll send|mutil import.ini
The above example wait for echomail or netmail.out, and
execute mutil to export, then fidopoll to send, then
mutil to import any new packets. Completely automated!
TYPE2: Shell
============
This event type executes at a defined time, defined on a weekly schedule.
When the event executes, it will execute the Shell command line. Like the
Semaphore event type, this Shell command can also execute multiple command
lines by separating them with a pipe character (|).
The different between this type and Semaphore is that instead of waiting
for a file, the event is defined by a specific execution time. This is
defined by picking which days of the week the event should execute, and
what time per day it should be ran (in 24-hour format). For example:
Active: Yes
Description: Pack message bases
Exec Type: Shell
Shell: mutil msgpack.ini
Exec Hour: 01
Exec Min: 30
Sun: No Mon: Yes Tue: No Wed: No Thu: No Fri: No Sat: No
The above event would execute once per week, at 1:30am on Monday morning
and execute the command line "mutil msgpack.ini" from the root Mystic BBS
directory.
7. So maybe it's a path issue. Should I use ./ or a full path. I'll try explicitly calling the path since I can't go wrong with that. (intuitive and documentation).
Maybe the documentation could link to some "how to use Linux" tutorials or some stackoverflow question on "what does ./ mean in Linux" and that could be helpful.
There really isn't one answer for this and its not something determined by Mystic. Its determined by your Linux setup, what you have in your path, what you're executing, etc. Mystic just executes what you tell it to execute, its up to you to understand how the OS works and what you need to put in that field. I would guess that you need to put a ./ though.
Thanks for the feedback!
--- Mystic BBS v1.12 A46 2020/08/22 (Windows/64)
* Origin: Sector 7 | Mystic WHQ (1:129/215)