(mirror of https://github.com/vyos/vyos-live-build.git) https://git.amelek.net/vyos/vyos-live-build.git/atom?h=rolling 2020-05-03T00:38:17+00:00 2020-05-03T00:38:17+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-03T00:25:55+00:00 urn:sha1:7276d0213fd26ee68b62b84080261e29512871e9 - the definition of $PROGRAM as used in $USAGE strings defined in each script has been broken for a long time, being simply "lb" when it needs to be "lb COMMAND". - `config` changed $PROGRAM to "lb config" thus its output was correct in this regard unlike everything else, but with the switch to a more "intelligent" `Man()` function recently, it means that instead of `man lb config`, what was actually run was `man lb config config`, which displayed the manpage, then on exiting with `q`, it showed some sort of index line todo with a "config" search (no exact manpage match?), for which you had to enter `ctrl+c` to get rid of. this revises things to fix the issues, minimising change by changing $PROGRAM to "lb COMMAND", with the frontend overriding this. Gbp-Dch: Ignore 2020-05-03T00:31:47+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-02T23:38:08+00:00 urn:sha1:372a8fd91a9ec22c22250e4a0322432305b69a9f lost in a reversion Gbp-Dch: Ignore 2020-05-02T17:18:49+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-02T17:18:49+00:00 urn:sha1:22d8ac15dbc75af2acf02447cf045791b137d7d4 2020-04-24T13:37:13+00:00 Raphaël Hertzog raphael@offensive-security.com 2020-04-23T20:17:23+00:00 urn:sha1:104fa2039990f17e02dd9d2dbfc801763987b532 This reverts commit 6b7c8ed4bf15175299729355f04d60dcbac1aded as it's breaking multi-value space-separated parameters. 2020-04-23T14:38:59+00:00 Raphaël Hertzog hertzog@debian.org 2020-04-23T14:38:59+00:00 urn:sha1:4c75f80e6763490d5bcb0e0a460b096a3292ae61 2020-04-23T14:32:26+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-30T16:32:07+00:00 urn:sha1:b3bba232ac6e1feff9e506506247aa20cd7f467c thus it can correctly indicate success/fail status instead of always indicating failure. when a user asks for usage with -u|--usage then we should exit in success mode rather than failure as when usage in printed in response to incorrect usage. Gbp-Dch: Short 2020-04-23T14:29:00+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-18T01:51:53+00:00 urn:sha1:6b7c8ed4bf15175299729355f04d60dcbac1aded this means that the usage goes from: lb {-h|--help|-u|--usage|-v|--version} lb COMMAND [OPTIONS] to: lb {-h|--help|-u|--usage|-v|--version} lb [FRONTEND_OPTIONS] COMMAND [COMMAND_OPTIONS] though it is probably not worth is to update the description in the manpages...? hmm... so for instance this matters for color control with --color|--no-color (you already had full control via environment vars). previously you could do `lb COMMAND --no-color` to turn off colour, only to find that output at the frontend level was still coloured (the option is processed at the command context level, not the frontend), so you might try to instead use `lb --no-color COMMAND`, only to find that this was not supported. Well now it is, and used at the frontend level will fully control colour output (after the command is processed anyway). the full set of common options are thus available (except --force) at the frontend level, and thus for instance all Echo_*() helpers used in the frontend will work correctly after args are processed. furthermore usage like `lb --color --help` will actually work. (not that color is used there, but this previously would have failed with the frontend treating the `--color` argument as the command; that's the point!) Gbp-Dch: Short 2020-04-23T10:52:13+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-30T05:41:00+00:00 urn:sha1:6b734df9f32914049b9a6e2291bda5c5b133b4bb this option actually only has an impact when used for `lb config`; it thus was incorrectly accepted and captured by Arguments() and the documentation was wrong. going back through git history, this has been incorrect since the v0.99 days. also, reorganised the list alphabetically (no-color was inserted in the wrong place). Gbp-Dch: Short 2020-03-23T08:06:51+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-18T01:09:11+00:00 urn:sha1:85e0681ee88a293e35bd77e613010663f274ece5 Gbp-Dch: Ignore 2020-03-16T22:10:03+00:00 Lyndon Brown jnqnfe@gmail.com 2020-02-20T06:58:11+00:00 urn:sha1:c55eb8a0c3ca5b8ed1081e7eb8a423563288fb58 all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short