• capturing tool output

    From Rampage@SESTAR to All on Thursday, January 03, 2019 13:44:43
    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
  • From Digital Man to Rampage on Thursday, January 03, 2019 12:07:57
    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
  • From Rampage@SESTAR to Digital Man on Thursday, January 03, 2019 17:15:53
    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
  • From Rampage@SESTAR to Digital Man on Thursday, January 03, 2019 17:40:17
    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
  • From Digital Man to Rampage on Thursday, January 03, 2019 15:50:05
    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
  • From Nightfox@DIGDIST to Digital Man on Thursday, January 03, 2019 17:15:28
    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

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Digital Man to Nightfox on Thursday, January 03, 2019 18:42:09
    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
  • From Rampage@SESTAR to Digital Man on Thursday, January 03, 2019 23:07:48
    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
  • From Nightfox@DIGDIST to Digital Man on Friday, January 04, 2019 09:35:49
    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

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Rampage@SESTAR to Digital Man on Friday, January 04, 2019 16:11:29
    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
  • From Nightfox@DIGDIST to Rampage on Friday, January 04, 2019 15:32:16
    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

    ---
    ■ Synchronet ■ Digital Distortion: digitaldistortionbbs.com
  • From Rampage@SESTAR to Nightfox on Saturday, January 05, 2019 09:40:53
    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
  • From Rampage@SESTAR to Digital Man on Sunday, January 06, 2019 00:53:32
    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
  • From Digital Man to Rampage on Sunday, January 06, 2019 00:42:17
    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
  • From Rampage@SESTAR to Digital Man on Sunday, January 06, 2019 10:11:39
    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
  • From Rampage@SESTAR to Digital Man on Sunday, January 06, 2019 17:46:08
    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
  • From Digital Man to Rampage on Sunday, January 06, 2019 15:50:15
    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
  • From Digital Man to Rampage on Sunday, January 06, 2019 15:52:09
    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
  • From Rampage@SESTAR to Digital Man on Sunday, January 06, 2019 21:41:29
    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