When up2date is run and no new packages are available it return non-zero return code (1). This is bad as this mean that up2date run with an error (like overloaded RHN server, DNS error, no route to host etc). In this case (Message: "None of the packages you requested were found, or they are already updated.") up2date should return 0 (ie success) or different code than 1 (one). Current behaviour is almost unusable.
up2date is designed to be used as an interactive application, so fine grained exit status values are not generally a priority. rhnsd/rhn_check is designed for non-interactive use. I'll take a look at improving the exit codes, but it's a fairly low priority.
Here is a patch to fix clean exit code when no packages are available for update: --- /usr/sbin/up2date.orig Tue Oct 8 23:36:53 2002 +++ /usr/sbin/up2date Sat Nov 2 12:30:22 2002 @@ -755,7 +755,8 @@ # raise up2dateErrors.SkipListError("The following packages were on your skip list and could not be installed: %s" % skippedPackagesPkgSkipList, skippedPackagesPkgSkipList) # if len(skippedPackagesFileConfigSkipList): # raise up2dateErrors.FileConfigSkipListError("The following packages were on your skip list and could not be installed: %s" % skippedPackagesFileConfigSkipList, skippedPackagesFileConfigSkipList) - return 1 + # We have nothing to update so this is clean exit + return 0 #FIXME:? should batch run do this itself? if len(batch.depPackages):
I underestand that there could be a lot of fine-grained exit codes. This patch solve only current implementation: return 0 or 1 (clean exit and exit with an error). This could satisfy almost all cases of possible in-script use and breaks nothing I hope.
Hmm, I'll change this. I'm not completety convinced that returning 0 in this case is correct (and in some cases, it could be wrong). But I'll change it and see if anyone complains. It's a fairly indeterminate state to exit from... should be changed in version 3.0.15 or newer
Change confirmed in up2date-3.1.15-7.