We rarely attach trait methods to stdlib types so this warning is unlikely to
be a true positive It is a false positive for the methods defined in future.rs.
It's not always obvious which method is selected when it's available in the
stdlib but I haven't seen a build failure yet. So let's disable the warning.
In future we might be able suppress it per method, see Rust issue 48919.
We often want to format and print a string to a fd, usually stdout/stderr.
In general we can't use "format!", "print!", "eprint!" etc. because they don't
know about our use of WString where we encode of invalid Unicode characters
in the private use area.
Instead we use "wwrite_to_fd()".
Since we unfortunately don't have a "wformat!()" yet, we use "sprintf!()"
to create a formatted wstring to pass to "wwrite_to_fd()".
Add "printf!" and "eprintf!" to stand in for "print!" and "eprint!".
For printing to files other than stdout and stderr, keep "fwprintf!" but
drop the "w" since our "sprintf!" always produces wide strings.
Replace "fputws" with "fprintf" though we could also use "wwrite_to_fd"
if performance matters.
Unlike std::io::stdout(), we don't use locking yet.
Remaining work:
- There are more places where we use \be?print(ln)?!
Usually we print strings that are guaranteed to be valid UTF-8, but not
always. We should probably make all of them respect our WString semantics
but preferrably keep using the native Rust format strings (#9948).
- I think flog.rs currently uses String so it won't handle invalid Unicode
characters. We should probably fix this as well.
Like FLOGF!, this now needs at least one argument to format.
This avoids some issues with missing variables and broken format
strings - it is how I found 13ba5bd405 -
where disown had a format string, with two placeholders, but no
arguments to fill them with.
For use in e.g. macros, where it's otherwise hard to tell if we have
something to format or not, this adds a wgettext_maybe_fmt! version to
"maybe" format, if necessary.
In LastC++11, an empty history item means we either reached the end of history,
or the item is actually empty. The second meaning is still true. We never
append empty history items but the history file might have been modified.
Fixes#10129
Recall that universal notifiers are used to report changes to universal
variables to other shell instances. This adds a new strategy based on using
inotify to directly monitor the universal variables
file.
We have tried this in the past and abandoned it because it doesn't properly
work on some CI systems - let's try again.
This
1. Skips access() if we only have "special" permissions like the owner
that need stat
2. Does the geteuid()/getegid() *once* outside of filter_path, if we
need it
In the extreme case of `path filter --perm user,group` it will remove
3 syscalls per file.
Drop support for history file version 1.
ParseExecutionContext no longer contains an OperationContext because in my
first implementation, ParseExecutionContext didn't have interior mutability.
We should probably try to add it back.
Add a few to-do style comments. Search for "todo!" and "PORTING".
Co-authored-by: Xiretza <xiretza@xiretza.xyz>
(complete, wildcard, expand, history, history/file)
Co-authored-by: Henrik Hørlück Berg <36937807+henrikhorluck@users.noreply.github.com>
(builtins/set)
