* Fix issue if md5sum is used instead of md5
Both have a different output which results in different array sized
Signed-off-by: Ron Gebauer <ron.gebauer@raytion.com>
* Add feedback
Signed-off-by: Ron Gebauer <ron.gebauer@raytion.com>
* Fix manpath handling in create_manpage_completions.py
...as well as do some (very!) light cleanup.
Currently, `create_manpage_completions.py` does not properly
understand/respect the `$MANPATH` variable. One important feature of
`$MANPATH` is that an empty component (i.e. the trailing : in
`foo:bar:`) expands to the 'default' or 'system' path -- that is to say,
the path that would be used if `$MANPATH` was unset. This allows the
user to extend the manpath without clobbering it, and has been a feature
many Unices have included for years.
The current implementation blindly uses the `$MANPATH` variable if it
exists, which does not allow for this behaviour -- to expand the
variable correctly, an external program must be invoked. Therefore, we
first shell out to the 'proper' (read: best guess) external program. If
that fails, we can then try to use `$MANPATH` directly/literally.
Finally, if both of those are impossible, we can fall back to some
common paths from widely used operating systems.
Note that the `man.conf` parsing has been removed: this is because while
many 'traditional' Unices (BSDs, Solaris, macOS) support this file, only
macOS actually ships a file -- most other Unices use a `conf.d`-style
layout and supporting that from our Python is impractical and silly at
best. On GNU (read: Linux) systems, `mandb` uses `/etc/man_db.conf` with
slightly different syntax and sematics. As this code-path has bitrotted
(and likely never worked, anyway), just remove it.
`create_manpage_completions.py` looks like it has suffered a lot of
confusion and bitrot in general over the last few years -- and is
overdue for a major refactoring. I am quite interested in tackling this,
but I plan to wait until the go-ahead to drop support for Python 2 is
given, as a major refactor/rewrite that still supports Python 2 (and
thus ignores the ergonomic/API/syntax improvements of Python 3) does not
make sense to me.
Related: #5657
It would probably be good to revisit `man.fish` once again when a
comprehensive refactor happens: hopefully every permutation of
`man`/`$MANPATH` could be documented as part of that effort.
* Restore /etc/man.conf parsing
I was not aware that this codepath was used -- since it appeared that it
would throw an error when it was reached. Redo it, using regex, and
support parsing NetBSD man.conf as well (untested).
* Fix create_manpage_completions.py under Python 2
It removed $KONSOLE_PROFILE_NAME and added $KONSOLE_VERSION.
Let's assume if $KONSOLE_PROFILE_NAME is set we use the old sequences,
if not we use the new ones.
This reverts commit 535845861a.
That commit introduced a bug where tab-completing commands no longer
prints their descriptions, unless there is an exact match.
If we output text and end up in the last column, the sticky right edge
will cause a clr_eos to erase the last character. Ensure this doesn't
happen by not issuing clr_eos in that case.
Fixes#6951
If a readline command is bound to a key sequence which also sends a
signal, then fish will set the cancel flag in addition to handling the
command. But this cancel flag is then persistent. Ensure it gets cleared
after each command.
Fixes#6937
The manual page for statfs(2) only lists SMB_SUPER_MAGIC and
CIFS_MAGIC_NUMBER, but it turns out there's a third type of CIFS/SMB
mount, represented by SMB2_MAGIC_NUMBER.
Haunting me from #6609.
The CMake variable FISH_USE_SYSTEM_PCRE2 now controls whether fish uses
system PCRE2 or the bundled version. The default is to use the system
version, unless no such version is found, or unless it is a macOS build
with code signing. Note the default behavior has not changed.
Fixes#6952
Use inline initializers rather than the constructor, and adopt some
maybe_t.
Also move post_buff_1 and post_buff_2 to local variables instead of
member variables.
Commit 5fccfd83ec, with the fix for #6806,
switched eval to buffer its output (like other builtins do). But this
prevents using eval with commands that wants to see the tty, especially
fzf. So only buffer the output if the output is piped to the next process.
builtin_eval needs to know whether to set up bufferfills to capture its
output and/or errput; it should do this specifically if the output and
errput is piped (and not, say, directed to a file). In preparation for
this change, add bools to io_streams_t which track whether stdout and
stderr are specifically piped.
Commit 5fccfd83ec, with the fix for #6806,
switched eval to buffer its output (like other builtins do). But this
prevents using eval with commands that wants to see the tty, especially
fzf. So only buffer the output if the output is piped to the next process.
This will solve #6955 (which needs to go into a point release).
builtin_eval needs to know whether to set up bufferfills to capture its
output and/or errput; it should do this specifically if the output and
errput is piped (and not, say, directed to a file). In preparation for
this change, add bools to io_streams_t which track whether stdout and
stderr are specifically piped.
Prior to this fix, builtin_eval would direct output to the io_chain of the
job. The problem is with pipes: `builtin_eval` might happily attempt to
write unlimited output to the write end of a pipe, but the corresponding
reading process has not yet been launched. This results in deadlock.
The fix is to buffer all the output from `builtin_eval`. This is not fun
but the best that can be done until we have real concurrent processes.
cherry-pick of a1f1b9c2d9Fixes#6806
Ensure that if eval is invoked as part of a pipeline, any jobs spawned
by eval will have the same pgroup as the parent job.
cherry-pick of 82f2d86718
Partially fixes#6806
