Path:   
   eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!f   
   eeder.erje.net!1.eu.feeder.erje.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 -- a bigger problem   
   Date: Fri, 15 Jan 2016 10:06:41 -0600   
   Organization: Usenet Elder   
   Lines: 65   
   Sender: VanguardLH <>   
   Message-ID:    
   References: <56977375$0$23733$e4fe514c@news.xs4all.nl>   
   <5698103a$0$23821$e4fe514c@news.xs4all.nl>    
   <5698c5a2$0$23803$e4fe514c@news.xs4all.nl>   
   Mime-Version: 1.0   
   Content-Type: text/plain; charset="us-ascii"   
   Content-Transfer-Encoding: 7bit   
   X-Trace: individual.net ltgLlBjwE/cPfufIfxAjXAsRomrjLuEhZ+EGam2gKvFN0rTARM   
   Keywords: VanguardLH VLH811   
   Cancel-Lock: sha1:PuCXbZ50LNthw7UtYaxxRadfbho=   
   User-Agent: 40tude_Dialog/2.0.15.41   
   Xref: mx02.eternal-september.org   
   microsoft.public.windowsxp.help_and_support:31816   
      
   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)