On Thu, Nov 5, 2009 at 8:01 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
Cedric Staniewski wrote:
The source command triggers / could trigger the ERR trap which makes makepkg abort right after a successful installation of missing dependencies.
Signed-off-by: Cedric Staniewski <cedric@gmx.ca> --- It works, but I'm totally clueless why. I would prefer a more obvious solution if we can find one (set +E ... set -E did not work for me).
scripts/makepkg.sh.in | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 92b0454..81f20bb 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -371,10 +371,9 @@ handle_deps() { fi
# we might need the new system environment - # set -e can cause problems during sourcing profile scripts - set +e - source /etc/profile &>/dev/null - set -e + # avoid triggering the ERR trap by running the + # source command in a subshell + $(source /etc/profile &>/dev/null)
return $R_DEPS_SATISFIED }
This one is stupid, sorry. Makepkg does not abort anymore, but the source command is pointless now. So we have to find another way to work around this nice errtrace option.
So looks like http://bugs.archlinux.org/task/11179 is coming up again because of the new set -E I have been reading http://fvue.nl/wiki/Bash:_Error_handling Oh my god ! This stuff is so complex , it really hurts :P I only understood half of what I was reading, which led to me to do many test, including this one : # we might need the new system environment # a trap on ERR can cause problems during sourcing profile scripts restoretrap=$(trap -p ERR) trap - ERR source /etc/profile &>/dev/null eval $restoretrap It looks like this did the trick for me (and set +e is no longer needed ?) Btw this problem is still caused by bash-completion.. It does not make sense to have makepkg load all that crap :)
From /etc/profile.bash : # Source our global bashrc file, to remove duplication of effort [ -r /etc/bash.bashrc ] && . /etc/bash.bashrc
Maybe this should only be done for interactive shells ? That would workaround the problem , right ?