[pacman-dev] Fwd: [PATCH] Hack to detect Pacman-command-no-found error
[Resending after subscribing my address. If this works perhaps a note should be added saying you have to subscribe to be able to send to the list?] Original [patch] in case it gets garbled: https://github.com/vadmium/pacman-arch/commit/0a71ece.patch If the spirit of the change is appropriate but you’re not happy about using the ”test” command, I’m happy to learn how to use the Bash-specific way with double square brackets. Or someone who already knows can translate it :)
From 0a71ece90951894953ffd7bae741d69af927bf3f Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Thu, 18 Oct 2012 06:31:07 +0000 Subject: [PATCH] Hack to detect Pacman-command-no-found error
Bash also uses exit code 127 for command-not-found errors, which can occur if we lose access to the command given by $PACMAN. For instance after invoking /etc/profile, $PATH may be reset. --- scripts/makepkg.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index d387b7d..307ceeb 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -895,7 +895,7 @@ check_deps() { pmout=$(run_pacman -T "$@") ret=$? - if (( ret == 127 )); then #unresolved deps + if test "$ret" -eq 127 -a -n "$pmout"; then #unresolved deps printf "%s\n" "$pmout" elif (( ret )); then error "$(gettext "'%s' returned a fatal error (%i): %s")" "$PACMAN" "$ret" "$pmout" -- 1.7.12
On 31/10/12 09:54, Martin Panter wrote:
[Resending after subscribing my address. If this works perhaps a note should be added saying you have to subscribe to be able to send to the list?] Original [patch] in case it gets garbled: https://github.com/vadmium/pacman-arch/commit/0a71ece.patch
If the spirit of the change is appropriate but you’re not happy about using the ”test” command, I’m happy to learn how to use the Bash-specific way with double square brackets. Or someone who already knows can translate it :)
Done below.
From 0a71ece90951894953ffd7bae741d69af927bf3f Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Thu, 18 Oct 2012 06:31:07 +0000 Subject: [PATCH] Hack to detect Pacman-command-no-found error
Bash also uses exit code 127 for command-not-found errors, which can occur if we lose access to the command given by $PACMAN. For instance after invoking /etc/profile, $PATH may be reset.
I'd be concerned if the software used for package management was not in a system path...
--- scripts/makepkg.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index d387b7d..307ceeb 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -895,7 +895,7 @@ check_deps() { pmout=$(run_pacman -T "$@") ret=$?
- if (( ret == 127 )); then #unresolved deps + if test "$ret" -eq 127 -a -n "$pmout"; then #unresolved deps
(( ret == 127 )) && [[ -n "$pmout" ]]
printf "%s\n" "$pmout" elif (( ret )); then error "$(gettext "'%s' returned a fatal error (%i): %s")" "$PACMAN" "$ret" "$pmout"
Now, if we hit a return of 127 due to missing command, and "$pmout" is empty, what does this fall though message look like? Perhaps a better approach to this would be to check the program specified in $PACMAN is available in the check_software function and then assign it to its full path. i.e. PACMAN=$(which $PACMAN) Allan
On 31/10/2012, Allan McRae <allan@archlinux.org> wrote:
On 31/10/12 09:54, Martin Panter wrote:
Bash also uses exit code 127 for command-not-found errors, which can occur if we lose access to the command given by $PACMAN. For instance after invoking /etc/profile, $PATH may be reset.
I'd be concerned if the software used for package management was not in a system path...
I have a Pacman wrapper called “roopwn” that I am playing with, linked in my ~/bin/ directory. This seems to me to be a nice way to use it as I develop it.
--- scripts/makepkg.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index d387b7d..307ceeb 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -895,7 +895,7 @@ check_deps() { pmout=$(run_pacman -T "$@") ret=$?
- if (( ret == 127 )); then #unresolved deps + if test "$ret" -eq 127 -a -n "$pmout"; then #unresolved deps
(( ret == 127 )) && [[ -n "$pmout" ]]
printf "%s\n" "$pmout" elif (( ret )); then error "$(gettext "'%s' returned a fatal error (%i): %s")" "$PACMAN" "$ret" "$pmout"
Now, if we hit a return of 127 due to missing command, and "$pmout" is empty, what does this fall though message look like?
[vadmium@patig pacaur]$ makepkg --syncdeps # Requires “expac” to be installed first ==> Making package: pacaur 3.2.6-1 (Wed Oct 31 02:10:34 UTC 2012) ==> Checking runtime dependencies... ==> Installing missing dependencies... resolving dependencies... Packages (1): expac-1-1 . . . (1/1) installing expac [######################] 100% /home/bin/../proj/pacman/pacman/scripts/makepkg.sh.in: line 890: roopwn: command not found ==> ERROR: 'roopwn' returned a fatal error (127): [Exit 1] [vadmium@patig pacaur]$
Perhaps a better approach to this would be to check the program specified in $PACMAN is available in the check_software function and then assign it to its full path. i.e. PACMAN=$(which $PACMAN)
Sounds like that could be better. Then “makepkg --syncdeps” should actually be usable in the above case.
On 31 October 2012 02:28, Martin Panter <vadmium+patch@gmail.com> wrote:
On 31/10/2012, Allan McRae <allan@archlinux.org> wrote:
Perhaps a better approach to this would be to check the program specified in $PACMAN is available in the check_software function and then assign it to its full path. i.e. PACMAN=$(which $PACMAN)
Sounds like that could be better. Then “makepkg --syncdeps” should actually be usable in the above case.
I’m working on a patch that does this. There is already code that seems to check if Pacman is available for the --syncdeps operation, if you search for “Skipping dependency checks”. So I will try to save the path there, using “command -v”. Assuming this is more portable and POSIX-y than “which”. I ran into an inconsistency with the behaviour of spaces in $PACMAN. Judging by the “${PACMAN%% *}” incantation from revision 66c6d28 (makepkg: allow to specify an alternative pacman command), it looks like the original intention was to allow arguments after the command name. I think restoring that is the best way forward but will mean that the full path to $PACMAN will not be allowed to have spaces, because supporting spaces in the path and also spaces to separate arguments seems needlessly complex. Currently, including arguments in $PACMAN means the --syncdeps operation may be attempted, but each Pacman invocation will probably fail. However in other cases the operation would be skipped if $PACMAN cannot be found. Looks like this inconsistency comes from revision 622326b (makepkg: fix sudo/su calling of pacman).
participants (2)
-
Allan McRae
-
Martin Panter