descend_unique_hierarchy is used for the cd autosuggestion: if a directory
contains exactly one subdirectory and no other entries, then propose that
as part of the cd autosuggestion.
This had a bug: if the subdirectory is a symlink to the parent, we would
chase that, going around the loop suggesting a longer path until we hit
PATH_MAX.
Fix this by using the new API which provides the inode "for free," and
track whether we've seen this inode before. This is technically too
conservative since the inode may be for a directory on a different device,
but devices are not available for free so this would incur a cost. In
practice encountering the same inode twice with different devices in a
unique hierarchy is unlikely, and should it happen the consequences are
merely cosmetic: we fail to suggest a longer path.
This introduces dir_iter_t, a new class for iterating the contents of a
directory. dir_iter_t encapsulates the logic that tries to avoid using
stat() to determine the type of a file, when possible.
* add adb options
only complete device serial when space after '-s' option
* keep current `adb -s` completion
* add adb reboot fastboot
* only show tcp/ip devices for disconnect
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
* fix: files not complete when options given
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
* fix: use old-style options for adb generic options
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
* completion/usbip: use string-match to detect remote (#9250)
* simplify output
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
Signed-off-by: Next Alone <12210746+NextAlone@users.noreply.github.com>
I have about fifty git branches for fish and I almost always `git checkout`
between the most recent two or three - this makes the completions list more
usable. If you're using `git cherry-pick` or `git merge`, etc. you also most
likely to want to reference a recently changed branch.
The decision was made to only sort local branches and not remote ones in the PR
at #9248.
The performance of changing from one `git for-each-ref` invocation to two
separate ones (so we could sort them separately) was checked and found to be OK.
Food for future thought: consider ergonomics, caveats, and performance of
excluding the current branch's name from the list of completions (or perhaps
only from the first completion). Or maybe there's another way to have
`for-each-ref` give priority to a different branch while still sorting by
recency?
There are a million existing ways of skinning this cat, but it's a good parallel
to `__fish_seen_argument` to have, in a similar vein to
`__fish_seen_subcommand_from`.
Confirmed on NetBSD: The `ls -o` option groups. I tested `ls -gon` and
it didn't give an error.
It's quite suspect that this one option couldn't be grouped, so I'm
assuming this was a typo.
Prior to 1811a2d, the return value for negative return codes was UB and I'd
witnessed both expected cases like -256 mapping to a $status of 0 and unexpected
cases like a return value of -1 mapping to a $status of 0. As such, this doesn't
test just one fixed return value but the entire range from negative multiples of
256 all the way down (rather, up!) to -1.
While we hardcode the return values for the rest of our builtins, the `return`
builtin bubbles up whatever the user returned in their fish script, allowing
invalid return values such as negative numbers to make it into our C++ side of
things.
In creating a `proc_status_t` from the return code of a builtin, we invoke
W_EXITCODE() which is a macro that shifts left the return code by some amount,
and left-shifting a negative integer is undefined behavior.
Aside from causing us to land in UB territory, it also can cause some negative
return values to map to a "successful" exit code of 0, which was probably not
the fish script author's intention.
This patch also adds error logging to help catch any inadvertent additions of
cases where a builtin returns a negative value (should one forget that unix
return codes are always positive) and an assertion protecting against UB.
Hyphenation in our documentation is aggressive, even to the point of caus-
ing options themselves to be broken across lines. This makes the document-
ation hard to read, especially when you have an option like `string colle-
ct` which gets a weird hyphen.
Remove the hyphenation from the CSS.
This makes it so we link to the very top of the document instead of a
special anchor we manually include.
So clicking e.g. :doc:`string <cmds/string>` will link you to
cmds/string.html instead of cmds/string.html#cmd-string.
I would love to have a way to say "this document from the root of the
document path", but that doesn't appear to work, I tried
`/cmds/string`.
So we'll just have to use cmds/string in normal documents and plain
`string` from other commands.
