Rerouting CMD window messages

[Graham Hobbs]

Hello,

Am Windows XP2. I have a CJP2.CMD file with many steps such that it
scrolls well beyond the scrolling limit of my physical CMD window.

So I can read everything at leisure I issue cjp2 > aaresult.txt but
this delivers little to the txt file, most remaining on my CMD window.

How do I get such as the following into the TXT file so I can see
EVERYTHING in one place?

e.g. many msgs such as ..
The handle is invalid.
Could Not Find C:\CRDUSR\GJH.QKDB\the*.*
ERZ005013I/0702: Physical map generated to 'QKDBS01.map'.
ERZ005014I/0601: Logical map generated to 'QKDBS01'.
The system cannot find the file specified.

Please, thanks
Graham Hobbs

[Tom Lavedas]

Those are error messages sent to the "StdErr" interface. The normal output goes to the "StdOut" interface. Since NT, these two interfaces have been representated at the command line using their respective "pipe" numbers: 1 for StdOut and 2 for StdErr. (StdIn is also defined as zero, but that is of almost no consequence - I've never seen a need for it.) So, in your case, you can do something like this ...

cjp2 > aaresult.txt 2>&1

The initial redirection goes to StdOut by default, or you can explicitely add the 1. The second redirection of StdErr (2) is sent to the same place as StdOut with the &1 construct.
_______________________________
Tom Lavedas

[billious]

On 24/08/2012 03:35, Tom Lavedas wrote:
>
> Please, thanks Graham Hobbs
>
> Those are error messages sent to the "StdErr" interface. The normal output goes to the "StdOut" interface. Since NT, these two interfaces have been representated at the command line using their respective "pipe" numbers: 1 for StdOut and 2 for StdErr. (StdIn is also defined as zero, but that is of almost no consequence - I've never seen a need for it.) So, in your case, you can do something like this ...
>
> cjp2 > aaresult.txt 2>&1
>
> The initial redirection goes to StdOut by default, or you can explicitely add the 1. The second redirection of StdErr (2) is sent to the same place as StdOut with the &1 construct.
> _______________________________
> Tom Lavedas
>

Certainly - but here's a quirk:

cjp2 > aaresult.txt 2>&1

will redirect as expected

cjp2 2>&1 > aaresult.txt

will not redirect STDERR(W7)

[foxidrive]

In hindsight that seems logical. The STDOUT redirection needs to be setup before 2>&1 being specified.


In the second case, when reading in command sequence from left to right, STDOUT is going to the console so using 2>&1 will redirect STDERR to the console too. After that STDOUT is redirected to a file but STDERR is still going where it has been told.



--
Mic

[billious]

Sounds reasonable. Left-to-right evaluation assigning the redirected
device to the current assignment of the target.

So... what should

cjp2 > aaresult.txt 2>&1 >bbresult.txt

do? Not that it's really logical, but just for the sake of interest?

(STDOUT to bbresult.txt; STDERR to console...)

[Graham Hobbs]

On Thu, 23 Aug 2012 14:25:55 -0400, Graham Hobbs <gho...@cdpwise.net>
wrote:

---
I ran as follows:
C:\CRDUSR\GJH.QKDB>cjp2 > aaa2.txt 2>&1
C:\CRDUSR\GJH.QKDB>

.. and got
I: cjp2.rex started OK
I: ------------------------------------------------------------------
Z: parminst loaded=312
Z: zzparmuser loaded=292
copy zzreadme c:\crdusr\W_QKDB001
copy zzparmuser c:\crdusr\W_QKDB002
copy DCLGQKDB c:\crdusr\W_QKDB003
del *?.* 2>nul
copy c:\crdusr\W_QKDB001 ZZREADME
copy c:\crdusr\W_QKDB002 ZZPARMUSER
copy c:\crdusr\W_QKDB003 DCLGQKDB
del c:\crdusr\W_QKDB*?.* 2>nul
cjp2.rex will next sub ZZJOB2.CMD=call ZZJOB2 QKDB DCLGQKDB
/VENDOR-IBM
End of REXX cjp2
I: **********************
I: This was an executable run
I: cjp2.rex ended OK
I: **********************

.. but problems were:
a) none of the steps in the CMD executed
b) it ran in 1 second flat wheras job is usually 2 minutes
b) likely why am missing > 2000 expected lines

.. then tried billious's:
C:\CRDUSR\GJH.QKDB>cjp2 2>&1 > aaa5.txt

.. this gave me exactly the same txt file output (as above) although
the job did run its two minutes
??
Graham

[Graham Hobbs]

--
.. i ran ..

C:\CRDUSR\GJH.QKDB>cjp2 > aaresult.txt 2>&1 > aaaresult.txt

.. pretty much the same .. job ran, most stuff still appearing on
screen, exactly same lonely stuff in aaaresult

Is it possible that there is no solution?

graham
.. ps have gone to bed, no more till tomorrow

[foxidrive]

It is likely that some other issue caused the job to fail earlier.

Try it again.


--
Mic

[billious]

I think we should try putting the lid back on this particular can of
worms before it's too late.

The syntax

batchfile >reportfile 2>&1

as Tom originally proposed /should/ work AND, as Tom also said,

batchfile 1>reportfile 2>&1

should yield identical results.

What I was pointing out was that

batchfile 2>&1 >reportfile
or
batchfile 2>&1 1>reportfile

would NOT yield the same results; the "2>&1" would appear to be ignored.

This violates the accepted principle that the order of switches is
irrelevant (and true, this is redirection, not switches - but it is data
delivered to the SHELL itself for control of the job rather than the
process to be controlled.)

The

batchfile >reportfile 2>&1 >anotherfile

syntax is simply a discussion point. Personally, I'd have produced an
error because it is ambiguous as to the destination of the redirection.

===============

In the case of OP's problem, I'd say

batchfile >reportfile 2>errorfile
which should be equivalent to
batchfile 1>reportfile 2>errorfile

will show which report lines are sent to which device and that any OTHER
report lines appearing would be being sent by the process to CON: rather
than STDOUT or STDERR; hence they may be difficult or impossible to capture.

================

On the subject of output to CON: - ISTR some utilities bypass
STDOUT/STDERR as I've outlined - but their identities escape me. There
are also MS-supplied utilities that produce the sequence

[spaces]text[CR]text[CR][LF]

where the second text overwrites the leading spaces - but FOR/F uses
[CR] as the line-terminator...

Which is getting off the subject a little.

Has anybody noticed the warning/suggestion about speed that occasionally
appears when a big file is used as SORT input in a

SORT <bigfile >newfile

command? I've seen no pattern - repeating PRECISELY the same command
does not necessarily produce the message. I've an idea that that message
(unless it's a figment of my imagination) is sent to CON:

===========================

And for the sake of demonstrating the flakiness of the
redirection-sequence-sensitivity that triggered this part of the
discussion, try this quick quiz:

@ECHO OFF
DIR \idontexist
DIR \idontexist >u:\1-1.txt
DIR \idontexist >u:\2-1.txt 2>2-2.txt
DIR \idontexist 2>3-2.txt
DIR \idontexist 1>u:\4-1.txt
DIR \idontexist 1>u:\5-1.txt 2>5-2.txt
DIR \idontexist 2>6-2.txt >u:\6-1.txt
DIR \idontexist 2>u:\7-2.txt 1>7-1.txt


And here's the result:

Volume in drive U has no label.
Volume Serial Number is 0422-0000

Directory of u:\

24/08/2012 16:32 93 1-1.txt
24/08/2012 16:32 93 2-1.txt
24/08/2012 16:32 93 4-1.txt
24/08/2012 16:32 93 5-1.txt
24/08/2012 16:32 93 6-1.txt
24/08/2012 16:32 16 7-2.txt
6 File(s) 481 bytes
0 Dir(s) 2,114,617,344 bytes free

?-1.txt are all identical.

How come 7-2.txt is created but 5-2.txt isn't?
(7-2.txt contains

File not found

)

====================

Be thankful I stopped the investigation there. It was going to be the
first step to investigating all of the sequence combinations of

>file.txt
1>file1.txt
2>file2.txt
1>&2
2>&1

...

[Herbert Kleebauer]

On 23.08.2012 20:25, Graham Hobbs wrote:
> Hello,
>
> Am Windows XP2. I have a CJP2.CMD file with many steps such that it
> scrolls well beyond the scrolling limit of my physical CMD window.

Increase the buffer size of the CMD window, then you can scroll back.

[Graham Hobbs]

On Fri, 24 Aug 2012 13:30:43 +0200, Herbert Kleebauer <kl...@unibwm.de>
wrote:

---
Herbert,

This actually solves most of my problem. I wanted to examine all of
the output from my cjp2 job but only from time to time during
extensive testing to eyeball if any oddities were present.

This almost does it .. right click top left of a CMD window and do
'Properties'. Still haven't got all the output in one shot (two shots
so far but judiciously placed 'pause' does the trick) but will work on
that.

While the rerouting would have been a cleaner solution, the above is
much simpler than working on intracies of DOS syntax, a subject of
great mystery to me.

Again, to all, my thanks for pushing me in a solution direction.
Graham