Please upload: clamav-0.88.3-3
Due to another packaging errors introduced by the switch to cygport detected by Volker Zell (thanks) I need an update. And finally I split the package into more convenient pieces. http://xarch.tu-graz.ac.at/publ/cygwin/release/clamav/setup.hint http://xarch.tu-graz.ac.at/publ/cygwin/release/clamav/clamav-0.88.3-3.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/clamav/clamav-0.88.3-3-src.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/clamav/libclamav1/libclamav1-0.88.3-3.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/clamav/libclamav1/setup.hint http://xarch.tu-graz.ac.at/publ/cygwin/release/clamav/libclamav-devel/libclamav-devel-0.88.3-3.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/clamav/libclamav-devel/setup.hint Please keep clamav-0.88.2-1 as prev and delete clamav-0.88.3-2 All setup.hint's changed, resp. are new. -- Reini
Please upload: mathomatic-12.6.0-1
http://xarch.tu-graz.ac.at/publ/cygwin/release/mathomatic/mathomatic-12.6.0-1.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/mathomatic/mathomatic-12.6.0-1-src.tar.bz2 setup.hint didn't change. mathomatic-12.5.22-1 will be prev. mathomatic-12.5.20-1 can be deleted. Thanks! -- Reini
Re: [ITP] mlcscope-14.1.8 (Attempt 2)
Dave Diane schrieb:
Hello!
I would like to propose a new package, mlcscope for cygwin. I would like
to become the maintainer of this package. I have resolved the issues
that Reini raised and am ready for another try...
I'm including the setup.hint:
$ cat setup.hint
# comment
sdesc: Lucent version of cscope for multiple languages (mlcscope)
ldesc: Lucent version of cscope for multiple languages (mlcscope).
mlcscope is a source code browser tool allowing developers to simplify
searching source code. mlcscope differs from cscope by using
separate parsers for C/C++ and Java. mlcscope is developed by
Lucent Technologies.
requires: cygwin libncurses8
category: Devel
As far as I am aware, mlcscope is not available in any major Linux
distribution.
I have placed the packages to be reviewed at
http://www.lowtechnet.com/cscope :
http://www.lowtechnet.com/cscope/mlcscope-14.1.8-1-src.tar.bz2
http://www.lowtechnet.com/cscope/mlcscope-14.1.8-1.tar.bz2
http://www.lowtechnet.com/cscope/setup.hint
[no GTG] There's still no README in CYGWIN-PATCHES and no instructions
how to build from src. You have to look into the binary packaged
/usr/share/doc/Cygwin/mlcscope-14.1.8.README to get a hint.
[good] The binary is now correspondent to cscope, that is does recurse
into the given dir to scan for all know sourcefile extensions.
Previously you had to prepend this with a find pipe, which was awkward
given that it should have known about multiple languages.
[minor] There's still the empty homepage dir in the src pkg and also
under src/homepage.
[no GTG] Following the build instructions in mlcscope-14.1.8.README:
From /usr/src unpack mlcscope-X-src.tar.bz2
if you use setup to install this src package, it will be
unpacked under /usr/src automatically
cd /usr/src/mlcscope-X/src
make build install
$ tar xfj mlcscope-14.1.8-1-src.tar.bz2
$ cd mlcscope-14.1.8-1/src
$ make build
make: *** No rule to make target `build'. Stop.
That has to fixed into
cd /usr/src/mlcscope-X
make build install
[minor] We prefer now to have the html docs in
/usr/share/doc/mlcscope-14.1.8/html
So please fix the README and add it to the src package.
BTW: It still would be much easier to use cygport.
The cscope-15.5-1.cygport file is this:
DESCRIPTION=developer's tool for browsing source code
HOMEPAGE=http://cscope.sourceforge.net/;
SRC_URI=http://puzzle.dl.sourceforge.net/sourceforge/cscope/${PN}-${PV}.tar.gz;
cygport cscope-15.5-1.cygport get almostall
--
Reini
Re: [ITP] fcgi-2.4.0-1
Max Bowsher schrieb: Reini Urban wrote: Max Bowsher schrieb: Reini Urban wrote: I want to contribute and maintain the fastcgi library. I compiled it just as static library, which is useful for apache2, lighttpd, ruby, php and clisp. Maybe I might be persuaded to maintain a dll (libfcgi0) also. I do not see how it would be useful for apache2. Why a static library? To gain the benefits of smaller overall package size, and of not needing to rebuild dependent packages to pick up new library versions, I'd suggest _only_ shipping a DLL. Well I was toying with this plan also. But found out that linux packages don't use it. fcgi is not a enduser package, only a developer library to enable several packages to cooperate in a different way, so I prefered to keep everything together and let packages link the lib statically. This way upgrades and conflict resolutions only have to be made on protocol changes, not software upgrades. I don't understand this at all. *Lots* of non-enduser software is provided as DLLs. I don't understand what you mean by upgrades and conflict resolutions in particular. To my mind, a DLL is strongly preferable, because all packages using the library pick up any fixes automatically, instead of requiring a recompilation themselves. fcgi does not build out of the box as shared library on any target. Almost no other distro has or uses the shared library. So why should we? In my reasoning which is unfortunately not english enough I also explained my private POV which makes sense at least to me. E.g. mandrake, suse and PLD have their mod_fastcgi.so without libfcgi dependency, linked statically. debian's libapache2-mod-fastcgi_2.4.2 also. mandrake's php-fgci also, all clisp's also. haven't looked further. http://rpmseek.com/rpm/php-fcgi-5.1.2-1mdk.i586.html?hl=decs=fcgi:PN:0:0:1:0:2604182 Sorry, but the above is entirely wrong. mod_fastcgi does not use libfcgi at all. Sorry, but the above is entirely wrong. mod_fastcgi does use libfcgi as silent build requirement, and is not listed in the reqs because it is linked statically. Which is my point. Same for most other packages. Say a standalone /usr/lib/apache2/mod_fastcgi.so for apache2-mod_fastcgi or /usr/lib/apache/mod_fastcgi.dll for apache-mod_fastcgi, without libfcgi0 require, talking to a fcgi enabled ruby, clisp or php. clisp being the only cygwin package so far which actually has it enabled. What are you trying to say? The above paragraph isn't meaningful English. Sorry. My native lingua is german. The other reason is this: I don't only develop on cygwin, I also run business services like clisp or xapian and swish cgi's with cygwin1.dll, but I wouldn't bother to use the cygwin apache. For testing and development it's great, similar to postgresql. So I don't want to mix a native apache-mod_fastcgi with a cygwin fcgi using a shared libfcgi0. Makes no sense. The above paragraph makes no sense, too. /var/www/ is not a natural location, in my opinion. It is certainly NOT a good location on Cygwin to install anything that is webserver-agnostic, as it has a long tradition of being associated with the Apache 1.3 package. The latest FHS is fairly emphatic about service data belonging in /srv/, not /var/. Not /usr/share/. You should put them in /usr/lib/fcgi/examples/. Ok. Done. I usually run fcgi's and cgi's on win32-native apache2 and lighttpd. How is this relevant to the Cygwin package layout? For that user scenario where native apache and/or cygwin lighttpd has to deal with a cygwin fcgi. fcgi upgrades and breakage are dependend on developers decisions only if linked statically. -- Reini
Re: [ITP] fcgi-2.4.0-1
Reini Urban wrote: Max Bowsher schrieb: To my mind, a DLL is strongly preferable, because all packages using the library pick up any fixes automatically, instead of requiring a recompilation themselves. fcgi does not build out of the box as shared library on any target. Almost no other distro has or uses the shared library. So why should we? In my reasoning which is unfortunately not english enough I also explained my private POV which makes sense at least to me. OK, the fact that upstream does not is a fairly good reason. However, Debian does ship a shared library, so we would not be alone in doing so if we decided to. I suggest that if it is reasonably easy to get a DLL to build, then we should have a DLL, and no static library, in the distribution, because of the eased maintenance (dependencies always use the current library, not what was current when they were built). If, on the other hand, it is infeasibly difficult to get a DLL building, we could live with just a static library. E.g. mandrake, suse and PLD have their mod_fastcgi.so without libfcgi dependency, linked statically. debian's libapache2-mod-fastcgi_2.4.2 also. mandrake's php-fgci also, all clisp's also. haven't looked further. http://rpmseek.com/rpm/php-fcgi-5.1.2-1mdk.i586.html?hl=decs=fcgi:PN:0:0:1:0:2604182 Sorry, but the above is entirely wrong. mod_fastcgi does not use libfcgi at all. Sorry, but the above is entirely wrong. mod_fastcgi does use libfcgi as silent build requirement, and is not listed in the reqs because it is linked statically. Which is my point. Same for most other packages. Please go check your facts before you cast my words back at me. mod_fastcgi does *NOT* use libfcgi - a fact I have verified by building mod_fastcgi successfully, without having libfcgi installed at all. Say a standalone /usr/lib/apache2/mod_fastcgi.so for apache2-mod_fastcgi or /usr/lib/apache/mod_fastcgi.dll for apache-mod_fastcgi, without libfcgi0 require, talking to a fcgi enabled ruby, clisp or php. clisp being the only cygwin package so far which actually has it enabled. What are you trying to say? The above paragraph isn't meaningful English. Sorry. My native lingua is german. That's fine, but could you try to rephrase what you are trying to say, since you obviously consider the underlying point to be important. The other reason is this: I don't only develop on cygwin, I also run business services like clisp or xapian and swish cgi's with cygwin1.dll, but I wouldn't bother to use the cygwin apache. For testing and development it's great, similar to postgresql. So I don't want to mix a native apache-mod_fastcgi with a cygwin fcgi using a shared libfcgi0. Makes no sense. The above paragraph makes no sense, too. Please do try to clarify this, as well. I'm especially confused about how native-windows versions have any relevance to the Cygwin packaging. I usually run fcgi's and cgi's on win32-native apache2 and lighttpd. How is this relevant to the Cygwin package layout? For that user scenario where native apache and/or cygwin lighttpd has to deal with a cygwin fcgi. fcgi upgrades and breakage are dependend on developers decisions only if linked statically. Again, please clarify, I don't understand the problem here. To the best of my knowledge, FastCGI is a fixed and unchanging protocol - upgrades should be bugfixes only and should not cause breakage. Max. signature.asc Description: OpenPGP digital signature
Re: [ITP] mlcscope-14.1.8 (Attempt 2)
On Sun, Aug 06, 2006 at 04:25:27PM +0200, Reini Urban wrote: Dave Diane schrieb: Hello! I would like to propose a new package, mlcscope for cygwin. I would like to become the maintainer of this package. I have resolved the issues that Reini raised and am ready for another try... I'm including the setup.hint: $ cat setup.hint # comment sdesc: Lucent version of cscope for multiple languages (mlcscope) ldesc: Lucent version of cscope for multiple languages (mlcscope). mlcscope is a source code browser tool allowing developers to simplify searching source code. mlcscope differs from cscope by using separate parsers for C/C++ and Java. mlcscope is developed by Lucent Technologies. requires: cygwin libncurses8 category: Devel As far as I am aware, mlcscope is not available in any major Linux distribution. I have placed the packages to be reviewed at http://www.lowtechnet.com/cscope : http://www.lowtechnet.com/cscope/mlcscope-14.1.8-1-src.tar.bz2 http://www.lowtechnet.com/cscope/mlcscope-14.1.8-1.tar.bz2 http://www.lowtechnet.com/cscope/setup.hint [no GTG] There's still no README in CYGWIN-PATCHES and no instructions how to build from src. You have to look into the binary packaged /usr/share/doc/Cygwin/mlcscope-14.1.8.README to get a hint. Please excuse my ignorance but have we gotten the requisite number of votes for this package? I'm just mentioning this to set expectations. I don't want anyone to assume that a GTG would mean inclusion in the distribution if we haven't gotten the right number of votes. cgf
[ITP] fcgi-2.4.0-2
Following the discussion with Max, I got persuaded to do the shared lib also. It required only the typical AM_LDFLAGS=-no-undefined, and some praying and hackery, that the PATH within libtool install will not be exhausted to build the examples binaries. So please consider the following new files: http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2-src.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/fcgi-2.4.0-2.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/setup.hint http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/libfcgi0-2.4.0-2.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi0/setup.hint http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/libfcgi-devel-2.4.0-2.tar.bz2 http://xarch.tu-graz.ac.at/publ/cygwin/release/fcgi/libfcgi-devel/setup.hint Max Bowsher schrieb: Reini Urban wrote: Max Bowsher schrieb: To my mind, a DLL is strongly preferable, because all packages using the library pick up any fixes automatically, instead of requiring a recompilation themselves. fcgi does not build out of the box as shared library on any target. Almost no other distro has or uses the shared library. So why should we? In my reasoning which is unfortunately not english enough I also explained my private POV which makes sense at least to me. OK, the fact that upstream does not is a fairly good reason. However, Debian does ship a shared library, so we would not be alone in doing so if we decided to. I suggest that if it is reasonably easy to get a DLL to build, then we should have a DLL, and no static library, in the distribution, because of the eased maintenance (dependencies always use the current library, not what was current when they were built). If, on the other hand, it is infeasibly difficult to get a DLL building, we could live with just a static library. E.g. mandrake, suse and PLD have their mod_fastcgi.so without libfcgi dependency, linked statically. debian's libapache2-mod-fastcgi_2.4.2 also. mandrake's php-fgci also, all clisp's also. haven't looked further. http://rpmseek.com/rpm/php-fcgi-5.1.2-1mdk.i586.html?hl=decs=fcgi:PN:0:0:1:0:2604182 Sorry, but the above is entirely wrong. mod_fastcgi does not use libfcgi at all. Sorry, but the above is entirely wrong. mod_fastcgi does use libfcgi as silent build requirement, and is not listed in the reqs because it is linked statically. Which is my point. Same for most other packages. Please go check your facts before you cast my words back at me. mod_fastcgi does *NOT* use libfcgi - a fact I have verified by building mod_fastcgi successfully, without having libfcgi installed at all. So it includes a static version. I said most packages have no dependency for a shared libfcgi, besides debian. Say a standalone /usr/lib/apache2/mod_fastcgi.so for apache2-mod_fastcgi or /usr/lib/apache/mod_fastcgi.dll for apache-mod_fastcgi, without libfcgi0 require, talking to a fcgi enabled ruby, clisp or php. clisp being the only cygwin package so far which actually has it enabled. What are you trying to say? The above paragraph isn't meaningful English. Sorry. My native lingua is german. That's fine, but could you try to rephrase what you are trying to say, since you obviously consider the underlying point to be important. The other reason is this: I don't only develop on cygwin, I also run business services like clisp or xapian and swish cgi's with cygwin1.dll, but I wouldn't bother to use the cygwin apache. For testing and development it's great, similar to postgresql. So I don't want to mix a native apache-mod_fastcgi with a cygwin fcgi using a shared libfcgi0. Makes no sense. The above paragraph makes no sense, too. Please do try to clarify this, as well. I'm especially confused about how native-windows versions have any relevance to the Cygwin packaging. I usually run fcgi's and cgi's on win32-native apache2 and lighttpd. How is this relevant to the Cygwin package layout? For that user scenario where native apache and/or cygwin lighttpd has to deal with a cygwin fcgi. fcgi upgrades and breakage are dependend on developers decisions only if linked statically. Again, please clarify, I don't understand the problem here. To the best of my knowledge, FastCGI is a fixed and unchanging protocol - upgrades should be bugfixes only and should not cause breakage. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ fcgi -- FastCGI A High-Performance Gateway Interface. Static library and a cgi-wrapper to create fastcgi enabled applications. End users will most likely not need that. FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI without introducing any of the new problems associated with writing applications to lower-level Web server APIs. Modules to support FastCGI can
call for testing of latest setup.exe snapshot
I've just uploaded http://cygwin.com/setup/snapshots/setup-2.551.exe. If you had experienced any problems with previous versions please try this one and report if it solves your issue or not. The above is CVS HEAD as of this moment. I committed several outstanding patches (sorry for the huge delay Igor!) and have tried to round up all or most of the remaining outstanding patches/reported problems below. I wanted to put everything in one thread instead of continuing a bunch of individual threads. Sorry if this breaks up the discussion too much. (Of course there were many more things in the feature request pile but that is another matter.) http://www.cygwin.com/ml/cygwin/2006-05/msg00594.html Null dereference in new_cstr_char_array. This was already fixed in CVS on 2006-03-14. http://cygwin.com/ml/cygwin-apps/2006-02/msg00124.html Stray debugging messagebox removed. http://cygwin.com/ml/cygwin-apps/2006-02/msg00099.html So, we have a couple of issues here. Firstly, the bug/unintended feature of -r causing the infinite retries until the file can be written (if I understand correctly.) Second the patch by Igor that adds a dialog when trying to replace an in-use file. Here is my opinion on the matter: I like the dialog idea, but I don't think having Abort as an option is appropriate, as it will potentially cause a really screwed up install, plus it was left unimplemented in the patch submitted. So let's just have two options: Retry and Replace on Reboot. I know that this means we can't use the stock Abort/Retry/Ignore dialog but I think it's worth it for clarity. After we have that, we should fix the tar extraction bug with -r. http://www.cygwin.com/ml/cygwin-apps/2006-01/msg00190.html Parsing of installed.db. I don't really see that this matters a whole lot but it's certainly silly to have setup trying to read fields that don't exist so I applied this (with minor updates to account for std::string changes.) http://cygwin.com/ml/cygwin-apps/2006-01/msg00204.html Package validation exception. As I said in the thread, I dislike the idea of pretending that invalid files don't exist without some kind of error, and the specific case I was thinking of was a user who downloads and installs in two separate steps. If a file obtained during the download step turns out to be corrupt/wrong size, then during install from local directory it will simply be silently omitted from the package list, which might be rather confusing if it's something important. Even if the automatic dependency checking page flags a problem it is still not something the user can fix -- it will say select this package! but that package does not exist to be selected and cannot be installed anyway. Still, since I nor anyone else has come up with anything better, and because an unhandled exception is pretty ghastly, I've applied Igor's patch. In the future I would like to augment this with a warning of some kind if the user is in Install from local directory mode, but I guess that will have to wait. http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00070.html -p option to specify packages to add. I think I must have missed this patch the first time it was posted but I reviewed it here: http://www.cygwin.com/ml/cygwin-apps/2006-07/msg8.html If the submitter can fix the minor points raised I think it's fine for inclusion. I don't have a URL Background color issues. These should have been fixed for some time, but a newer snapshot was never made. Bottom line: If we can finish off the Retry/Replace file-in-use thing and assuming there are no reports of new issues with this snapshot then I think we can push out a release. Brian
Re: running cygwin bash scripts from apache
Thank you Rene and Max for your replies. Rene's response did the trick: Did you put the script in Apache's cgi-bin directory? Once I put it there, the script works ok. Much to my relief. Thanks for the tip that I can configure Apache to run scripts from other places to - that might come in handy later. Are you using the Apache packaged with Cygwin, or some other Windows Apache? And, what version of Apache? Max, I have Apache 2.0.55 for Windows installed - I thought I needed the Cygwin version, but it turns out the Windows version is still ok to run Bash scripts as long as it has the right shebang line. Thank you both! Rob :) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] clisp-2.39-1 released
Dr. Volker Zell schrieb: Reini Urban writes: I've taken over clisp maintainance from Sam Steingold, who lost access to his windows box and to this list. Thanks Sam for a wonderful job anyway! clisp-2.39-1 is now built with cygport, but you can still compile it with ./configure; make; make install also. ./configure --fsstnd=redhat --with-dynamic-ffi \ --with-module=rawsock --with-module=dirkey \ --with-module=bindings/win32 --with-module=berkeley-db \ --with-module=pcre --with-module=postgresql \ --with-module=fastcgi --prefix=/usr --build build What about the zlib module, it used to be included in the last version. Yes, you are right. I missed that. $ clisp -q -E 1:1 -K full -norc -x '*FEATURES*' (:FASTCGI :POSTGRESQL :PCRE :BERKELEY-DB :DIRKEY :RAWSOCK :READLINE :REGEXP :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :SOCKETS :GENERIC-STREAMS :LOGICAL-PATHNAMES :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :PC386 :UNIX :CYGWIN) Furthermore setup.hint is also wrong, because I listed it there. Will be updated ASAP. I'll update the automatic README and setup.hint creation also. -- Reini -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Checking XCOPY Exit Value in Cygwin Bash
Hi all,
I am writing a automated build script for my project that will be run
under cygwin. I will copy my updated source files to the build directory and if
there are updated files, the executables will be built. To copy the source
files, I had to use XCOPY since the directory structure should be preserved in
the destination directory also. To copy only the updated files, I used the /D
switch for XCOPY. Now since I want to execute the source compile only if files
in the build directory have been updated, I have to use the exit codes of XCOPY
inside the script. I tried checking the value of $! after executing XCOPY but
it didnt work. I couldn't find a solution in the internet too. Currently I am
piping the standard output to a file and checking if the number of files copied
is 0 or not. But I think this is not an elegant solution. This is what I am
doing now.
[script]
copied=false
# Helper Function
copy_files()
{
echo copying *.$1 files in $2 to $3\\$2
xcopy /DSYI $2\\*.$1 $3\\$2 | tee copy.log
while read amount ; do
if [ ${amount::1} != 0 ]; then
copied=true;
fi
done copy.log
}
cd ../source
copy_files h. ..\\build
copy_files c. ..\\build
copy_files cpp . ..\\build
rm -f copy.log
! $copied echo Files up-to-date. Skipping build exit 0
cd ../build
# Start the Build Process
[/script]
Can you please provide me a way of checking the XCOPY exit code: reference
[http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true]
within Bash?
Thank you for your time.
Shane
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
On Sun, 6 Aug 2006, Shane wrote:
Hi all,
Hi. http://cygwin.com/acronyms/#PCYMTWLL. Reading the one-line below
was extremely painful in the web archives. See for yourself:
http://cygwin.com/ml/cygwin/2006-08/msg00169.html.
I am writing a automated build script for my project that will be
run under cygwin. I will copy my updated source files to the build
directory and if there are updated files, the executables will be built.
To copy the source files, I had to use XCOPY since the directory
structure should be preserved in the destination directory also.
Nope, you didn't have to. Something like
(cd $2/.. find $2 -name *.$1 | tar cfT - -) | tar xfC - $3
would do the job of XCOPY /S using POSIX means.
To copy only the updated files, I used the /D switch for XCOPY.
If you go POSIX, you can use the --keep-newer-files tar option.
Now since I want
to execute the source compile only if files in the build directory have
been updated, I have to use the exit codes of XCOPY inside the script. I
tried checking the value of $! after executing XCOPY but it didnt work.
Of course it didn't. Please read a good bash tutorial, or the Special
Parameters section of the bash manpage.
I couldn't find a solution in the internet too. Currently I am piping
the standard output to a file and checking if the number of files copied
is 0 or not. But I think this is not an elegant solution. This is what I
am doing now.
[script]
copied=false
# Helper Function
copy_files()
{
echo copying *.$1 files in $2 to $3\\$2
xcopy /DSYI $2\\*.$1 $3\\$2 | tee copy.log
while read amount ; do
if [ ${amount::1} != 0 ]; then
copied=true;
fi
done copy.log
}
cd ../source
copy_files h. ..\\build
copy_files c. ..\\build
copy_files cpp . ..\\build
rm -f copy.log
! $copied echo Files up-to-date. Skipping build exit 0
cd ../build
# Start the Build Process
[/script]
Can you please provide me a way of checking the XCOPY exit code:
reference
[http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true]
within Bash?
It's just like checking any other exit code in bash: reference man bash.
HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte.
But no -- you are no fool; you call yourself a fool, there's proof enough in
that! -- Rostand, Cyrano de Bergerac
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
On 8/6/06, Shane wrote: Can you please provide me a way of checking the XCOPY exit code: reference [http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true] within Bash? result codes are stored in $? in bash success = 0 usually, and xcopy seems to follow the norm here. here, i did xcopy somefile somedir echo $? which returned 0 when i tried xcopy nonfile somedir echo $? i get 4 so test for 0 for success. extensions of this idea: xcopy somefile somedir echo ok xcopy somefile somedir || echo fail -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: NTFS fragmentation
-Original Message- From: Robert Pendell Sent: Saturday, August 05, 2006 7:50 PM To: Cygwin Mailing List Subject: Re: NTFS fragmentation Vladimir Dergachev wrote: Also, I tried the following experiment - found a 17 MB file in ibiblio.org and downloaded it with Firefox. The file ended up fragmented into more than 200 pieces. Tried the same file with IE - no fragmentation. It could be, of course, that Firefox is compiled with cygwin, but I have not found cygwin.dll anywhere in its installation directory. IE moves the files from your Temporary Internet Files to where your defined destination is once the download is complete. Firefox however skips that and just writes it to the destination. That is why you see the fragmentation in Firefox and not IE. The move that IE does isn't always noticeable. The box will only come up if it takes more than a few seconds but occasionally you see it say Moving FILE from Temporary Internet Files to DEST (replacing FILE and DEST as appropriate). The message is probably different but you get the idea. -- Robert Pendell [EMAIL PROTECTED] Thawte Web of Trust Notary CAcert Assurer When you actually open the file using IE, it just downloads the file into Temporary Internet Files and opens it. But in Fx, it downloads it into the preset folder, but when it is just about to open, it moves the file into the temp folder (C:\Documents and Settings\cygwin\Local Settings\temp (replace cygwin as your username), then opens it. --- Sure, Fx is compiled USING cygwin but not using GCC. The build is driven by a makefile (using make) and configure (autoconf-2.13), but the tools are Microsoft Visual C++ tools found in C:\Program Files\Microsoft Visual Studio\VC\bin\. Those tools are cl (compiler), link (linker), rc (resource compiler), and vcvars32.bat (environment setup). Charli -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
Igor Peshansky wrote: Nope, you didn't have to. Something like (cd $2/.. find $2 -name *.$1 | tar cfT - -) | tar xfC - $3 would do the job of XCOPY /S using POSIX means. If you go POSIX, you can use the --keep-newer-files tar option. Of course it didn't. Please read a good bash tutorial, or the Special Parameters section of the bash manpage. Hi Igor and Mark, Thank you very much for the quick reply. I was initially using tar -cf - `find $source_dir -name *.$file_ext -print` | ( cd $dest_dir tar xBf - ) but it had a problem with path names with spaces. Obviously being not that good in bash scripting, I couldn't get over that issue. So that was why I decided to use the XCOPY command. I will use your method and see. Thanks again. I made a silly mistake in my former email. I was actually checking $? (not $!) for the exit code, but it didn't work. But I saw in a later reply from Mark that it worked for him. I will check it again. Maybe I was doing something silly. thanks again Regards Shane -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Checking XCOPY Exit Value in Cygwin Bash
Shane wrote: I am writing a automated build script for my project that will be run under cygwin. I will copy my updated source files to the build directory and if there are updated files, the executables will be built. To copy the source files, I had to use XCOPY since the directory structure should be preserved in the destination directory also. To copy only the updated files, I used the /D switch for XCOPY. Now since I want to execute the source compile only if files in the build directory have been updated, I have to use the exit codes of XCOPY inside the script. There are standard software development tools that solve the problems you are facing -- CVS and Make: http://ximbiot.com/cvs/wiki/index.php?title=Main_Page http://ximbiot.com/cvs/wiki/index.php?title=Main_Page Both are included in Cygwin. In the long run, you'd be better off investing in a basic to intermediate understanding of both rather than hacking together custom scripts to implement a subset of their functionality. David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
David Christensen wrote: There are standard software development tools that solve the problems you are facing -- CVS and Make: http://ximbiot.com/cvs/wiki/index.php?title=Main_Page http://ximbiot.com/cvs/wiki/index.php?title=Main_Page Both are included in Cygwin. In the long run, you'd be better off investing in a basic to intermediate understanding of both rather than hacking together custom scripts to implement a subset of their functionality. To David, Thank you for the tip. Actually I am using Visual Source Safe as the Source Management tool. I was considering the use of CVS, but decided against at the last moment because most of the fellow developers including me, had been using VSS for a considerable amount of time, and felt that the migration from a VSS to CVS would take a some time. Similarly for Make. We are primarily a group of developers who are conversent with MS Windows than the Unix environment. Cygwin basically gives us the power of bash scripting and the ease of Windows at the same time. :) What I am trying to do is, checkout the source to the build directory and if there are any local changes in my working directory copy them to the build directory, build and do a test run from there. This is so that I can test my code before I do the actual check in. To Igor, Your method worked perfectly for paths with spaces too. :) Now if only I had a way of detecting if files were updated or not. To Mark I tried it again. Unfortunately echo $? gives 0 for both the cases of, number of files copied = 0 and, greater than 0. The link I posted from MSDN http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true says that XCOPY returns 1 when there were no files to be copied. So I guess I am back to square one. :( Thanks and best regards Shane GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music online! Visit http://www.inbox.com/storage to find out more! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: installer: select packages: text background color
Greetings: A display bug was introduced about a year ago in the Select Packages screen of Cygwin's installer. The text's background color is manually set to white but the text's color relies upon the system's settings for Window Text. No one has noticed this change because most users have their Window background color set to white and their Window Text color set to black. But, for people who have other preferences for their Windows Display options, like myself, this can cause problems. For example, here's what I see when I run the installer: http://www.analysisandsolutions.com/cygwin/cygwin.setup.png Kind of hard to read the list of programs, eh? :) To demonstrate that the Window Text is the color being used, I changed that setting to red in Control Panel | Display | Appearance: http://www.analysisandsolutions.com/cygwin/cygwin.setup.red.png Also note, that the Window Text color is being used for the text around the program listing, such as Select packages to install and Hide obsolete and administrative packages when it would be programatically more correct to use the Message Box/Message Text color. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: installer: select packages: text background color
A display bug was introduced about a year ago in the Select Packages screen of Cygwin's installer. The text's background color is manually set to white but the text's color relies upon the system's settings for Window Text. This bug was also reported about a year ago, and fixed about a year ago. See http://cygwin.com/setup/snapshots/ for a snapshot with the fix incorporated, and then join the crusade to get the snapshot tested to the point that it can be released as the next stable version of setup.exe. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: installer: select packages: text background color
On Sun, Aug 06, 2006 at 06:46:52PM +, Eric Blake wrote: This bug was also reported about a year ago, and fixed about a year ago. Great, thanks. See http://cygwin.com/setup/snapshots/ for a snapshot with the fix incorporated, and then join the crusade to get the snapshot tested to the point that it can be released as the next stable version of setup.exe. Tried it and the following errors came up: vv setup-2.529.exe - Application Error The instruction at 0x78010adf referenced memory at 0x. The memory could not be read. I then hit cancel to debug... ^^ vv Just-In_Time Debugging An exception 'Unhandled Win32 Exception' has occurred in setup-2.529.exe However, no debuggers are registered that can debug this exception. ^^ --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
On Mon, 7 Aug 2006, Shane wrote: What I am trying to do is, checkout the source to the build directory and if there are any local changes in my working directory copy them to the build directory, build and do a test run from there. This is so that I can test my code before I do the actual check in. As David said, cvs has an easy way of doing this (using cvs diff and patch), which will also deal with local and checked in changes to the same file (while your method won't). To Igor, Your method worked perfectly for paths with spaces too. :) It was designed to. :-) Now if only I had a way of detecting if files were updated or not. Did you happen to notice the mention of the --keep-newer-files tar option in my original reply to you? Just add that to the last tar, and you will only copy the files that were changed in your copy (presumably by you) after the checked in version. To Mark I tried it again. Unfortunately echo $? gives 0 for both the cases of, number of files copied = 0 and, greater than 0. The link I posted from MSDN http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/xcopy.mspx?mfr=true says that XCOPY returns 1 when there were no files to be copied. MSDN apparently lies. XCOPY for me returns non-zero on error, and 0 on normal execution (no matter how many files were copied). So I guess I am back to square one. :( There are quite a few POSIX and Unix tools that are much better for this job than xcopy. I'd say investing some time in a Unix tutorial now would save you more effort in the long run. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
On Sun, Aug 06, 2006 at 07:46:07AM -0800, Shane wrote: I am writing a automated build script for my project that will be run under cygwin. I will copy my updated source files to the build directory and if there are updated files, the executables will be built. To copy the source files, I had to use XCOPY since the directory structure should be preserved in the destination directory also. To copy only the updated files, I used the /D switch for XCOPY. Now since I want to execute the source compile only if files in the build directory have been updated, I have to use the exit codes of XCOPY inside the script. I tried checking the value of $! after executing XCOPY but it didnt work. I couldn't find a solution in the internet too. Currently I am piping the standard output to a file and checking if the number of files copied is 0 or not. But I think this is not an elegant solution. This is what I am doing now. Is there some reason why you are not using cp to accomplish your task? cp --help should provide you with all sorts of options for copying files. You should be able to press cp into service for this. Using DOS utilities and DOS paths for this type of thing is putting you on the fringes of support for Cygwin. I really wouldn't recommend it. Clearly this is not such a Windows-specific problem that it outside of the capabilities of a UNIX solution. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: installer: select packages: text background color
On Sun, 6 Aug 2006, Eric Blake wrote: A display bug was introduced about a year ago in the Select Packages screen of Cygwin's installer. The text's background color is manually set to white but the text's color relies upon the system's settings for Window Text. This bug was also reported about a year ago, and fixed about a year ago. See http://cygwin.com/setup/snapshots/ for a snapshot with the fix incorporated, and then join the crusade to get the snapshot tested to the point that it can be released as the next stable version of setup.exe. This would be a good sentiment if the setup snapshots on that page were recent enough to warrant testing. However, before we can start the above crusade, we have to embark on a crusade for getting a more recent setup snapshot out. Max or Brian, would it be possible to produce one and post it to setup/snapshots? It's been overdue for a while (2.529 is 5 months old). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
Igor Peshansky wrote:
As David said, cvs has an easy way of doing this (using cvs diff and
patch), which will also deal with local and checked in changes to the
same file (while your method won't).
Point taken. I will certainly look into it.
Did you happen to notice the mention of the --keep-newer-files tar
option in my original reply to you? Just add that to the last tar, and
you will only copy the files that were changed in your copy (presumably by
you) after the checked in version.
Yeah I saw that reply and I had tried it. There were two problems.
1. New files will not be added to the build directory. It will say
something like
tar: ./Test/res/Test.manifest: Warning: Cannot stat: No such
file or directory
tar: Current `./Test/res/Test.manifest' is newer
and the required manifest file is not copied into the build
folder. So for the initial copy I have to
use it without the --keep-newer-files, and for the subsequent
copies I will have to use the --keep-newer-files.
2. This is the real problem. That is getting an indication whether
none of the files were updated or not. I want to proceed
with the rest of the building script only if more than one files have
been copied. I do not know how to get that using the tar
command. I tried echoing the $? value but it gives 0 all the time. The
source compiler can
detect if the sources were updated or not, on it's own, but
there are a lot of projects in one Visual Studio
Solution (about 60), that I can't wait until all those projects
have been parsed.
I am using
while read amount ; do
if [ ${amount::1} != 0 ]; then
copied=true;
fi
done copy.log
for that purpose.
MSDN apparently lies. XCOPY for me returns non-zero on error, and 0 on
normal execution (no matter how many files were copied).
If that is the case, then there is no point in trying to check for the
xcopy return value.
As a short term solution I will stick with my original XCOPY solution.
But I will try to find out
what CVS, Make and the other tools have to offer. If there is a way of
getting if files have been replaced using the
tar command, I will try to implement that into my solution.
Although I am fairly competent at programming in C/C++, this is my first
attempt in writing a serious bash script,
and I must admit that I am both impressed and overwhelmed by it's power. :)
Thank you all for the help offered so far.
Regards
Shane
GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music
online!
Visit http://www.inbox.com/storage to find out more!
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
Christopher Faylor wrote: Is there some reason why you are not using cp to accomplish your task? cp --help should provide you with all sorts of options for copying files. You should be able to press cp into service for this. Using DOS utilities and DOS paths for this type of thing is putting you on the fringes of support for Cygwin. I really wouldn't recommend it. Clearly this is not such a Windows-specific problem that it outside of the capabilities of a UNIX solution. My initial attempt was with cp. But I didn't see a way of preserving the original directory structure of the source dir, inside the destination directory. XCOPY just seemed easier. Will have a go at 'cp' again. Thanks and regards Shane -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
On Mon, Aug 07, 2006 at 06:52:40AM +0900, Shane wrote: Christopher Faylor wrote: Is there some reason why you are not using cp to accomplish your task? cp --help should provide you with all sorts of options for copying files. You should be able to press cp into service for this. Using DOS utilities and DOS paths for this type of thing is putting you on the fringes of support for Cygwin. I really wouldn't recommend it. Clearly this is not such a Windows-specific problem that it outside of the capabilities of a UNIX solution. My initial attempt was with cp. But I didn't see a way of preserving the original directory structure of the source dir, What's wrong with cp -a or cp -r? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
What's wrong with cp -a or cp -r? It only copied files that were directly under the source directory. It didn't traverse the directories inside source recursively. I did some searching and, I came up with a similar thread. Finally the tar method was recommended in it too. Please refer : http://lists.samba.org/archive/samba/1999-December/016328.html and it's follow-ups. Thanks and Regards Shane -Original Message- From: [EMAIL PROTECTED] Sent: Sun, 6 Aug 2006 21:04:27 -0400 To: cygwin@cygwin.com Subject: Re: Checking XCOPY Exit Value in Cygwin Bash On Mon, Aug 07, 2006 at 06:52:40AM +0900, Shane wrote: Christopher Faylor wrote: Is there some reason why you are not using cp to accomplish your task? cp --help should provide you with all sorts of options for copying files. You should be able to press cp into service for this. Using DOS utilities and DOS paths for this type of thing is putting you on the fringes of support for Cygwin. I really wouldn't recommend it. Clearly this is not such a Windows-specific problem that it outside of the capabilities of a UNIX solution. My initial attempt was with cp. But I didn't see a way of preserving the original directory structure of the source dir, What's wrong with cp -a or cp -r? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Checking XCOPY Exit Value in Cygwin Bash
On Sun, Aug 06, 2006 at 08:26:11PM -0800, Shane wrote: What's wrong with cp -a or cp -r? It only copied files that were directly under the source directory. It didn't traverse the directories inside source recursively. I did some searching and, I came up with a similar thread. Finally the tar method was recommended in it too. Please refer : http://lists.samba.org/archive/samba/1999-December/016328.html and it's follow-ups. 1999 archives in a non-cygwin mailing list? No, thank you. I have used cp -a and cp -r any number of times with success on cygwin. However, if cp is not working correctly, I'm sure the coreutils maintainer would be interested in fixing it, if you have further details. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
