FS#69689 - [gmrun] arguments regression and fundamental upstream shift
Attached to Project:
Community Packages
Opened by zgrim (zgrim) - Thursday, 18 February 2021, 11:59 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 18 February 2021, 12:19 GMT
Opened by zgrim (zgrim) - Thursday, 18 February 2021, 11:59 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 18 February 2021, 12:19 GMT
|
Details
Description:
The chosen upstream (github.com/wdlkmpx/gmrun) has switched to g_shell_parse_argv/g_spawn_async in 3d3c2785edae3e8881579347add1561875b597d5 replacing the older system(3) call for the underlying mechanism of spawning things. This has induced arbitrary and artificial restrictions in what can be passed for execution, drastically reducing the usefulness of the app. Seems a bit excessive for this particular program, whose sole purpose had been to be a GUI for system(3), if not a fundamental shift in nature. For example, one could previously specify env vars for the child process, e.g. "FOO=1 BAR=2 /path/to/app". This now errors out with "Failed to execute child process "FOO=1", whereas it would previously run without issues. Or e.g. "for i in $(seq 3) ; do xterm & done" would previously spawn 3 xterms, and now fails to execute. Same for pipes, etc, obviously the plain system(3) call was much more useful in the 20 years before this change. Additional info: * package version(s) gmrun 1.0w-1 * link to upstream bug report, if any not reported upstream Steps to reproduce: Run gmrun 1.0w-1. Type in "FOO=1 xterm" and attempt to run it. Then run the previous gmrun (0.9.5w-2). Type in the same. |
This task depends upon