Subj : Re: XP's "more.com" skips first lines of output -- a bigger problem To : All From : address@not.available Date : Tue Jan 15 2019 12:34 pm Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!b order1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed8.ne ws.xs4all.nl!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!n ewsgate.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail From: "R.Wieser" Newsgroups: microsoft.public.windowsxp.help_and_support References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <5698c5a2$0$23803$e4fe514c@news.xs4all.nl> Subject: Re: XP's "more.com" skips first lines of output -- a bigger problem Date: Fri, 15 Jan 2016 18:34:55 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Lines: 138 Message-ID: <56992d34$0$23823$e4fe514c@news.xs4all.nl> NNTP-Posting-Host: 83.163.119.5 X-Trace: 1452879156 news.xs4all.nl 23823 83.163.119.5:2314 X-Complaints-To: abuse@xs4all.nl Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31817 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 dfsjolFelhpU1@mid.individual.net... > 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/documentation/windows/xp/all/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. --- Platinum Xpress/Win/WINServer v3.1 * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013) .