Summary: | sys-apps/portage-2.1.11.51 chops EXTRA_ECONF string parameter values containing blanks | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Hugo Mildenberger <Hugo.Mildenberger> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Hugo.Mildenberger |
Priority: | Normal | Keywords: | InVCS, PATCH |
Version: | 2.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 458152, 459934 | ||
Attachments: |
use eval to assign parameters passed via EXTRA_ECONF correctly
eval EXTRA_ECONF to an array |
Description
Hugo Mildenberger
2013-02-14 11:28:11 UTC
Created attachment 338880 [details, diff]
eval EXTRA_ECONF to an array
The patch gives the intended result, without changing the interpretation of arguments passed directly to econf (important for compliance with app-doc/pms).
Here's a little demonstration script to show that this approach works:
#!/usr/bin/env bash
EXTRA_ECONF="--with-mssql-driver='SQL Server Native Client 11.0' --with-mssql-server=example.com"
econf_demo() {
eval "local -a EXTRA_ECONF=(${EXTRA_ECONF})"
for x in "${EXTRA_ECONF[@]}" ; do echo "${x}" ; done
}
econf_demo
(In reply to comment #1) > The patch gives the intended result, without changing the interpretation of > arguments passed directly to econf (important for compliance with > app-doc/pms). Yes, this solves the the problem here too. Yet I observe a a small difference: $ sudo [...] --with-mssql-server=example.com --with-mssql-driver=SQL Server Native Client 11.0 Note the missing single quotes when the command line gets logged by __vecho. However, this is only a defective appearance -- what you see is worrying, but what you get is right. This is in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e62aa344cba45aca2f317ecaae025ed4240659fd (In reply to comment #2) > Note the missing single quotes when the command line gets logged by __vecho. > However, this is only a defective appearance -- what you see is worrying, > but what you get is right. I suppose we could add a __vecho option that makes it quote the arguments it's given, or a new function for that. This is fixed in 2.1.11.53 and 2.2.0_alpha164. |