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: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 31 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 00:13:25 |
| Calls: | 2,091 |
| Calls today: | 2 |
| Files: | 11,141 |
| Messages: | 949,127 |