Subj : Re: XP's "more.com" skips first lines of output -- need a replacement To : All From : V@nguard.LH Date : Mon Jan 14 2019 04:14 pm 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) .