My suggestion would be to simply allow chmod on windows, unless explicitly conditionalized by platform. It would be up to the user to supply a suitable implementation on the PATH.
Unfortunately, to just change it to run everywhere by default would be incompatible, so the default would have to continue to be to limit it to unix platforms, but we should be able to explicitly request it. It's not necessary to append ".exe" -- in fact, it would be incorrect. I might supply the functionality in a .BAT file, perl script, or what have you. In my case, I would either use cygwin, or write a little script that does ATTRIB to map the specific case I'm interested in, and error otherwise (which is to turn off read-only status). It doesn't have to be fully unix-compatible; it merely has to perform the task as required by the build. -----Original Message----- From: Rob Oxspring [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2002 2:29 PM To: Ant Developers List Subject: RE: Chmod task for Windows > -----Original Message----- > From: Jesse Stockall [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 24, 2002 9:32 PM > To: Ant Developers List > Subject: Re: Chmod task for Windows > > > On Thu, 2002-01-24 at 15:18, Peter Donald wrote: > > > > Theres also the difficulty that some windows platforms (ie > cygwin) actually > > support chmod to some degree or another. So we would be > blocking people who > > already used chmod on win32. > > Hmmm, the Chmod task does an check for Os family="unix". Cygwin on > Win2000 is detected as family "windows" so the Chmod task should never > run on a Windows box. Also it can be valid to run chmod under "normal" windows - my specific example is when using an NFS mounted volume. This also applies to chgrp and chown which by rights should probably also have ant tasks. I would suggest that the restriction of OsFamily="unix" should be at most a default and not the precondition that it currently is. I'm not sure if this simple change would be enough though since NFS Maestro supplies chmod.exe which, if I understand things correctly, would not be picked up by the line in Chmod.java: super.setExecutable("chmod"); How does cygwin supply the chmod functionality - chmod or chmod.exe? - could we get away with adding ".exe" to the commandline if the os family is "windows"? > > > The first one would definetly be accepted. The second *might* > be accepted if > > it was done in an exceptionally good way but I suspect it would not :) > > Peter, I know that you are cencentrating on Ant2 right now, and the VFS should probably provide access to these sort of features, but could you spare the time to extrapolate on "an exceptionally good way" to combine this functionality? I suggested a (somwhat ambitious) option on a previous thread but got no response... http://marc.theaimsgroup.com/?l=ant-dev&m=100533848516462&w=2 I'm happy to work on such a combined task, and firmly believe that it would be better than the current unix only support, but would prefer it if I felt that there was a vague chance of making it into CVS. Rob > > I guess I'll submit the attrib task for now & put some more thought into > a platform independent chmod task. > > > > -- > Jesse Stockall | Tel: 1+ > 613.599.2441 ext. 243 > CRYPTOCard Corporation | Fax: 1+ 613.599.2442 > Suite 304, 300 March Rd. | email: [EMAIL PROTECTED] > Ottawa, ON, Canada K2K 2E2 | web: www.cryptocard.com > --------------------------------------------------------------------- > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
