A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » Windows XP Help and Support
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

XP's "more.com" skips first lines of output -- need a replacement



 
 
Thread Tools Display Modes
  #1  
Old January 14th 16, 10:10 AM posted to microsoft.public.windowsxp.help_and_support
R.Wieser
external usenet poster
 
Posts: 603
Default XP's "more.com" skips first lines of output -- need a replacement

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


Ads
  #2  
Old January 14th 16, 02:39 PM posted to microsoft.public.windowsxp.help_and_support
JJ[_11_]
external usenet poster
 
Posts: 572
Default XP's "more.com" skips first lines of output -- need a replacement

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.
  #3  
Old January 14th 16, 03:20 PM posted to microsoft.public.windowsxp.help_and_support
R.Wieser
external usenet poster
 
Posts: 603
Default XP's "more.com" skips first lines of output -- need a replacement

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
...
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.





  #4  
Old January 14th 16, 08:36 PM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 9,415
Default XP's "more.com" skips first lines of output -- need a replacement

R.Wieser wrote on 2016/01/14:

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 ?


In what path (folder) is the more.com that you call? If you are using
the PATH environment variable to specify executable paths, perhaps you
are using a more.com other than what came with Windows. XP, and later,
also use the registry to specify appPaths. Used regedit to look at:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\App Paths

Each subkey is the name of the executable and a data value tells where
to find the executable. more.com should be under %windir%\System32 and
that should already be specified in the PATH environment variable, so
there should not be a registry AppPath for it; however, the rules for
executable search is to use the current folder first, so if you have a
more.com there then that one gets used.

You sure the file contains only *printable* TEXT characters? No
printing or control (hidden) characters?

Are you using the command-line to more.com to specify the file? Or are
you piping or redirecting the output of another console-mode command
(output goes to stdout) into the more.com program (e.g., program |
more)? If you are specifying the file(s) as an argument to the more
program then it should have only printable ASCII8 characters. If you
are piping the output of a program into more.com, the program may issue
output to stdout and stderr. The standard piping only redirects stdout.
Standard redirection () only redirects stdout. For stderr, you have to
use "2", as in "program 2 stderr.txt". You didn't say HOW you are
using more.com so I don't know if you are piping stdout into it or
redirecting its output to a file or what.

more.com is designed to paginate the output. Do you really need it
paginated? If you redirect stdout to a file then pagination means you
might not get all of the file redirected into another file.

Have you tried using "type" command (internal command inside of cmd.com)
if pagination is not needed?

Does the file look okay when you load it into Notepad? Does it look
okay when you run "type file otherfile & notepad otherfile"?

I haven't been on Windows XP for a few years but I don't remember
encountering what you describe back when I used Windows XP (unless there
were non-printable control or print characters within the file). You
aren't using the +n command-line argument that says to skip n lines in
the file, are you?

What is the command line you enter? You can pipe into more.com. You
can redirect into more.com. You can redirect out of more.com. more.com
has command-line arguments. Just saying "more.com" doesn't tell us HOW
you are using it.
  #5  
Old January 14th 16, 09:14 PM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 9,415
Default XP's "more.com" skips first lines of output -- need a replacement

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
...
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.
  #6  
Old January 14th 16, 09:18 PM posted to microsoft.public.windowsxp.help_and_support
R.Wieser
external usenet poster
 
Posts: 603
Default XP's "more.com" skips first lines of output -- a bigger problem

JJ, VanguardLH,

I've noticed that my XPsp3 has got a version of MORE.COM
which, in circumstances, skips the first set/page of lines.


I threw together a small program emulating a basic MORE program, and noticed
it failed pretty-much the same way.

Either my OS has got problems or, more likely, there something wrong with my
video card and/or driver ... I've already tried to disable hardware
accelleration, but that did not seem to help.

Oh well.

Regards,
Rudy Wieser


-- Origional message:
R.Wieser schreef in berichtnieuws
...
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




  #7  
Old January 14th 16, 09:50 PM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 9,415
Default XP's "more.com" skips first lines of output -- a bigger problem

R.Wieser wrote on 2016/01/14:

I threw together a small program emulating a basic MORE program, and noticed
it failed pretty-much the same way.

Either my OS has got problems or, more likely, there something wrong with my
video card and/or driver ... I've already tried to disable hardware
accelleration, but that did not seem to help.


Alas, we still don't know what you are doing. Skipping lines could be
at the head (start of stream), tail (end of stream), or within the
stream. We don't know if you are redirecting or piping a program's
output or using command-line args to more.com to specify a file.

I don't see how anything video card related would affect the content of
a stdout or stderr stream. Those don't even require video. Those are
data streams, not video streams. I don't even need a video card
connected to a monitor for more, type, Notepad, or any other program to
work correctly. Me not seeing it does not equate to the program not
producing expected results.

What are you running? What is the command? Are you running it in a
console (command shell, cmd.exe) so the console remains after the
program ends? Does "skipping" mean you don't see the lines on the
screen or that they are truncated in the console window? Does the
console's window have scrolling enabled? If so, does scrolling still
have the missing lines? is the console's window partially offscreen?

Have you yet tried booting into Windows' safe mode to make sure
something you load on startup and login are not affecting however you
are trying to view output from more.com?

Have you tried "more.com file otherfile & notepad otherfile" to see if
all the lines are there when viewing the stdout stream in Notepad
(instead of on the screen within the console window)?
  #8  
Old January 15th 16, 06:23 AM posted to microsoft.public.windowsxp.help_and_support
JJ[_11_]
external usenet poster
 
Posts: 572
Default XP's "more.com" skips first lines of output -- a bigger problem

On Thu, 14 Jan 2016 22:18:59 +0100, R.Wieser wrote:

I threw together a small program emulating a basic MORE program, and noticed
it failed pretty-much the same way.

Either my OS has got problems or, more likely, there something wrong with my
video card and/or driver ... I've already tried to disable hardware
accelleration, but that did not seem to help.

Oh well.


The skipped line might actually be a single long line which is broken into
two lines because it's longer than the number of console buffer columns.
  #9  
Old January 15th 16, 09:27 AM posted to microsoft.public.windowsxp.help_and_support
R.Wieser
external usenet poster
 
Posts: 603
Default XP's "more.com" skips first lines of output -- a bigger problem

JJ,

The skipped line might actually be a single long line which is broken into
two lines because it's longer than the number of console buffer columns.


When I look at the contents of the file I redirected the output to all I see
are short lines. Also, my own version of the program stops reading after
80 chars and calls it a line (so I can count 24 displayed lines and than
wait for a keypress).

Also, XPs MORE.COM allows you to advance a single line by pressing SPACE.
The problem remains the same.

But I realized something: I said "skipped", but did not describe *how* it
was skipped (didn't think it was neccessary when I asked for a replacement).
The funny thing is that sometimes it actually skips the lines with nothing
on the screen indicating it hapopened, but sometimes it just scrolls the
screen up (as if only a CRLF is printed), line-by-line. Also, the /C
(clear screen before displaying output) didn't work when I tried it.

Regards,
Rudy Wieser


-- Origional message:
JJ schreef in berichtnieuws
...
On Thu, 14 Jan 2016 22:18:59 +0100, R.Wieser wrote:

I threw together a small program emulating a basic MORE program, and

noticed
it failed pretty-much the same way.

Either my OS has got problems or, more likely, there something wrong

with my
video card and/or driver ... I've already tried to disable hardware
accelleration, but that did not seem to help.

Oh well.


The skipped line might actually be a single long line which is broken into
two lines because it's longer than the number of console buffer columns.



  #10  
Old January 15th 16, 10:13 AM posted to microsoft.public.windowsxp.help_and_support
R.Wieser
external usenet poster
 
Posts: 603
Default XP's "more.com" skips first lines of output -- a bigger problem

VanguardLH,

Skipping lines could be at the head (start of stream), tail
(end of stream), or within the stream.


As far as I can tell they are always skipped from the start of the stream.
Sometimes with no effect on the screen, sometimes I see the screen being
scrolled up.

We don't know if you are redirecting or piping a program's
output or using command-line args to more.com to specify
a file.


I'm piping the output of another command into it. No arguments.

I don't see how anything video card related would affect
the content of a stdout or stderr stream.


Why would you think it does or should do ? All I see is that output
directed at the screen disappears, sometimes without a trace. Mind you,
when I redirect the output to a file instead of to the screen I see all the
data I expect.

Are you running it in a console (command shell, cmd.exe)
so the console remains after the program ends?


Yes.

Does "skipping" mean you don't see the lines on the screen or
that they are truncated in the console window?


See above. Sometimes I see nothing, sometimes I just see the screen
scrolling up or the cursor moving down.

And by the way, pressing "=" to show the line number displays, AFAIK, the
correct one, 24.

Does the console's window have scrolling enabled?


No. I've used MODE CON to set an old-school 80x25 screen.

Have you tried "more.com file otherfile


No, but I just have (good catch btw). A filecompare with an earlier
outputted file (no MORE, directly to file) shows no differences.


Hmmm... odd ....

I saw you asking about what commandline I ran, and skipped answering it
because the piping should isolate the two programs from each other (using an
intermediate file).

Nevertheless, I seldom let such questions go without trying to make sure I'm
right. So, I also ran the command "... bla & more bla". That worked
every time I tried it. Which, I might say, is quite unexpected. What is
going on here ?

I could point fingers at the specific program sourcing the piped text, but
I'm a lot more interrested in knowing what causes MORE's behaviour, and how
I can fix it (instead of compiling a list of programs I should not use in
combination with it).

Regards,
Rudy Wieser



-- Origional message:
VanguardLH schreef in berichtnieuws
...
R.Wieser wrote on 2016/01/14:

I threw together a small program emulating a basic MORE program, and

noticed
it failed pretty-much the same way.

Either my OS has got problems or, more likely, there something wrong

with my
video card and/or driver ... I've already tried to disable hardware
accelleration, but that did not seem to help.


Alas, we still don't know what you are doing. Skipping lines could be
at the head (start of stream), tail (end of stream), or within the
stream. We don't know if you are redirecting or piping a program's
output or using command-line args to more.com to specify a file.

I don't see how anything video card related would affect the content of
a stdout or stderr stream. Those don't even require video. Those are
data streams, not video streams. I don't even need a video card
connected to a monitor for more, type, Notepad, or any other program to
work correctly. Me not seeing it does not equate to the program not
producing expected results.

What are you running? What is the command? Are you running it in a
console (command shell, cmd.exe) so the console remains after the
program ends? Does "skipping" mean you don't see the lines on the
screen or that they are truncated in the console window? Does the
console's window have scrolling enabled? If so, does scrolling still
have the missing lines? is the console's window partially offscreen?

Have you yet tried booting into Windows' safe mode to make sure
something you load on startup and login are not affecting however you
are trying to view output from more.com?

Have you tried "more.com file otherfile & notepad otherfile" to see if
all the lines are there when viewing the stdout stream in Notepad
(instead of on the screen within the console window)?




  #11  
Old January 15th 16, 11:27 AM posted to microsoft.public.windowsxp.help_and_support
JJ[_11_]
external usenet poster
 
Posts: 572
Default XP's "more.com" skips first lines of output -- a bigger problem

On Fri, 15 Jan 2016 11:13:00 +0100, R.Wieser wrote:

I could point fingers at the specific program sourcing the piped text, but
I'm a lot more interrested in knowing what causes MORE's behaviour, and how
I can fix it (instead of compiling a list of programs I should not use in
combination with it).


Have you tried using the Unicode mode of CMD?
  #12  
Old January 15th 16, 11:57 AM posted to microsoft.public.windowsxp.help_and_support
R.Wieser
external usenet poster
 
Posts: 603
Default XP's "more.com" skips first lines of output -- a bigger problem

JJ,

Have you tried using the Unicode mode of CMD?


No, I haven't. I was not even aware that it's there ...

But, I think I've narrowed down on the cause: By replacing the text sourcing
program with something else the problem disappears. Also, that program is
legacy, traveled with me from my DOS times ... It appears to somehow
either interfere with the screen, or, as VanguardLH suggested, with the
stream outputted by the MORE program (gobbling-up its stdout stream as long
as it runs ?).

In short, its appears not to be either the "more" program nor the display
driver, but just a legacy program being oblivious to the possibility that a
piped-to program can run while it itself is also (still) running (which was
not possible in the era of DOS, nor of the command consoles of earlier
versions of Windows).

So, it looks I have to replace that legacy program.

Regards,
Rudy Wieser


-- Origional message:
JJ schreef in berichtnieuws
...
On Fri, 15 Jan 2016 11:13:00 +0100, R.Wieser wrote:

I could point fingers at the specific program sourcing the piped text,

but
I'm a lot more interrested in knowing what causes MORE's behaviour, and

how
I can fix it (instead of compiling a list of programs I should not use

in
combination with it).


Have you tried using the Unicode mode of CMD?



  #13  
Old January 15th 16, 02:58 PM posted to microsoft.public.windowsxp.help_and_support
Ron Hardin
external usenet poster
 
Posts: 204
Default XP's "more.com" skips first lines of output -- a bigger problem

Slightly OT, but you get unix/linux under XP if
you install Cygwin, if you'd prefer a nicer shell.

/cygdrive/c gets you to windows drive c

I've run it since 2005 without problems.

Use .profile as usual to set the shell up the way
you want.
--


On the internet, nobody knows you're a jerk.
  #14  
Old January 15th 16, 04:06 PM posted to microsoft.public.windowsxp.help_and_support
VanguardLH[_2_]
external usenet poster
 
Posts: 9,415
Default XP's "more.com" skips first lines of output -- a bigger problem

Piping uses a buffer to pipe data from stdout to stdin. Redirection
uses a file pointer (not necessarily a file in the file system) to
transfer data. With redirection using file pointers, the file has to
get closed to reuse it in another redirection (except as noted when
using &1 to merge data streams by having the output from one handle
write into to the input of another handle). So I have to wonder if the
problem isn't with the program generating the stdout stream. stdin for
more.com looks to be working because you tested with "... file & more
file" and that works (all lines are captured). Not all programs work
with pipes.

Note: Although I've mentioned stdin, stdout, and stderr, cmd.exe
actually permits up to 10 handles. 0 = stdin, 1 = stdout, 2 = stderr,
and 3-9 are defined by the program and are specific to it. To specify
which handle, put a number before the redirection character. No number
defaults to 1 (stdout) for and defaults to 0 (stdin) for . You can
specify a file or handle for the stream source. For example, "1&2"
redirects from handle 2 (stderr) into handle 1 (stdout) while "dir path
file 2&1" sends the dir's stdout and stderr to the same file. See:

http://www.microsoft.com/resources/d...direction.mspx

Piping uses a buffer while redirection uses file handles. I have read
that using | is that a command can produce enough output to fill up the
pipe's buffer which causes a block on the next program to read it. That
is, for "programA | programB", programA might fill up the buffer and
still be in write mode so programB cannot read the buffer. The size of
the pipe's buffer differs with different operating systems. There are
bunch of rules as to size and it can change within an OS. I read where
Mac OS/X has a pipe buffer capacity of 16,384 bytes but will switch to
65,336 bytes (although since Linux 2.6.11 it defaults to 65.336) if a
large write is made to the pipe, or switch to a single system page if
too much memory is already used by the pipe. fcntl is called by a
program to change the pipe's buffer size. win32api calls are used in
Windows. So a program could adjust the size of the pipe. Alas, I don't
know if a console-mode program can adjust the size of cmd.exe's piping
buffer. As I recall, cmd.exe's pipe is only 512 bytes. Very small.
And probably why piping is slow.

So perhaps you are hitting against the pipe's max buffer size versus
using redirection with file handles since files are rather indefinite in
size (with restrictions within the OS and hardware).

With the mode command, it looks like the args specify the buffer size.
"mode con:cols=80 lines=25" only gives you a 2000 byte buffer. If
instead you used "mode con:cols=132 lines=2500" then you would get a
322kB buffer (and use scrolling in the console window to get at scrolled
off output - but then you are using more.com to paginate that output).

I don't bother using MODE to define the buffer size for the console
(cmd.exe). I might if I needed in in a script (.bat file). Instead I
load the command shell and click on its control menu to select
Properties where I set the buffer size (and window size) under the
Layout tab. Because I don't want a huge window size (I set it at 132 x
50) which would end up with much of it being offscreen, I set a larger
buffer size (132 x 5000) and use the vertical scroll bar to move up and
down through the output. I could set width to 80 and use horizontal
scrollbar to move left and right for output greater than 80 characters
but the screen is usually wide enough that I can set width to 132 (few
DOS-mode programs ever exceed that line length).

So move away from using MODE to define some ancient 80x25 screen size
(whether by using mode.com or setting properties of cmd.exe's window)
and up the buffer size and use scroll bars. After all, you are using
more.com to paginate, anyway, so scrolling or not shouldn't be a concern
to you.
  #15  
Old January 15th 16, 05:34 PM posted to microsoft.public.windowsxp.help_and_support
R.Wieser
external usenet poster
 
Posts: 603
Default XP's "more.com" skips first lines of output -- a bigger problem

VanguardLH,

Piping uses a buffer to pipe data from stdout to stdin.
Redirection uses a file pointer (not necessarily a file in
the file system) to transfer data.


In this day-and-age ? True. But only when the consumer can run at the
same time as the sourcer.

So I have to wonder if the problem isn't with the program
generating the stdout stream.


Possible. But in that case, how would you explain that just the first few
lines go wrong -- and in different ways -- with the rest going fine ?

Not all programs work with pipes.


I'm not quite certain how that applies to a program which expects a
write-only handle to the console. As far as I'm aware a handle to a file,
a device or a pipe respond the same in that regard.

That is, for "programA | programB", programA might fill up
the buffer and still be in write mode so programB cannot
read the buffer.


:-) That would cause any program using a blocking read or write to
permanently freeze within seconds (which does not happen). As far as I know
a pipe is just a FIFO with a write, and a read end. If it gets full the
writing end cannot place more data into (the write blocks) it until the
reading end removes some data from its end.

As I recall, cmd.exe's pipe is only 512 bytes. Very small.
And probably why piping is slow.


Such a small buffer means that the writing program might need to do a *lot*
of small writes, and what you than see is probably the overhead of it all.

I don't bother using MODE to define the buffer size for the
console


I don't either. What I do use it for is not having a windowed console.
Ofcourse, the fact that 80x25 is what most legacy console apps expect to see
is a factor too. :-)

After all, you are using more.com to paginate, anyway, so scrolling
or not shouldn't be a concern to you.


Huh ? I like my daily shower just after getting outof bed. I would not
like it if that shower is cold, of a natural origine or when I'm clothed.
:-)

In other words: I want to have scrolling when *I'm* ready for it, not
allways. Besides, the scrolling buffer of a windowed console is limited
too, and stuff could scroll outof that buffer without me having a chance to
see it (yes, I sometimes have that much output to look at).

I've created (somewhat of) a solution though: I've taken a 16-bit
environment MORE.COM, removed the version check and use it in the console
window. The only drawback is that I have to wait for the sourcing program
to finish before the 16-bit MORE program gets its first data and thus can
display it. It will do for now.

Regards,
Rudy Wieser


-- Origional message:
VanguardLH schreef in berichtnieuws
...
Piping uses a buffer to pipe data from stdout to stdin. Redirection
uses a file pointer (not necessarily a file in the file system) to
transfer data. With redirection using file pointers, the file has to
get closed to reuse it in another redirection (except as noted when
using &1 to merge data streams by having the output from one handle
write into to the input of another handle). So I have to wonder if the
problem isn't with the program generating the stdout stream. stdin for
more.com looks to be working because you tested with "... file & more
file" and that works (all lines are captured). Not all programs work
with pipes.

Note: Although I've mentioned stdin, stdout, and stderr, cmd.exe
actually permits up to 10 handles. 0 = stdin, 1 = stdout, 2 = stderr,
and 3-9 are defined by the program and are specific to it. To specify
which handle, put a number before the redirection character. No number
defaults to 1 (stdout) for and defaults to 0 (stdin) for . You can
specify a file or handle for the stream source. For example, "1&2"
redirects from handle 2 (stderr) into handle 1 (stdout) while "dir path
file 2&1" sends the dir's stdout and stderr to the same file. See:


http://www.microsoft.com/resources/d...l/proddocs/en-
us/redirection.mspx

Piping uses a buffer while redirection uses file handles. I have read
that using | is that a command can produce enough output to fill up the
pipe's buffer which causes a block on the next program to read it. That
is, for "programA | programB", programA might fill up the buffer and
still be in write mode so programB cannot read the buffer. The size of
the pipe's buffer differs with different operating systems. There are
bunch of rules as to size and it can change within an OS. I read where
Mac OS/X has a pipe buffer capacity of 16,384 bytes but will switch to
65,336 bytes (although since Linux 2.6.11 it defaults to 65.336) if a
large write is made to the pipe, or switch to a single system page if
too much memory is already used by the pipe. fcntl is called by a
program to change the pipe's buffer size. win32api calls are used in
Windows. So a program could adjust the size of the pipe. Alas, I don't
know if a console-mode program can adjust the size of cmd.exe's piping
buffer. As I recall, cmd.exe's pipe is only 512 bytes. Very small.
And probably why piping is slow.

So perhaps you are hitting against the pipe's max buffer size versus
using redirection with file handles since files are rather indefinite in
size (with restrictions within the OS and hardware).

With the mode command, it looks like the args specify the buffer size.
"mode con:cols=80 lines=25" only gives you a 2000 byte buffer. If
instead you used "mode con:cols=132 lines=2500" then you would get a
322kB buffer (and use scrolling in the console window to get at scrolled
off output - but then you are using more.com to paginate that output).

I don't bother using MODE to define the buffer size for the console
(cmd.exe). I might if I needed in in a script (.bat file). Instead I
load the command shell and click on its control menu to select
Properties where I set the buffer size (and window size) under the
Layout tab. Because I don't want a huge window size (I set it at 132 x
50) which would end up with much of it being offscreen, I set a larger
buffer size (132 x 5000) and use the vertical scroll bar to move up and
down through the output. I could set width to 80 and use horizontal
scrollbar to move left and right for output greater than 80 characters
but the screen is usually wide enough that I can set width to 132 (few
DOS-mode programs ever exceed that line length).

So move away from using MODE to define some ancient 80x25 screen size
(whether by using mode.com or setting properties of cmd.exe's window)
and up the buffer size and use scroll bars. After all, you are using
more.com to paginate, anyway, so scrolling or not shouldn't be a concern
to you.



 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 04:28 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2004-2018 PCbanter.
The comments are property of their posters.