EnBug is useful for when you have to fix a DOS or Windows machine with no or broken networking, and no CD or no available media (and in my case, neither terminal program would upload with [XYZ]modem). Use a terminal program to dial into a box with a shell account, use lynx or wget to fetch EnBug and the required files, EnBug them and log/capture the output to the local disk (lack of 8-bit-clean is fine), run debug, redirecting input from the captured text file. Debug then re-creates the original files. Large files are split and must be recombined with COPY /B 1file+2file+3file file.
> A super intelligent compiler would replace f(3) to the
> That's the utopia.
DEC ForTran did this in 1980. Friend was
benchmarking it and got unreasonably good results, made
it spit out the asm, which was a single instruction:
print-fixed-string-and-exit with the correct end result.
--long-help? --full-help? --war-and-peace?
Fine and good, but before you get too carried away I'd like to see published conventions for getting full or specific kinds of help.
I'd also like to see any help for some GUI programs at all; many of them (KDE tools are notable for this) have neither --help nor a manpage, and in that specific case no handbook either. It would be handy to have KDE/GNOME/etc field --help if the application does not and at least list the KDE/GNOME/whatever options, plus the X options, and who knows what else is possible, maybe filch out a getopts array from the application, if it has one.