Help Diagnosing Strange Program Behavior

[pro...@berkeley.edu]

I've been a long-time user of the file viewer list.exe, which I believe
was first made available to Windows users as part of the Win2000 Resource
Kit tools. A few months ago, list.exe suddenly began behaving in a most
unusual way: the file being displayed was only visible in a narrow column
eight characters wide at the left of the window, and on the right side
the window was mostly blank, except that the tail end of what looks like
the output of a 'set' command appeared across the top of the screen, but
without any CR/LFs, each 'line' appended to the end of the preceding one.
I have uploaded an image to Box; you can see it here:

https://app.box.com/s/oxccfc20cfll9zteyh2kw5q2l745kf0x

(I didn't capture the entire window, just the part with characters.)

This happened a few months ago, and then a couple of days ago, it happened
again. The first time, I thought that somehow the program itself might
have become corrupted. I had another copy of list.exe, so I 'refreshed'
the program by deleting c:\util\list.exe and copying f:\util\list.exe to
c:\util. This appeared to solve the problem the first time, but now the
same strange behavior is happening again.

Last night I did some experimenting. Usually, I invoke 'list' from the
CMD prompt, but now it doesn't work when I do that. First thing was to
check whether there was a list.bat, list.cmd, list.rexx, and so on, in
the PATH. Nope. But when I ran the same command via WindowsKey-R, then
list.exe worked correctly! And when I created a desktop shortcut to
invoke list.exe, it also behaved correctly. So the problem doesn't seem
to be with list.exe itself but with something else.

I don't know where to check next. Any suggestions?

--
Phil Robyn

[Batchman]

pro...@berkeley.edu wrote:

> invoke list.exe, it also behaved correctly. So the problem doesn't seem
> to be with list.exe itself but with something else.
>

It certainly looks as though you have some other List program in your PATH.

Did you test for List.COM (an old Dos file viewer)?

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[pro...@berkeley.edu]

I didn't. But at your suggestion, I did: NOT IN PATH.

[foxidrive]

On 8/04/2016 04:19, pro...@berkeley.edu wrote:

> Last night I did some experimenting. Usually, I invoke 'list' from the
> CMD prompt, but now it doesn't work when I do that. First thing was to
> check whether there was a list.bat, list.cmd, list.rexx, and so on, in
> the PATH. Nope. But when I ran the same command via WindowsKey-R, then
> list.exe worked correctly! And when I created a desktop shortcut to
> invoke list.exe, it also behaved correctly. So the problem doesn't seem
> to be with list.exe itself but with something else.

Simple question first - is the vertical bar draggable horizontally with La
Mouse, on the right side of the 8 columns?

Try opening cmd and do a

set path=
c:\listfolder\list.exe

[pro...@berkeley.edu]

The vertical bar is NOT draggable; list.exe (whose ancestor is list.com)
is not mouse-aware.

But if I do the following, list.exe works as it is supposed to:

>xcmdc list \pxrwork\t*.txt

where xcmdc looks like

@echo off
setlocal enableextensions DISabledelayedexpansion
set inpt="%*"
if not defined inpt goto :BEGIN
echo/%inpt:~1,-1% >c:\cmd\util\cmd_from_JoeUser.cmd
if not exist "c:\cmd\util\cmd_from_JoeUser.cmd" (echo/no input&goto :EOF)
:BEGIN
start " " c:\Users\JoeUser\desktop\session2.lnk


and the Target field of session2.lnk says

%comspec% /c cmd_from_JoeUser


When I use WindowsKey-Run, list.exe also behaves as it should.

[Herbert Kleebauer]

On 08.04.2016 03:46, pro...@berkeley.edu wrote:

>> It certainly looks as though you have some other List program in your PATH.
>>
>> Did you test for List.COM (an old Dos file viewer)?
>>

> I didn't. But at your suggestion, I did: NOT IN PATH.

But maybe you have set the INIT variable in the PATH of a normal
CMD shell and a tools.ini file.

----------------------------------------------------------------


Newsgroups: microsoft.public.win32.programmer.tools
Date: Wed, 16 Jul 2014 23:22:14 -0700 (PDT)
Message-ID: <ef716200-5e77-4f65...@googlegroups.com>

Subject: Re: list's tools.ini

On Tuesday, August 10, 2004 4:25:05 AM UTC-7, Gisle Vanem wrote:
> The list.exe program is IMHO the single most valuable program
> in the "Microsoft Windows NT 4.0 Resource Kit Support Tools".
>
> Allthough it has it's quirks, I use it every day.
>
> The helpscreen (F1) indicates that settings like tab-width and colours
> can be entered in tools.ini, but I cannot get that to work. I created a
> tools.ini in the directory of list.exe (f:\programfiler\RKtools\) and added
> this:
> [list]
> tab 4
> tcolor 22
>
> It doesn't take effect. Where is tools.ini supposed to be located?
> I couldn't find *any* documentation for list in the package.


Put tools.ini in C:\INIT. Then "set INIT=C:\INIT". Viola.

[pro...@berkeley.edu]

No, I have never created any INIT for list.exe. I was also aware of
the 'tools.ini' info that shows in the 'help' screen for list.exe,
and I also had searched in vain for documentation of this years ago.
I'm going to try this (I have made the changes), but I'd better log
off and log on again to see if my new system variable is still there.
Thanks, I'll let you know whether it works tomorrow.

[Philip Robyn]

On Friday, April 8, 2016 at 12:22:38 AM UTC-7, Herbert Kleebauer wrote:

Thus creating an 'INI' file for list.exe works fine with regard to finally
being able to specify the colors and window size, etc.; but it doesn't
alter the strange behavior (except to change the colors to what I have
specified in the 'ini' file). The text of the file is visible in an
eight-character-wide column at the very left of the screen, the 'vertical
bar' (also known as the 'scroll bar') is still in column 9, and the large
area to the right of the vertical bar is empty except for the following:

♦ ○╖ É W É W 8 W 8 W ►W ≡

The strange display happens ONLY when list.exe is invoked from the CMD
prompt by user JoeUser (my everyday non-admin account). It does NOT happen
when list.exe is invoked by JoeUser via the XCMDC - Session2.lnk method
previously described. When admin user XNameNotGivenX invokes list.exe from
the CMD prompt, list.exe behaves properly. The behavior is the same with
or without the 'ini' file (except for the color changes).


--
Phil Robyn

[Herbert Kleebauer]

On 08.04.2016 20:07, Philip Robyn wrote:

> The strange display happens ONLY when list.exe is invoked from the CMD
> prompt by user JoeUser (my everyday non-admin account).

Does all CMD windows have a width of 201 columns?

Maybe it's time to change the tool. Why not use a Windows port
of Midnight Commander or Far Manager. Both are similar to the good
old DOS Norton Commander and have a built-in viewer and editor.


https://sourceforge.net/projects/mcwin32/
http://www.farmanager.com/

[pro...@berkeley.edu]

Herbert, you're a genius! The wide CMD window seems to be the cause
of the problem! The session2.lnk window dimensions were 140x55, but
my CMD window was cols=265 (!) at the time (I had been working on
files with long lines). So is the maximum width for list.exe equal
to 200 or fewer columns?

I have some good editors already (TextPad and Wylbur are the two I
use most often), but in my 'spare time' I will check out MCWIN32 and
FarManager.

--
Phil R.

[Herbert Kleebauer]

On 09.04.2016 01:48, pro...@berkeley.edu wrote:

> my CMD window was cols=265 (!) at the time (I had been working on
> files with long lines). So is the maximum width for list.exe equal
> to 200 or fewer columns?

Maybe the number of columns is stored in a byte variable. 265
as a byte gives 265-256=9 which could be the width of the
displayed text.

[pro...@berkeley.edu]

Could be. Experimentation shows that 256 is the maximum window width
tolerated by list.exe. Once past this threshold, the text column that
was eight characters wide increases with the window width, so that by
the time the window width is 360 (using a small-enough font setting),
the 'text column' has become wide enough again to show the file(s), but
there is still all of the 'memory leakage' of environment variables
like the output of a 'set' command across the top of the screen.
Thanks again for your help, Herbert!

--
Phil R.

[Dr J R Stockton]

In alt.msdos.batch.nt message <4af81a43-0d5c-4390-afc7-af6ce900b008@googlegro
ups.com>, Thu, 7 Apr 2016 11:19:18, pro...@berkeley.edu posted:

>
>I don't know where to check next. Any suggestions?
>

Open a command prompt window. For some shortish file F in the current
directory enter the command LIST F and when the contents of F are
showing type a question mark. That, or something more modern, should
enable you to say which version you have found. Mine says

LIST - Version 6.2a - 5/07/87
(c) Copyright 1987 Vernon D. Buerg

Instead, I use

MiniTrue 2.0.6 for 32-bit Windows May 1 2010
Copyright (C) 1995-99 Andrew Pipkin mini...@idiotsdelight.net
MiniTrue is free software released with no warranty. See COPYING for details.
This release by Jason Hood http://minitrue.adoxa.cjb.net/

--
(c) John Stockton, nr London, UK. For Mail, see Home Page. Turnpike, WinXP.
Web < > - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see my < pc-links.htm>.

[pro...@berkeley.edu]

Thanks, but Herbert solved the mystery. The problem was not with list.exe
itself but with the size of the CMD console window within which list was
invoked.