On 07/30/2018 12:23 PM, Ralph Corderoy wrote:
I'll be more clear.
makepkg(1) says `makepkg is a script'. It doesn't say what kind of script, e.g. sh(1), bash(1), ...
makepkg.conf(5) says `This file is sourced', but again doesn't state the language.
Well, on the other hand the actual makepkg.conf contains a *bash* shebang. :) Anyway my default rule when a file is "sourced" is to stick with the lowest common denominator, that is to say, POSIX sh, since it would therefore work regardless. However, in this case makepkg.conf lists a number of options that are part of makepkg.conf's formal API, which are represented by shell arrays, which indicates that POSIX sh is insufficient and you need bash. One who notices this could easily infer without leaving the configuration file, that it is bash. I'll ignore zsh on the grounds that no one *actually* writes programs in zsh... ... So, two points that definitively confirm it is bash, and a guaranteed-safe fallback in sh for people who don't notice this.
Right, that add up to thirty-odd variables. I wasn't arguing that `GNUPGHOME' should be magically exported just be being assigned in makepkg.conf, but stating it won't be exported because, quite reasonably, it isn't in makepkg.conf(5)'s list. Thus some method of exporting it would be required.
But makepkg.conf(5) just shows variable assignments because it's explicit they'll all be exported so the export syntax for this unknown language isn't shown.
It is, technically, a lie that they'll be exported, since many are not but it doesn't specify what it actually means there and basically implies that everything on that page is in fact exported to all subprocesses. Although I'm not sure if this generally matters as the ones used for internal state won't surprise people when some Makefile does not honor them, and moreover, half of them are arrays which aren't variables and cannot be exported as environment *variables*.
Besides, it's a lot more clear to have makepkg.conf(5) say it's bash(1) syntax and any bash code is acceptable, than see it's a list of `VAR=value' and wonder if deviating from that would be fragile and break in the future even if it's OK today. mkinitcpio.conf(5) has the same issue.
Patches welcome! Developers often do not realize that what seems obvious to us (cf. my above inferences regarding the language syntax) are non-obvious to others. When confusion arises, this is a good opportunity to get outside perspective on the matter (and, coincidentally, a sneaky way to trick people into becoming contributors :D). -- Eli Schwartz Bug Wrangler and Trusted User