It looks like it's not checking for console.aborted in the correct place. I've tried putting a check for console.aborted in ddfilelister toward the beginning and exiting if it's true, but it seems to think console.aborted is always false:
if (user.is_sysop) console.print("console.aborted: " + console.aborted + "\r\n");if (console.aborted) exit(0);
I'm not entirely sure if that's the correct thing to do if console.aborted is true. Also, I'm curious what conditions make console.aborted true?
console.aborted is set to true when a user hits Ctrl-C while console.abortable is true and the control-key passthrough bit map (console.ctrlkey_passthru) does not have bit 3 (for Ctrl-C) set.
There are other factors (e.g. Telnet binary mode, Telnet gateway mode) that can cause SBBS to just pass-through the Ctrl-Key (not set the console.aborted flag), but those are probably not a factor here.
Thanks for the info.
If console.abortable is true and the passthrough doesn't have Ctrl-C, should ddfilelister get a keypress at startup and see if the user pressed Ctrl-C and set console.aborted to true? I tried doing the following when ddfilelister starts up, but it didn't seem to be much help - Although console.aborted is set to true, Synchronet continued to do the file scan through the rest of the file directories. I'm still not sure if the code below is what ddfilelister should be doing to enable aborting the file scan:
if (console.abortable && (console.ctrlkey_passthru & (1<<3)) == 0){ var userKey = console.inkey(K_NOECHO|K_NOSPIN|K_NOCRLF, 100); if (userKey == CTRL_C) console.aborted = true;}if (user.is_sysop) console.print("console.aborted: " + console.aborted + "\r\n"); // For debuggingif (console.aborted) exit(0);
No, you should never have to set console.aborted to true yourself or check specifically for CTRL_C. In fact, I wouldn't expect this code to actually do anything (console.inkey() will never return CTRL_C unless you have Ctrl-C in the control-key pass-through bitmap. Did you test this (e.g. add a debug log message in the if(userKey == CTRL_C) condition)? I wouldn't expect it to do anything.
So the built-in scan dirs logic will call your list files mod for each directory included in the search scope and check the aborted flag between each directory. So, if your script is only a list files script (you're not using a custom scan dirs module), then I would expect a Ctrl-C to at least (at minimum) abort the scan between consecutive directories searched. This would not require anything special done in the custom list files mod (other than to not clear the aborted status at any point).
If you're wanting a search of each/single directory to be immediately abortable via Ctrl-C, then any loops in your list files mod will need to check for console.aborted and cancel their operations when it's true.
ddfilelister indeed does not clear the aborted status. If it also should never have to set console.aborted to true, then I feel like I'm at a bit of a loss. I don't know why Ctrl-C doesn't abort the file scan when ddfilelister is being used.
In this case, ddfilelister will search just the directory with the given sub-board code each time it runs.
I've tried different scopes, and it has the same behavior (ctrl-C doesn't stop the scan).
I've printed the value of console.aborted just before my script terminates, and it looks like sometimes it's true but most of the time it's false. In each case, I'm pressing ctrl-C multiple times while the scan is running, and the scan continues until it has searched all directories for the scope I chose.
@rswindell I'm at a loss on this. I don't know what ddfilelister would need to do (that it's not currently doing) to allow Ctrl-C to abort a file search.
Recently, I remember nelgin saying he seemed to be able to stop it on his BBS after pressing Ctrl-C several times. It seems it doesn't stop on my BBS. I made a debug version of ddfilelister to output ctrlkey_passthru, and it's showing it's 0 for both of our BBSes. Also, we've tried having ddfilelister output the value of console.aborted, and it seems even when console.aborted is true, the file search continues
So with NightFox's DD utils/mods running I can't control-C out of the searching routine using any of the terminal emulator that allow me to control-c out of a stock search on vert.
There are no files in Local Files - Text Filesconsole aborted: false[press a key] - ctrl-c pressed hereconsole aborted: truelet's get outta here[ Scanning 0.4% ]There are no files in Local Files - Communications Programsconsole aborted: false[press a key] - ctrl-c pressed hereconsole aborted: truelet's get outta here
So even though it hits an exit, the scan continues.
I think this change from 7 years ago might be the reason:
c22063f9
I'm not sure reverting that change is a good idea. Maybe?
If your script returns -1 (e.g. exit(-1)) that should stop the scan, so you could do that conditionally based on if console.aborted === true or not (return 0 for normal/continue).
That seems to help. It looks like I have to press Ctrl-C a few times for it to detect that console.aborted is true, but the file search does stop early.