Am Donnerstag, 7. August 2003 18:57 schrieb Thorsten Kampe:
> * Michael Schreckenbauer (2003-08-07 16:37 +0200)
>
> > Am Donnerstag, 7. August 2003 16:15 schrieb Thorsten Kampe:
> >> I have a vcron job[1] that syncs the portage tree und afterward
> >> fetches available updates - at least that's how it is supposed to
> >> work. The sync works fine and the fetch, too, at least according to
> >> /var/log/emerge.log[2].
> >>
> >> But actually the .tar.bz never reaches /usr/portage/distfiles, so I
> >> have to execute "emerge -fuD world" manually. This happens with all
> >> updates!
> >>
> >> I even tried to search for the files - with locate - but they're not
> >> on my harddisk.
> >>
> >> Does anyone have a hint or idea?!
> >>
> >> [1] 0 */12 * * * root /opt/gentoo-rsync/rsync-gentoo-portage.sh;
> >> emerge -fuD world &> /dev/null [2] Started emerge on: Aug 07, 2003
> >> 12:14:020
> >
> > Maybe I'm wrong, but isn't the '&' at the wrong position? Afaik the line
> > should read:
> > 0 */12 * * * root /opt/gentoo-rsync/rsync-gentoo-portage.sh;
> > emerge -fuD world > /dev/null &
>
> Well "&" (background) doesn't make much sense in a cron job in my
> opinion.
Of course you are right here. I realized this, when I started to read your
answer.
> > I believe you are forcing your updates straight forward to /dev/null
>
> Well no and yes:
>
> man bash
> There are two formats for redirecting standard output and standard
> error: "&>word" and ">&word". Of the two forms, the first is
> preferred. This is semantically equivalent to ">word 2>&1".
Ah, interesting. Thanks for this.
> But the real culprit was *Prozilla*! I changed the $FETCHCOMMAND to
> [1] and when I get back to the default wget - it works...!
>
> Thorsten
>
> [1] FETCHCOMMAND='/usr/bin/proz -r --no-netrc --no-getch --no-search -k=4
> --timeout=300 -t=5 --retry-delay=15 --max-bps=0 ${URI} -P ${DISTDIR}'
Nice to hear everything works again :-)
HAND
Michael
--
[EMAIL PROTECTED] mailing list
