• Re: XP's "more.com" skips first lines of output -- a bigger problem

    From address@not.available@1:124/5013 to All on Mon Jan 14 16:19:00 2019
    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" <address@not.available>
    Newsgroups: microsoft.public.windowsxp.help_and_support
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl>
    Subject: Re: XP's "more.com" skips first lines of output -- a bigger problem Date: Thu, 14 Jan 2016 22:18:59 +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: 35
    Message-ID: <5698103a$0$23821$e4fe514c@news.xs4all.nl>
    NNTP-Posting-Host: 83.163.119.5
    X-Trace: 1452806202 news.xs4all.nl 23821 83.163.119.5:2941
    X-Complaints-To: abuse@xs4all.nl
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31808

    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 <address@not.available> schreef in berichtnieuws 56977375$0$23733$e4fe514c@news.xs4all.nl...
    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



    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From V@nguard.LH@1:124/5013 to All on Mon Jan 14 16:50:36 2019
    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 <V@nguard.LH>
    Newsgroups: microsoft.public.windowsxp.help_and_support
    Subject: Re: XP's "more.com" skips first lines of output -- a bigger problem Date: Thu, 14 Jan 2016 15:50:36 -0600
    Organization: Usenet Elder
    Lines: 35
    Sender: VanguardLH <>
    Message-ID: <dfqjheFu1r6U1@mid.individual.net>
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl>
    Mime-Version: 1.0
    Content-Type: text/plain; charset="us-ascii"
    Content-Transfer-Encoding: 7bit
    X-Trace: individual.net 1bXy6eqd14PJVM8wgYhi6QTWCmC1ZpN/Z2oRz3oVTHGxPkgMMr Keywords: VanguardLH VLH811
    Cancel-Lock: sha1:1sy5OZiD52ZBwNBK6QAd4f195RY=
    User-Agent: 40tude_Dialog/2.0.15.41
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31809

    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)?
    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From jj4public@vfemail.net@1:124/5013 to All on Tue Jan 15 01:23:24 2019
    Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!n ews.mixmin.net!news.albasani.net!.POSTED!not-for-mail
    From: JJ <jj4public@vfemail.net>
    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 13:23:24 +0700
    Organization: ?
    Lines: 13
    Message-ID: <1xq24kwecs5t8$.hbosenoc5auw$.dlg@40tude.net>
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl>
    Mime-Version: 1.0
    Content-Type: text/plain; charset="us-ascii"
    Content-Transfer-Encoding: 7bit
    X-Trace: news.albasani.net YraS285hDcsl9SSJRCk8Gda7SssliLLVKf5omFive4/y9NGFQop7aF7Bf+ggvsCo31TNN74kdSm3YAY feYWh+vMnBR1cyRzm59cNWphUyUurf4Q7QFOcoHFDJxdQLc7l
    NNTP-Posting-Date: Fri, 15 Jan 2016 06:23:26 +0000 (UTC)
    Injection-Info: news.albasani.net; logging-data="rYj1Cgpv7f+erwUzLr70XFkrWmIl+lY3ezbnmikU0PSNGE47KFMEd4cAzruxUiyPy wpjTzagRJYOY/0ZRNQEWAVEv7vfguSXXr9Wx3tyAtqhcNsCZTVvHmV2Z2LHnQF0"; mail-complaints-to="abuse@albasani.net"
    User-Agent: 40tude_Dialog/2.0.15.1
    X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
    Cancel-Lock: sha1:6b1nHfSfXXMSFDLC5oWXIVqOtN0=
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31810

    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.
    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From address@not.available@1:124/5013 to All on Tue Jan 15 04:27:02 2019
    Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!g oblin1!goblin.stu.neva.ru!uio.no!news.tele.dk!news.tele.dk!small.news.tele.dk!n ewsgate.cistron.nl!newsgate.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail From: "R.Wieser" <address@not.available>
    Newsgroups: microsoft.public.windowsxp.help_and_support
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <1xq24kwecs5t8$.hbosenoc5auw$.dlg@40tude.net>
    Subject: Re: XP's "more.com" skips first lines of output -- a bigger problem Date: Fri, 15 Jan 2016 10:27:01 +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: 44
    Message-ID: <5698badb$0$23794$e4fe514c@news.xs4all.nl>
    NNTP-Posting-Host: 83.163.119.5
    X-Trace: 1452849883 news.xs4all.nl 23794 83.163.119.5:1373
    X-Complaints-To: abuse@xs4all.nl
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31811

    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 <jj4public@vfemail.net> schreef in berichtnieuws 1xq24kwecs5t8$.hbosenoc5auw$.dlg@40tude.net...
    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.

    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From address@not.available@1:124/5013 to All on Tue Jan 15 05:13:00 2019
    Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!b order1.nntp.ams1.giganews.com!nntp.giganews.com!bcyclone02.am1.xlned.com!bcyclo ne02.am1.xlned.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!nzpost1.xs4all.n et!not-for-mail
    From: "R.Wieser" <address@not.available>
    Newsgroups: microsoft.public.windowsxp.help_and_support
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <dfqjheFu1r6U1@mid.individual.net> Subject: Re: XP's "more.com" skips first lines of output -- a bigger problem Date: Fri, 15 Jan 2016 11:13:00 +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: 111
    Message-ID: <5698c5a2$0$23803$e4fe514c@news.xs4all.nl>
    NNTP-Posting-Host: 83.163.119.5
    X-Trace: 1452852642 news.xs4all.nl 23803 83.163.119.5:1377
    X-Complaints-To: abuse@xs4all.nl
    X-Received-Bytes: 5101
    X-Received-Body-CRC: 3075415709
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31812

    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 <V@nguard.LH> schreef in berichtnieuws dfqjheFu1r6U1@mid.individual.net...
    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)?


    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From jj4public@vfemail.net@1:124/5013 to All on Tue Jan 15 06:27:06 2019
    Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!n ews.mixmin.net!news.albasani.net!.POSTED!not-for-mail
    From: JJ <jj4public@vfemail.net>
    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 18:27:05 +0700
    Organization: ?
    Lines: 8
    Message-ID: <1rx8aiykrxzrh$.1bymvtgug2bf6$.dlg@40tude.net>
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <dfqjheFu1r6U1@mid.individual.net> <5698c5a2$0$23803$e4fe514c@news.xs4all.nl>
    Mime-Version: 1.0
    Content-Type: text/plain; charset="us-ascii"
    Content-Transfer-Encoding: 7bit
    X-Trace: news.albasani.net WGBpDH04j3O3vUVQ3N3dBSEBIHk3q68kqQuZrnvvngW5AXJF4R+9fwkaKUvuU/+f+uRGuNl4XUoQLOZ FRpDQL0g/xuQZHIr9xJ6UI9QukY8tI7/CzHXTXsHSV9sVlhH9
    NNTP-Posting-Date: Fri, 15 Jan 2016 11:27:06 +0000 (UTC)
    Injection-Info: news.albasani.net; logging-data="VZhOHm/phDYqjJfk7FTfqTrWQEie7a4/oWuJ8SZUmkh+fxy6fOKZj3R9pEUVvZ8zo 4rcAhSnt2lt3MDQyOOlJIMf/buDaKkCe/mxWtjlNvyyySsIjqozgd7FkcnE0HAP"; mail-complaints-to="abuse@albasani.net"
    User-Agent: 40tude_Dialog/2.0.15.1
    X-Face: \*\`0(1j~VfYC>ebz[&O.]=,Nm\oRM{of,liRO#7Eqi4|!]!(Gs=Akgh{J)605>C9Air?pa d{sSZ09u+A7f<^paR"/NH_#<mE1S"hde\c6PZLUB[t/s5-+Iu5DSc?P0+4%,Hl
    Cancel-Lock: sha1:AubVDKQ9AdjkakLuANwWAGtI0ro=
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31813

    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?
    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From address@not.available@1:124/5013 to All on Tue Jan 15 06:57:18 2019
    Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!f eeder2.usenet.farm!feeder.erje.net!2.eu.feeder.erje.net!newsfeed.xs4all.nl!news feed8.news.xs4all.nl!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cist ron.nl!newsgate.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail
    From: "R.Wieser" <address@not.available>
    Newsgroups: microsoft.public.windowsxp.help_and_support
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <dfqjheFu1r6U1@mid.individual.net> <5698c5a2$0$23803$e4fe514c@news.xs4all.nl> <1rx8aiykrxzrh$.1bymvtgug2bf6$.dlg@40tude.net>
    Subject: Re: XP's "more.com" skips first lines of output -- a bigger problem Date: Fri, 15 Jan 2016 12:57:17 +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: 41
    Message-ID: <5698de12$0$23842$e4fe514c@news.xs4all.nl>
    NNTP-Posting-Host: 83.163.119.5
    X-Trace: 1452858898 news.xs4all.nl 23842 83.163.119.5:1723
    X-Complaints-To: abuse@xs4all.nl
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31814

    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 <jj4public@vfemail.net> schreef in berichtnieuws 1rx8aiykrxzrh$.1bymvtgug2bf6$.dlg@40tude.net...
    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?

    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From rhhardin@mindspring.com@1:124/5013 to All on Tue Jan 15 09:58:14 2019
    Path: eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!n ews.glorb.com!Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews .com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED! not-for-mail
    NNTP-Posting-Date: Fri, 15 Jan 2016 08:57:29 -0600
    Message-ID: <56990905.3B0B@mindspring.com>
    Date: Fri, 15 Jan 2016 09:58:13 -0500
    From: Ron Hardin <rhhardin@mindspring.com>
    X-Mailer: Mozilla 2.02 (WinNT; I)
    MIME-Version: 1.0
    Newsgroups: microsoft.public.windowsxp.help_and_support
    Subject: Re: XP's "more.com" skips first lines of output -- a bigger problem References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <dfqjheFu1r6U1@mid.individual.net> <5698c5a2$0$23803$e4fe514c@news.xs4all.nl> <1rx8aiykrxzrh$.1bymvtgug2bf6$.dlg@40tude.net> <5698de12$0$23842$e4fe514c@news.xs4all.nl>
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    Lines: 13
    X-Usenet-Provider: http://www.giganews.com
    NNTP-Posting-Host: 71.54.71.88
    X-Trace: sv3-2HdfhBG3zTmOB0EbrX4RIuM8STZyNlNBzAu2XVpTD9exCvGACWzTVr8J5vqJ/hZqHGcHjeGsO9o byEz!mBi3bRe68g2adCrtZ7mxXwaJ6tmoijX598jK7clEgnIgypb7eCoLhZ9v1tHmHM9AB0pm5MVLpu 2Q!yFXq5xmI
    X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
    X-Postfilter: 1.3.40
    X-Original-Bytes: 1587
    Xref: mx02.eternal-september.org microsoft.public.windowsxp.help_and_support:31815

    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.
    --
    rhhardin@mindspring.com

    On the internet, nobody knows you're a jerk.
    --- Platinum Xpress/Win/WINServer v3.1
    * Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)
  • From V@nguard.LH@1:124/5013 to All on Tue Jan 15 11:06:42 2019
    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 <V@nguard.LH>
    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: <dfsjolFelhpU1@mid.individual.net>
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <dfqjheFu1r6U1@mid.individual.net> <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)
  • From address@not.available@1:124/5013 to All on Tue Jan 15 12:34:56 2019
    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" <address@not.available>
    Newsgroups: microsoft.public.windowsxp.help_and_support
    References: <56977375$0$23733$e4fe514c@news.xs4all.nl> <5698103a$0$23821$e4fe514c@news.xs4all.nl> <dfqjheFu1r6U1@mid.individual.net> <5698c5a2$0$23803$e4fe514c@news.xs4all.nl> <dfsjolFelhpU1@mid.individual.net> 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 <V@nguard.LH> 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)