I've noticed that my XPsp3 has got a version of MORE.COM
which, in circumstances, skips the first set/page of lines.
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
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.
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.
On Thu, 14 Jan 2016 22:18:59 +0100, R.Wieser wrote:noticed
I threw together a small program emulating a basic MORE program, and
with myit failed pretty-much the same way.
Either my OS has got problems or, more likely, there something wrong
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.
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.
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?
Have you tried "more.com file > otherfile
R.Wieser wrote on 2016/01/14:noticed
I threw together a small program emulating a basic MORE program, and
with myit failed pretty-much the same way.
Either my OS has got problems or, more likely, there something wrong
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)?
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?
On Fri, 15 Jan 2016 11:13:00 +0100, R.Wieser wrote:but
I could point fingers at the specific program sourcing the piped text,
howI'm a lot more interrested in knowing what causes MORE's behaviour, and
inI can fix it (instead of compiling a list of programs I should not use
combination with it).
Have you tried using the Unicode mode of CMD?
file 2>&1" sends the dir's stdout and stderr to the same file. See:http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ redirection.mspx
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.
So I have to wonder if the problem isn't with the program
generating the stdout stream.
Not all programs work with pipes.
That is, for "programA | programB", programA might fill up
the buffer and still be in write mode so programB cannot
read the buffer.
As I recall, cmd.exe's pipe is only 512 bytes. Very small.
And probably why piping is slow.
I don't bother using MODE to define the buffer size for the
console
After all, you are using more.com to paginate, anyway, so scrolling
or not shouldn't be a concern to you.
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:
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.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 995 |
Nodes: | 10 (1 / 9) |
Uptime: | 199:16:46 |
Calls: | 13,023 |
Calls today: | 1 |
Files: | 186,574 |
Messages: | 3,284,719 |