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. 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. 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. Thanks for the feedback! --- Mystic BBS v1.12 A46 2020/08/22 (Windows/64) * Origin: Sector 7 | Mystic WHQ (1:129/215) .