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?

thanks!

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

Re: capturing tool output
By: Rampage to All on Thu Jan 03 2019 01:44 pm

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.

digital man

Synchronet/BBS Terminology Definition #15:
CVS = Concurrent Versioning System
Norco, CA WX: 65.0°F, 21.0% humidity, 1 mph W wind, 0.00 inches rain/24hrs

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

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.

hummm... the problematic system is running winwhatever...

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.

ahh! i'll give that a try...

we are running at LogLevel=Debugging... is there a more detailed
level that would show us that output?

No.

thanks!

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

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?

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

Re: Re: capturing tool output
By: Rampage to Digital Man on Thu Jan 03 2019 05:40 pm

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?

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.

digital man

Synchronet "Real Fact" #75:
Rob's alias "digital man" was inspired by a song on Rush's 1982 "Signals" album.
Norco, CA WX: 66.4°F, 19.0% humidity, 2 mph WSW wind, 0.00 inches rain/24hrs

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

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

Nightfox

Re: Re: capturing tool output
By: Nightfox to Digital Man on Thu Jan 03 2019 05:15 pm

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

That's the same page I quoted in my message! Funny, I just didn't read it all the way to bottom.

digital man

Synchronet "Real Fact" #24:
1584 Synchronet BBS Software registrations were sold between 1992 and 1996. Norco, CA WX: 56.4°F, 27.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Re: capturing tool output
By: Digital Man to Rampage on Thu Jan 03 2019 15:50:05

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.

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...

thanks for the pointer :)


)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

Re: Re: capturing tool output
By: Digital Man to Nightfox on Thu Jan 03 2019 06:42 pm

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.

I should have read your message more carefully to see you had quoted the same page. :P

Nightfox

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...

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...

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

Re: Re: capturing tool output
By: Rampage to Digital Man on Fri Jan 04 2019 04:11 pm

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...

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.

Nightfox

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.

that's what we thought, too...

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.

it shouldn't matter but winwhatever is... umm... winwhatever... we need the append, though, because the next execution run could be good which would overwrite the recorded error we're trying to hunt down...

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

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...

so just to clarify, when run from an event, tickit.js executes addfiles and addfiles fails for some unknown reason... the redirection code was added to try to capture the addfiles output so we could see the failure but it is not captured either...

if the above command line is copied and pasted to the terminal command prompt OR if tickit.js is run from jsexec, then addfiles runs properly and the file is imported into the file base...

the only difference we can see is that the temp directory is different between the two methods of execution but that should not matter...

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

Re: Re: capturing tool output
By: Rampage to Digital Man on Sun Jan 06 2019 12:53 am

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...

The temp directory is cleared out often, so perhaps you should create the addfiles.log somewhere else.

digital man

Synchronet/BBS Terminology Definition #63:
SyncTERM = The Synchronet Terminal Emulator/BBS-client program
Norco, CA WX: 46.4°F, 93.0% humidity, 0 mph SSW wind, 0.21 inches rain/24hrs

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

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...

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

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...

)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR

Re: Re: capturing tool output
By: Rampage to Digital Man on Sun Jan 06 2019 10:11 am

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...

system.logs_dir

digital man

Synchronet "Real Fact" #1:
Development began in 1990 of the (unnamed at the time) Synchronet BBS software. Norco, CA WX: 56.8°F, 60.0% humidity, 2 mph NNW wind, 0.21 inches rain/24hrs

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Re: capturing tool output
By: Rampage to Digital Man on Sun Jan 06 2019 05:46 pm

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

digital man

This Is Spinal Tap quote #5:
Nigel Tufnel: Authorities said... best leave it... unsolved.
Norco, CA WX: 56.8°F, 60.0% humidity, 2 mph NNW wind, 0.21 inches rain/24hrs

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Re: capturing tool output
By: Digital Man to Rampage on Sun Jan 06 2019 15:52:09

That's covered in detail here: http://wiki.synchro.net/config:env

i've pointed them to that link... thanks!


)\/(ark

---
■ Synchronet ■ SouthEast Star Mail HUB - SESTAR