[pacman-dev] [PATCH 1/3] makepkg: send messages to stdout rather than stderr
This behavior is confusing, since it means absolutely everything goes to
stderr and makepkg itself is a quiet program that produces no expected
output???
The only situation where messages should go to stderr rather than
stdout, is with --geninteg which is meant to return the checksums on
stdout (but we don't want to totally get rid of status messages when
redirecting the results elsewhere, or, worse, redirect status messages
to a PKGBUILD). For this specific case, redirect message output to
stderr in the --geninteg callers directly.
Implements FS#17173
Signed-off-by: Eli Schwartz
In the spirit of making libmakepkg more useful as a library, and,
critically, *using* that library for additional pacman scripts, we
should include all of output_format.sh and term_colors.sh directly in
libmakepkg and hopefully stop having to embed additional copies in e.g.
repo-add via m4 macros.
Signed-off-by: Eli Schwartz
Remove all remnants of library/{output_format,term_colors}.sh
Signed-off-by: Eli Schwartz
On 6/28/18 1:19 PM, Eli Schwartz wrote:
This behavior is confusing, since it means absolutely everything goes to stderr and makepkg itself is a quiet program that produces no expected output???
The only situation where messages should go to stderr rather than stdout, is with --geninteg which is meant to return the checksums on stdout (but we don't want to totally get rid of status messages when redirecting the results elsewhere, or, worse, redirect status messages to a PKGBUILD). For this specific case, redirect message output to stderr in the --geninteg callers directly.
Implements FS#17173 Don't use this.
Actually the pkgver() function saves the stdout of run_function_safe to a variable, and this patch would ensure the variable contains some decidedly not-pkgver content. :( -- Eli Schwartz Bug Wrangler and Trusted User
On 14/08/18 11:25, Eli Schwartz wrote:
On 6/28/18 1:19 PM, Eli Schwartz wrote:
This behavior is confusing, since it means absolutely everything goes to stderr and makepkg itself is a quiet program that produces no expected output???
The only situation where messages should go to stderr rather than stdout, is with --geninteg which is meant to return the checksums on stdout (but we don't want to totally get rid of status messages when redirecting the results elsewhere, or, worse, redirect status messages to a PKGBUILD). For this specific case, redirect message output to stderr in the --geninteg callers directly.
Implements FS#17173 Don't use this.
Actually the pkgver() function saves the stdout of run_function_safe to a variable, and this patch would ensure the variable contains some decidedly not-pkgver content. :(
Have not had time to look into this, but is there an easy/obvious way to adjust pkgver() capturing to stop this? Do we need to special case run_function? A
On 8/29/18 12:37 AM, Allan McRae wrote:
On 14/08/18 11:25, Eli Schwartz wrote:
On 6/28/18 1:19 PM, Eli Schwartz wrote:
This behavior is confusing, since it means absolutely everything goes to stderr and makepkg itself is a quiet program that produces no expected output???
The only situation where messages should go to stderr rather than stdout, is with --geninteg which is meant to return the checksums on stdout (but we don't want to totally get rid of status messages when redirecting the results elsewhere, or, worse, redirect status messages to a PKGBUILD). For this specific case, redirect message output to stderr in the --geninteg callers directly.
Implements FS#17173 Don't use this.
Actually the pkgver() function saves the stdout of run_function_safe to a variable, and this patch would ensure the variable contains some decidedly not-pkgver content. :(
Have not had time to look into this, but is there an easy/obvious way to adjust pkgver() capturing to stop this? Do we need to special case run_function?
I was actually thinking, we should maybe special-case run_function to not emit this when run in a subshell. Subshells aren't something we usually do, and when we do, it's probably to capture output, as in fact it is here. So, we could then handle this surrounding the subshell, the same way I did for https://patchwork.archlinux.org/patch/736/ -- Eli Schwartz Bug Wrangler and Trusted User
On 8/29/18 12:54 AM, Eli Schwartz wrote:
On 8/29/18 12:37 AM, Allan McRae wrote:
On 14/08/18 11:25, Eli Schwartz wrote:
On 6/28/18 1:19 PM, Eli Schwartz wrote:
This behavior is confusing, since it means absolutely everything goes to stderr and makepkg itself is a quiet program that produces no expected output???
The only situation where messages should go to stderr rather than stdout, is with --geninteg which is meant to return the checksums on stdout (but we don't want to totally get rid of status messages when redirecting the results elsewhere, or, worse, redirect status messages to a PKGBUILD). For this specific case, redirect message output to stderr in the --geninteg callers directly.
Implements FS#17173 Don't use this.
Actually the pkgver() function saves the stdout of run_function_safe to a variable, and this patch would ensure the variable contains some decidedly not-pkgver content. :(
Have not had time to look into this, but is there an easy/obvious way to adjust pkgver() capturing to stop this? Do we need to special case run_function?
I was actually thinking, we should maybe special-case run_function to not emit this when run in a subshell.
Subshells aren't something we usually do, and when we do, it's probably to capture output, as in fact it is here.
So, we could then handle this surrounding the subshell, the same way I did for https://patchwork.archlinux.org/patch/736/
Adding https://lists.archlinux.org/pipermail/pacman-dev/2018-August/022793.html on top of my branch with this patchset, makes pkgver() work again while sending messages to stdout. So this patchset is now back on the table. -- Eli Schwartz Bug Wrangler and Trusted User
participants (2)
-
Allan McRae
-
Eli Schwartz