Path:
eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!n
ewsfeed0.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!n
ot-for-mail
From: VanguardLH
Newsgroups: microsoft.public.windowsxp.help_and_support
Subject: Re: XP's "more.com" skips first lines of output -- need a replacement
Date: Thu, 14 Jan 2016 15:14:54 -0600
Organization: Usenet Elder
Lines: 136
Sender: VanguardLH <>
Message-ID:
References: <56977375$0$23733$e4fe514c@news.xs4all.nl>
<5697bc51$0$23855$e4fe514c@news.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: individual.net Fcc4hjma6UU6Copd48OOLgpQcq8t6510pXPdxoj+L0NC7wIVhM
Keywords: VanguardLH VLH811
Cancel-Lock: sha1:akXqjNueT9PX3a8zwyk52i5yYsA=
User-Agent: 40tude_Dialog/2.0.15.41
Xref: mx02.eternal-september.org
microsoft.public.windowsxp.help_and_support:31807
R.Wieser wrote on 2016/01/14:
> JJ,
>
>> Mine works fine. XP SP3, MORE.COM version 5.1.2600.5512.
>
> Same version here. And it bugs repeatedly.
>
>> Some console programs output text to the error handle in
>> addition to the output handle.
>
> In that case I should be seeing a mixed-up, rather unreadable combination of
> both, which has not happened.
>
> Regards,
> Rudy Wieser
>
> -- Origional message:
> JJ schreef in berichtnieuws
> zblp881q6o0e.4jvsn3fuhykh$.dlg@40tude.net...
>> On Thu, 14 Jan 2016 11:10:04 +0100, R.Wieser wrote:
>>> Hello All,
>>>
>>> I've noticed that my XPsp3 has got a version of MORE.COM which, in
>>> circumstances, skips the first set/page of lines. That means I need a
>>> bug-fixed replacement. Does someone have it for me ?
>>>
>>> And outof curiosity, has anyone else noticed the same ?
>>>
>>> Regards,
>>> Rudy Wieser
>>
>> Mine works fine. XP SP3, MORE.COM version 5.1.2600.5512.
>>
>> Some console programs output text to the error handle in addition to the
>> output handle. MORE.COM only captures the output handle. One example of
> this
>> program is ffmpeg.
No. Console output (stdout) is a separate stream from error output
(stderr). Normal redirection (program > file) only includes stdout.
There won't be any stderr content in the target file. To get stderr
redirected into a file, you use "2>" (program 2> file).
program > file
program 1> file
Only stdout goes into file.
program 2> file
Only stderr goes into file.
program 1> fileA 2> fileB
program > fileA 2> fileB
Stdout is redirected into fileA.
Stderr is redirected into fileB.
program 1> file 2>&1
program > file 2>&1
Stdout goes to file.
Stderr also goes to the same file.
&1 is the placeholder variable representing command line argument number
1 (which is the file). &0 is arg0 (program), &1 is arg1 (first arg to
program), &2 is arg2, and so on. Redirection operators are not
arguments. However, I've also seen "2>&1" described as "stream2
redirected to stream 1 (so stream 1 must already exist)". There must
NOT be a space between the redirection character (>) and the argument
placeholder (&1).
The redirection operation for stderr (2>) *must* follow the one for
stdout (> or 1>). "prog 2> err.txt 1> ok.txt" and "prog 2>&1 > file"
are invalid.
Only in this case would you get a mix of stdout and stderr in the same
file. Likely you are defaulting to just specifying stdout so that is
all that gets redirected to the file.
If a program, for example, outputted both non-blank stdout and stderr
streams and you wanted to ensure to squelch all output:
program > nul
Only squelches stdout.
Error messages (stderr) still go to the screen.
program > nul 2> nul
program > nul 2>&1
Squelches both stdout and stderr.
Nul is not an actual file so there is no conflict on trying to write
multiple streams into it.
program 1> file 2> file
program > file 2> file
Results in a "file inuse" error. Rather than redirect 2 streams
concurrently into the file, you are trying to first write into the file
and then write into it again but the file handle is still open from the
first write operation. > is an overwrite operation: if the file does
not exist then it is created and do the write, if the file does exist
then overwrite it. The stdout redirect is still open so you are not
allowed to write on an already open file for stderr.
I have not tried the 1 (stdout) and 2 (stderr) prefixes on redirects
that append (i.e., using >> to append output into an existing file).
For example:
programA > file
programB > file
file gets overwritten with programB's stdout. Nothing of programA's
stdout remains in file.
versus
program > file
programA >> file
file has stdout from programA followed by stdout from programB.
To capture stderr along with stdout into the same file, I suspect you
could use:
program > file 2>>&1
Overwrite stdout to file, append stderr to file.
program >> file 2>>&1
Append stdout to existing file (or create file), append stderr to file.
However, it seems unnecessary to append stderr since:
program > file 2>&1
and
program > file 2>>&1
do the same thing.
The stream identifiers of 1> or > for stdout and 2> for stderr are for
when redirecting them to the specified target (after the > character).
I'd have to research to find out if stream identifiers are applicable
when piping (using the | character); i.e., where programB has a stdin
stream that will accept stdout or stderr streams from programA.
--- Platinum Xpress/Win/WINServer v3.1
* Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
|
