With this commit, passing -Q to fs_cli will cause fs_cli to not load
or save the command history file (~/.fs_cli_history). This can be
useful e.g. on read-only systems.
This can also be set in the fs_cli configuration file with the option
`no-history-file`.
In some cases where `redisplay()` is called immediately after a
command is run (e.g. `log ...`) we often get a prompt, junk output,
and a second prompt. This is due to a (known) race.
We believe we're falling afoul of this code in `el_deletestr`:
if (el->el_line.cursor < &el->el_line.buffer[n])
return;
Basing the length of text to delete off of the cursor position
resolves the issue of junk text, but the real solution is to eliminate
the race conditions, which will also resolve the sometimes duplicated
prompt.
FS-6764 #resolve
Thanks-to: Nathan Neulinger <nneul@neulinger.org>
What we momentarily called log-uuid-chars is now better called
log-uuid-length. Setting log-uuid-length will specify a truncation
length for UUIDs displayed by setting log-uuid.
If log-uuid-short is set, or -S is passed to fs_cli, we only display
the first 8 hex digits of the UUID. The log-uuid-chars option may
instead be set to specify some other truncation length for the UUID.
POSIX says poll.h and signal.h should not be prefixed with sys/ (ie
poll.h instead of sys/poll.h)
limits.h also defines a TZNAME_MAX so we change name of the define for
spandsp.
If we received an event without a content-type header we were
dereferencing a null pointer leading to a seg fault.
Reported-by: Ico <ico@voip-io.org>
ESL-90 --resolve
Now that all output should end in a newline, we don't need to play
tricks with getting certain escape codes out ahead of buffered output.
This updates what we tried to do in commit
991b83d23c.
This partially reverts commit
8056125077.
The issue is that sofia siptrace output doesn't end each line with a
newline. Instead it sends a separate newline afterward, which comes
in as a separate event body. With the new EL_REFRESH code in effect
the line is being cleared after the siptrace output has been written
but before that next newline comes in.
With our own refresh code this doesn't happen because of slight
differences in where the stdio buffers get flushed compared to where
the output of clear_line() ends up.
This is a bit of a clumsy workaround. But we'll fix it first, then
refactor.
Using the system libedit means that libedit will again make absolute
movements on certain kinds of terminals. Older versions of libedit
without EL_PROMPT_ESC miscalculate the length of the prompt.
Combined, this results in the cursor ending up in the wrong place.
We knew this was a possibility when we moved to system libedit, and
we're OK with it. We certainly lived without this fancy prompt
feature for a long time.
This change puts back in place detection of the terminal type when
EL_PROMPT_ESC isn't available. On these older versions of libedit,
we'll only enable the fancy features when we know that libedit will
only make relative movements and not tickle the bug.
This partially reverts commit:
b9b77bd615
Newer versions of libedit provide an EL_REFRESH mechanism for
redrawing the prompt. We had previously written our own code to
handle this. In theory handing this over to libedit should be better.
Unfortunately when using EL_REFRESH the output of sofia siptrace isn't
showing up. We're working on that, but for now we're just force own
our redrawing code to be used instead.
Anthony Minessale