On 3 November 2012 01:56, Dave Reisner <[email protected]> wrote: > On Wed, Oct 31, 2012 at 07:02:59AM +0000, Martin Panter wrote: >> Unmangled version: >> https://github.com/vadmium/pacman-arch/commit/70b1327.patch >> >> From 70b1327c0443818d163e10b649ba882a4fd5a0f3 Mon Sep 17 00:00:00 2001 >> From: Martin Panter <vadmium à gmail·com> >> Date: Wed, 31 Oct 2012 03:05:42 +0000 >> Subject: [PATCH] Restore ability for $PACMAN to include arguments and >> document it >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 8bit >> >> Judging by the “${PACMAN%% *}” incantation from revision 66c6d28 (makepkg: >> allow to specify an alternative pacman command), it looks like this was >> consciously intended. > > 66c6d28 is a 3 year old patch, and I strongly disagree with what it > does. Other common environment variables like EDITOR do not allow > options to be part of the binary name, and I think we should stick to > that. > >> 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). > > This is a two year old patch which isn't really much better given that > it relies on eval (a common misspelling of evil). The current behavior > using an array is what I consider to be correct and proper (and safe) > bash. > > If you'd like the ability to extend PACMAN and invoke it with arguments, > I suggest exposing the currentlly internal PACMAN_OPTS in a sane way.
I don’t have any need for custom arguments. Would it be better to remove the code that strips off the arguments and make it so that $PACMAN is clearly a command name only?
