h a l f b a k e r yLike you could do any better.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Even under a graphical user interface like Windows, it is often useful to run processes from a command-line. This is especially true in software development, though it's true in some other situations as well.
Unfortunately, the command prompt window really has not improved much since the early days
of DOS. The 80x25 screen with no scrollback, the limitted batch-file processor, etc. all still remain.
About a decade ago, at a former employer, I used MPW for some software development on a Macintosh. MPW provided a command-line interface that really put DOS to shame. Input and output were done in a window which supported cut/copy/paste and nearly-unlimitted scrollback-ability, macros could be added to accomplish repeated tasks, and the script language allowed things that aren't even easy under Unix (I wrote an automatic make-file generator which would search through .c files to determine what other files they #include'd, for example).
What I'd like to see would be a version of the DOS prompt which is intended for use with DOS or Windows console applications which limit their console I/O to the equivalents of stdin, stdout, and stderr. In this version of the DOS prompt I would like, at minimum, a usable scrollback buffer, I/O redirection which sends output to both the screen and a file, copy/paste support, and probably some improved batch-file facilities as well.
Would anyone else like to see such a thing?
Cygwin
http://www.cygwin.com/
UNIX environment for Windows [bookworm, Feb 06 2002]
'TEE' command for DOS
http://www.zdnet.co.../06/tu1506.002.html
[phoenix, Feb 06 2002]
VB Source code for a Windows 'TEE' command
http://www.fpschultze.de/w3.htm
[phoenix, Feb 06 2002]
[link]
|
| |
All versions of Windows support batch file processing (as you point out). Batch file processing is only limited by your utility set. |
|
| |
If batch files still don't do it for you, or you want to interact with the GUI all Windows versions since 9x have supported the Windows Scripting Host (WSH). The WSH is a VB-like language that allows object-oriented interaction with the OS itself. |
|
| |
As far as the command prompt itself, all versions of Windows since 9x allow cutting and pasting. There are no macros, per se, but that's what batch files are for. For a scrollable command prompt, move up to NT or 2k/XP. Both provide a scrollable command prompt. |
|
| |
Or run a *n*x and simulate Windows on top of that. |
|
| |
In a Beowulf custard linked by Bluetooth. |
|
| |
Phoenix: I have not seen any way to size the command-prompt window larger than 80x50, nor make the contents easily recallable. Copy/paste sort of work, but only as a very crudely-implemented hack compared with MPW. |
|
| |
As for batch files only being limited by the utility set, there are limits to what utilities can do. For example, I know of no NT-compatible way of directing program output simultaneously to the screen and to a file (equivalent of Unix 'tee' command). Yes, it's possible to redirect to a file and then type it to the screen, but if the program needs user input that doesn't work well at all. |
|
| |
It shouldn't be that hard for Microsoft to have an application which loads a DOS-app in a virtual machine and redirects INT21 accesses to stdout/stderr into a textedit-style window. Unfortunately, however, I don't know any way to do that without inside knowledge of some of Microsoft's "hooks". |
|
| |
To what extent is "I would like these features from <application> in <other application>" a me-too? |
|
| |
I don't feel that pointing out shortcomings of Windows compared to other operating systems or applications you've known is a good line of inquiry for the halfbakery - there's a lot to complain about, and there's not much creativity involved. |
|
| |
Whilst admitting this isn't an idea, you can certainly do most things with batch files and Perl scripts. The main limits are the inputs and outputs, and the OS commands are limited in things like globbing and options. |
|
| |
NT and 2000 seem to support scrolling and large screen buffers. 2000 also has neat, though apparently undocumented, copy-and-paste functionality: highlight with the mouse pointer, and right-click on to copy; then right-click anywhere on screen to paste at the current cursor position. |
|
| |
[supercat] "As for batch files only being limited by the utility set, there are limits to what utilities can do."
That limitation coming from what the operating system itself can do (or will allow). If you want a Windows equivilent to the 'tee' command, write one. Or visit one of the links I've posted. |
|
| |
The 'tee' utility which was linked to is unfortunately not very useful in MS-DOS derivatives because they don't use "real" pipes; instead they redirect the first program's output to a file until the program completes, then feed that file into the second program. As a result, no output is visible until the first program has completed; if the program is waiting for input the user wasn't expecting it to require, the user will have to guess what it's looking for. |
|
| |
While the environment I'd be looking for is similar to others that exist, I know of no environment which hooks into the DOS INT21h handler (to catch STDOUT) and INT27H/INT10H handlers (to catch STDERR) when running DOS programs and the appropriate windows hooks when running Windows command-line based programs to provide such programs with the versatility present in other environments. |
|
| |
BTW, at work I mainly use Windows NT; I have not been able to find any useful scrollback features. If such things exist, could you direct me to them? |
|
| |
[Jutta]: I'm not seeking to bash Windows, nor to offer a WIBNI with no possible implimentation. I have a very good idea of how what I want could be implemented, but lack the knowledge of Windows internals to do it myself. Actually, I've very seriously considered doing a TSR to hook INT21h and INT10h thusly: |
|
| |
INT21h:
If TTY output trap
Output character via INT10h
Set anti-duplication flag
Call old INT21h
Clear anti-duplication flag
Else
Tailjump to old INT21h
Endif |
|
| |
INT10h:
If not TTY output or anti-duplication flag not set
Tailjump to old INT10h
Else
Return without outputting
Endif |
|
| |
Unfortunately, this approach would not only be incompatible with many INT27h enhancements such as ANSI.SYS, but it would also have problems if something like a critical error (Drive not ready etc.) prevented the call to the old INT21h from returning as planned. Tapping into those other interrupts and dealing with them shouldn't be overly hard, but is beyond my expertise. |
|
| |
[supercat] There are two command prompts in NT/2K: Command.com and CMD.exe. Opening either should give you a command prompt window with a scroll bar on the right-hand edge. |
|
| |
phoenix: In WinNT, running any DOS program, even one which restricts itself to INT21 console output, will size the command-prompt window to a maximum of 50 rows. If a makefile produces more than 50 lines of diagnostic output (sometimes unavoidable with the more verbose compilers) the first lines will scroll off screen, never to be seen again. |
|
| |
If NT supported a //useful// 'tee' function, which did not wait until a program was complete before redirecting its output, that would be great. Unfortunately, it does not. |
|
| |
Indeed, I think my two biggest complaints are the lack of a useful 'tee' and the inability have DOS output go, in real time, to a usefully-sized window. As yet I know no solution to either problem. |
|
| |
I'm sitting in front of my Win2K machine right now, so I can't speak for NT (haven't used it in a couple of years, but I'll check it when I get to work). |
|
| |
Opening a command prompt and maximizing it gives me a 62 line display. Right-clicking the command prompt icon in the upper left-hand corner and selecting properties brings up the property sheet for the window. The first of the four tabs ('Options') shows that the command prompt is currently set for 4 buffers of 50 lines each. This is configurable. The second tab ('Font') allows me to resize the command prompt font, which allows me to manipulate the number of visible lines displayed (124 lines onscreen at 4x6 character size - unusable on my 1024x764 display; 6x8 is a better fit and allows 93 lines to be displayed). The third tab ('Layout') allows me to configure the viewable buffer ('Screen Buffer Size') and the non-maximized window display ('Window Size'). |
|
| |
If for some reason I needed to view the output one page at a time, I'd pipe the output into a MORE command. |
|
| |
Again, I'll try to verify on NT 4.0 when I get to work. |
|
| |
And to replace the "tee" command, either cut and paste the output from screen to a file, or for your own programs you can just replace printf with a revised version that'll output to a file and the screen. Something like: |
|
| |
#include <stdio.h>
#include <stdarg.h>
FILE *dumpfile = fopen("dumpfile.txt","w");
int teeprintf( const char * format, ... )
{
int rtn = 0;
va_list args;
va_start( args, format );
vfprintf( dumpfile, format, args );
rtn = vfprintf( stdout, format, args );
va_end( args );
return rtn;
}
|
|
| |
Not actually tested, but close enough. |
|
| |
pottedstu: Including simultaneous stdout/stderr in my own software would be trivial, and I often in fact do precisely that. I don't, however, have source code for things like the cross-compilers I use on a daily basis, and thus can't patch them that way. |
|
| |
Otherwise, screen capturing is fine if stuff fits on the screen (which alas it often doesn't), and as I've noted before piping in MSDOS/Windows means that no output from a program will be visible until it's been run to completion. |
|
| |