Subj : Re: Switch to linux
To : Andre Robitaille
From : g00r00
Date : Sat Aug 22 2020 10:49 am
AR> It doesn't look like an easy job, for sure. I didn't realize that there
AR> was useful info in there that wasn't in the documentation until maybe a
AR> week in. Now I just let people know to check there and in the command
AR> 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.
AR> 1. The shell field isn't intuitive partially because by default it has
AR> Windows commands in it, so I think it's already correct and working.
AR> (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.
AR> 2. Then I find that it's not processing FTN events properly, but the 'mis
AR> server' window and logs don't show any errors about it not finding mutil
AR> 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.
AR> 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.
AR> 4. So through Mystic Guy videos, I can kind of tell that there are
AR> supposed to be files showing up that when processed disappear. So I
AR> determine that if fidopoll runs right, files will show up, and if
AR> 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?
AR> 5. Okay, so there must be something wrong with my shell field. What are
AR> the pipes for? Are they actually piping anything, or is it like ';' in
AR> Linux? It's not using & or && like Windows expects, so I'm extra
AR> 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.
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:
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.
AR> 7. So maybe it's a path issue. Should I use ./ or a full path. I'll try
AR> explicitly calling the path since I can't go wrong with that. (intuitive
AR> 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.