Bug 16867 - Ant + Windows = Ant doesn't work and is incompatible because WIndows command line sucks and ANt developers didn't take that into account
Summary: Ant + Windows = Ant doesn't work and is incompatible because WIndows command ...
Status: RESOLVED INVALID
Alias: None
Product: Ant
Classification: Unclassified
Component: Build Process (show other bugs)
Version: 1.5.1
Hardware: PC other
: P3 blocker (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-07 05:11 UTC by Dustin D
Modified: 2019-07-23 05:33 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dustin D 2003-02-07 05:11:20 UTC
I guess Ant doesn't work in Windows Millenium, because when I pull up a command 
prompt and try to run ant, it scrolls by a bunch of crap which is basically 
standard error output.  Because it's Windows, command prompt doesn't have a 
scroll bar.  Because it's standard error, I can't redirect the output to a 
file.  Because -logfile doesn't print standard error, I can't use command line 
switches to save the output.  Basically, unless Ant produces less than like 20 
lines of output, or unless it starts printing output to standard output, or 
unless I find an alternative to dos command prompt that isn't a piece of shit, 
I can't use Ant on Windows.  And I'm pissed because I just wasted 2 hours 
trying to find a way around this, searching google groups, downloading command 
prompt alternatives, and nothing f***ing works.  You guys should really 
consider redoing the output of Ant so that it works under Windows if you want 
Windows users to use it, because not everyone has the latest and greatest 
windows with scrollbar support in command prompt.  Windows f***ing sucks and if 
it wasn't for the project's need to work on Windows, I would have ditched it a 
long time ago.  I can't believe how rediculous this is, a program that prints 
output that you can't read.  Sorry for my frustration but it really, really, 
really really really pisses me off..
Comment 1 Conor MacNeill 2003-02-07 05:19:43 UTC

*** This bug has been marked as a duplicate of 13582 ***
Comment 2 Dustin D 2003-02-07 05:57:25 UTC
How is this a duplicate?  13582 has to do with ant.bat checking for paths and 
whether or not files/directories exist under Windows 98.  My bug has to do with 
not being able to see the output when I run ant because it scrolls down a ton 
of text using standard error, meaning that (1) I can't scroll back because 
Windows sucks, and (2) I can't redirect the stderr output to a file because 
windows sucks.  I don't see what this has to do with 13582.  I think it's a bug 
because Ant should provide a means for command output under Windows 
95/98/Millenium, and scrolling a bunch of text down a command prompt window so 
you can't read it doesn't seem like the route to go.
Comment 3 Conor MacNeill 2003-02-07 06:14:14 UTC
You said:
"I guess Ant doesn't work in Windows Millenium, because when I pull up a command 
prompt and try to run ant, it scrolls by a bunch of crap which is basically 
standard error output. "

My assumption is that this results from the problem in ant.bat. If you make that
fix, Ant should work. You should then be able to use -logfile. If this does not
work for you, I apologize for the incorrect assumption

As for Ant producing too much output for Windows ME, I'm afraid that is a
limitation of Windows ME. There are many other limitations to Windows ME and it
is not feasible for Ant to try and fix all of them.

Some alternatives would be to install cygwin and use the rxvt terminal which
comes with a scrollbar or to use an editor such as jEdit (free) or UltraEdit
which can store the output into a window with a scroll bar.
Comment 4 Antoine Levy-Lambert 2003-02-07 07:54:48 UTC
Can you also try to capture the standard error output if you do :
ant  2> myerrors.txt
Another 
possibility would be that you install emacs or xemacs on your PC, then run ant from the shell buffer 
of emacs, which should be big enough and lets you scroll through the results.
Other editors 
might also have big shell buffers. For instance UltraEdit32 can run commands for you and display 
both stderr and stdout in the resulting buffer.
Comment 5 Erik Hatcher 2003-02-07 08:35:49 UTC
I don't know WindowsME, but in Windows 95/98/NT/2000 (all of which I've used), it requires you set the vertical buffer to something larger than the screen height and scroll bars will then appear.  I'm assuming WindowsME has the same feature.
Comment 6 Antoine Levy-Lambert 2003-02-07 08:46:27 UTC
Erik is right, you should be able to right click on the title bar of your DOS Command window, then a 
popup menu appears. If you choose from this menu "Properties", you can adjust the size of the 
window and more importantly the size of the buffer up to 9999 lines.
Comment 7 Conor MacNeill 2003-02-07 09:55:34 UTC
No, unfortunately in Windows 98 (and I suspect 95 and ME) it is not possible to 
have a scroll bar on a command window. You can set the window to a maximum of 
50 lines.
Comment 8 Dustin D 2003-02-07 12:42:18 UTC
Yes, I tried multiple options under properties, to no avail.  I haven't tried 
redirecting stderr with 2>, so maybe I should give that a try.  I thought that 
was a unix-only thing, although I did try >& (used in csh for stderr).

Using UltraEdit32 or whatever sounds like a good idea too, I'll try that.  I 
guess I've been working in unix for too long, so it's extremely painful to deal 
with Windows command-line after getting spoiled by all the features of unix.

Thanks for the help,
Dustin
Comment 9 Steve Loughran 2003-02-07 18:16:31 UTC
I love titles that blame us, but I guess you are just venting your
disatisfaction with WinME/

I agree the Windows command line sucks, and I agree we didnt take it into
account. But we did and still do jump through inordinate hoops in the batch file
to make sure that Ant runs under win9x, which is a lot harder than you think, as
the .BAT execution sucks badly too. 

The rest, we leave to you

Can I suggest.

1. ant | more  to get paged stuff
2. 4DOS command shell (very nice add on)
3. run ant inside an IDE 
4. antidote (feel free to help)

Also, what was it you expected? That we should recognise that win9x and suddenly
add a fancy gui with scroll bars just to make your life easier? But what about
everyone running ant as part of some batch mode?

-Steve



Comment 10 Dustin D 2003-02-07 20:02:58 UTC
Nope, I wouldn't expect you to improve Windows or include an Ant-specific
service pack for Windows with Ant, that's silly.  But when your program doesn't
work, or when a user cannot see output, I think you have a serious problem. 
Imagine if you wrote a Windows application that only ran at a resolution of
1280x1024 and announced to the world that anyone with Windows can run it!  But
when users downloaded it, some of them realized they couldn't run it because it
was made to run at only 1280x1024.  Well, I would say that's a serious flaw with
your software, and unless there was a really good reason for forcing 1280x1024
resolution for your software, it's probably a dumb idea.  

Excuse the crappy analogy, but nonetheless, I think it applies.  If you write an
app for Windows but don't take into account the limitations of Windows, you're
setting yourself and your users up for trouble.  Trust me, I'm not trying to
bash Ant, I know you guys wrote some code that I'm able to download for free and
play with, so obviously if I don't like it, you have no obligation to support
me.  It was simply a recommendation, that if you're going to design a program
for windows that's dependent on the evil MSDOS Command Prompt, then either
adjust the output of Ant so that it accomodates this limitation, or provide some
links or something to some software that will enable Ant to run a little more
gracefully under Windows.  In my case, I was running ant, but getting an error
message that I couldn't understand because it was beyond the border of my
command prompt.  That's a serious problem for Windows users running Ant.  In
most cases piping output or doing |more will work, but in this case, it didn't.
 For whatever reason, I guess stderr doesn't pipe to the more command.

So don't take it as me bashing your software, but instead read it as me making a
recommendation as a frustrated user.  I know Windows sucks for things like this,
and it must be a real headache, I sympathize.  But nothing would be better than
to have Ant performing as the most robust build system on all platforms.

Thanks again for all the recommendations, and continue the good work.

-Dustin