how can i capture the output of a tool like addfiles when it is executed from a javascript via the event subsystem?
we can see the output when we run the javascript via jsexec and it runs fine from there... we get a return value of 0 (zero)... if it is run from an event, though, the addfiles execution return value is 1 (one) and we cannot see the output of addfiles so we can see what the problem is that is causing it to fail...
we are running at LogLevel=Debugging... is there a more detailed level that would show us that output?
how can i capture the output of a tool like addfiles when it is
executed from a javascript via the event subsystem?
On *nix-like systems, you can use system.popen() to execute a
command-line and capture its output.
we can see the output when we run the javascript via jsexec and
it runs fine from there... we get a return value of 0 (zero)...
if it is run from an event, though, the addfiles execution return
value is 1 (one) and we cannot see the output of addfiles so we
can see what the problem is that is causing it to fail...
You could also add ">somefile" to the end of the command-line to redirect the output to a file to be read/reviewed later.
we are running at LogLevel=Debugging... is there a more detailed
level that would show us that output?
No.
You could also add ">somefile" to the end of the command-line
to redirect the output to a file to be read/reviewed later.
You could also add ">somefile" to the end of the command-line
to redirect the output to a file to be read/reviewed later.
this is what i'm going to try now... do you know if it will also capture stderr in addition to stdout? or do i need to do it something like
blahblah >>addfiles.log 2>&1
?? and will that work on winwhatever like it does on linux?
I don't think the "2>&1" construct works on Windows.
Re: Re: capturing tool output
By: Digital Man to Rampage on Thu Jan 03 2019 03:50 pm
I don't think the "2>&1" construct works on Windows.
I've done 2>&1 in Windows, and it works for redirecting stderr to stdout.
This is a Microsoft support page, showing it's officially supported: https:/ /support.microsoft.com/en-us/help/110930/redirecting-error-messages-from -command-prompt-stderr-stdout
blahblah >>addfiles.log 2>&1
?? and will that work on winwhatever like it does on linux?
https://support.microsoft.com/en-us/help/110930/redirecting-error -messages-from -command-prompt-stderr-stdout
I don't think the "2>&1" construct works on Windows.
This is a Microsoft support page, showing it's officially supported:
https:/
/support.microsoft.com/en-us/help/110930/redirecting-error-messages-fr
om
-command-prompt-stderr-stdout
That's the same page I quoted in my message! Funny, I just didn't read it all the way to bottom.
actually, that page shows it at the bottom of the examples... the
only thing that i might need is to add a 1 on the first
redirection... maybe not, though, since by default, 1 (aka stdout)
is redirected in that format...
blahblah 1>>addfiles.log 2>&1
we'll find out once my tester gets back to me if it worked in their situation...
blahblah 1>>addfiles.log 2>&1
i actually first tried it without the "1" (one) in front of the first redirection symbols... that did not work... so we've now added the first "1" (one) so the line looks like above and we're trying again...
i actually first tried it without the "1" (one) in front of the
first redirection symbols... that did not work... so we've now
added the first "1" (one) so the line looks like above and
we're trying again...
Interesting.. I'd expect it to work without the 1, since that's the default.
I wonder if it makes a difference whether you're using 2
redirection symbols (>>), which would append if the file exists, or just one, which would always create a new file.
blahblah 1>>addfiles.log 2>&1
we'll find out once my tester gets back to me if it worked in their situation...
The issue is happening with anything being TIC'd to me, all areas,----- snip -----
all files.
Here's the log line from a failed run:
1/5 10:57:38a TICKIT Executing: 'C:\sbbs\exec\addfiles nasa -zd +C:\sbbs\temp\event\tickit-files.bbs 24 13 1>>C:\sbbs\temp\event\addfiles.log 2>&1'.
There was no 'addfiles.log' in my \sbbs\temp\event\ directory, so I think there's still something not right with that redirect/append syntax...
blahblah 1>>addfiles.log 2>&1
we'll find out once my tester gets back to me if it worked in their situation...
sadly, this didn't work, either :(
----- snip -----
The issue is happening with anything being TIC'd to me, all areas,
all files.
Here's the log line from a failed run:
1/5 10:57:38a TICKIT Executing: 'C:\sbbs\exec\addfiles nasa -zd +C:\sbbs\temp\event\tickit-files.bbs 24 13 1>>C:\sbbs\temp\event\addfiles.log 2>&1'.
There was no 'addfiles.log' in my \sbbs\temp\event\ directory, so I think there's still something not right with that redirect/append syntax...----- snip -----
i don't understand why it isn't working...
i don't understand why it isn't working...
The temp directory is cleared out often, so perhaps you should
create the addfiles.log somewhere else.
The temp directory is cleared out often, so perhaps you should
create the addfiles.log somewhere else.
Okay... so about a half hour ago I got a deadbeef, it failed as
usual, but this time there *IS* an addfiles.log in my \sbbs\data
directory!
Here's the content of that log:
SBBSCTRL environment variable not set.
Example: SET SBBSCTRL=/sbbs/ctrl
ADDFILES v3.03-Win32 (rev 1.54) - Adds Files to Synchronet Filebase
Now.... I do in fact have that env variable set, just went and double
checked it. It's weird how you set it in Windoze, but google told me
how and I've had it there all along, since first installing the BBS. Confirmed with a "set" command in a terminal window and it shows: SBBSCTRL=C:\sbbs\ctrl
Strange...
i don't understand why it isn't working...
The temp directory is cleared out often, so perhaps you should
create the addfiles.log somewhere else.
i'll give that a try, i guess... maybe data/logs is a better place? gotta see if i can find the system.blah variable that holds that information...
The temp directory is cleared out often, so perhaps you should
create the addfiles.log somewhere else.
that was it! now we have a log and guess what they've been fighting all along?
Okay... so about a half hour ago I got a deadbeef, it failed as
usual, but this time there *IS* an addfiles.log in my \sbbs\data directory!
Here's the content of that log:
SBBSCTRL environment variable not set.
Example: SET SBBSCTRL=/sbbs/ctrl
ADDFILES v3.03-Win32 (rev 1.54) - Adds Files to Synchronet Filebase
Now.... I do in fact have that env variable set, just went and double checked it. It's weird how you set it in Windoze, but google told me
how and I've had it there all along, since first installing the BBS. Confirmed with a "set" command in a terminal window and it shows: SBBSCTRL=C:\sbbs\ctrl
Strange...
i don't know how they are running their installation on their windows... i'd probably be kicking if off from a BAT file and put the necessary SET statements in there... i don't know if they are running it from a command prompt or as a service or what... i don't do windows anymore so i'm in the dark on where/how they need to set this...
That's covered in detail here: http://wiki.synchro.net/config:env
| Sysop: | Kurt Hamm |
|---|---|
| Location: | Columbia, SC |
| Users: | 7 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 92:15:26 |
| Calls: | 2,837 |
| Calls today: | 2 |
| Files: | 64 |
| Messages: | 856,638 |