We switch to using 'echo' instead of 'printf', for the reason described in a
previous commit.
This time, however, we don't do this in order to preserve the value of the
DESCRIPTION field (because we retrieve it using some other command). We do this
for two reasons:
* As chance would have it, we have the string '\c' in our DESCRIPTION. It turns
out that Dash's echo interprets '\c' to mean the end of the data[1], so
fields stored in $AllTAGS after DESCRIPTION aren't seen by our sed script
(resulting in the helper not reporting a few file entries).
* We also have '\n' in DESCRIPTION. This would translate, by echo, into
newline, failing the naive sed script.
[1] See "\c as in SYSV echo - abort all processing..." in the source code of
Dash: https://github.com/gioele/dash/blob/master/src/bltin/printf.c
Signed-off-by: Mooffie <mooffie@gmail.com>
Our goal is to replace the 'echo' with 'printf' on this line, for the reason
described in the previous commit. But before we do this we need to wrap one
variable in quotes.
This preliminary step does not affect the output of the helper.
As for using "tr \n ' '": this mimics the current behavior (when using no
quotes around the variable, newlines are converted to spaces by the shell; now
that we do have quotes we need to do this conversion ourselves). An alternative
is to tweak the sed script to be smarter, but it turns out it's not a simple
task.
Signed-off-by: Mooffie <mooffie@gmail.com>
Out test input intentionally contains weird characters in the DESCRIPTION field
(see the file 'test.spec'[1]).
It turns out that backslash sequences, as in our DESCRIPTION field, are
processed by the 'echo' command in some shells (i.e., Dash). In other words,
'echo' can't be used to print arbitrary data verbatim. Indeed, the standard
says[2] that "if any of the operands contain a <backslash> character, the
results are implementation-defined". You can see the problem by running:
$ echo "one \\a two"
under both Bash and Dash: you'll get different results.
The solution: we replace 'echo' with 'printf'.
[1] https://midnight-commander.org/browser/tests/src/vfs/extfs/helpers-list/misc/rpm/test.spec#L34
[2] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
Signed-off-by: Mooffie <mooffie@gmail.com>
As will be explained in a following commit, our rpm helper has a bug stemming
from the use of 'echo'.
Before we fix it, we update the test's "expected output" to reflect the
intended output (as it's currently reflects a faulty output).
Signed-off-by: Mooffie <mooffie@gmail.com>
The "expected output" files we provide must be generated in the same locale the
tester (that is, the helpers) are run. Otherwise helpers using the 'sort'
utility may generate output different than our provided "expected output",
hence failing the tests.
Therefore we:
(1) Regenerate the "expected output" files in the C locale.
(2) Make sure the tester is run in the C locale.
(Tip: to regenerate the "expected output" files we deleted all the *.output
files and run the tester with "LC_ALL=C ./run --create-output".)
Signed-off-by: Mooffie <mooffie@gmail.com>
Upon seeing a tab, the help viewer effectively pushes the *current* word
forward.
Instead, it should first finish handling the current word (that is, print it on
screen) and only then adjust the column.
Signed-off-by: Mooffie <mooffie@gmail.com>
When dragging a framed WEdit with the mouse, the frame is painted over the
buttonbar. This happens in two cases: when pressing the mouse down, and when
releasing it.
The patch fixes the problem by calling edit_update_screen() in these two cases.
This paints the buttonbar over the frame.
(The problem doesn't occur when moving the frame with the keyboard because
edit_callback(msg==MSG_KEY) calls edit_update_screen() right after handling the
key.)
Signed-off-by: Mooffie <mooffie@gmail.com>
This patch was supposed to get committed as part of #3571 but this never
happened. We commit it now as we depend on its functionality for the next
commit.
Signed-off-by: Mooffie <mooffie@gmail.com>
