IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
awk is an external program, and it is better to stick to shell built-ins.
Also, even with external awk, sort -u is redundant, because the shell does
this on its own.
"machinectl list" only lists running machines while many of the MACHINES
commands use names of images; both running and non-running.
List machines from both "list" and "list-images" and use sort -u to
avoid duplicates.
*Autocompletion for dirs, doesn't leave until you press space.
*Added tmpfs, volatile and network-macvlan options.
I tried with the SELinux options with seinfo(setools-console), but too
messy to get it right. Even Daniel Walsh haven't done it yet. :)
We really don't want to get lost in adding fridge, car, plane, drone, or
whatever else, hence add a generic term "embedded" cover all the cases
where the computer is just part of something bigger, and not at the
focus of things.
I tried to use 'systemctl --all list-units' to filter unit files, but
this always filters out unit files which are not loaded. We want to complete
systemctl start with those units too, so this approach is not going to work.
New version is rather slow, but hopefully correct.
Templates can be [re]enabled, on their own if the have DefaultInstance set,
and with an instance suffix in all cases. Propose just the template name
ending in @, to underline the instance suffix may have to be appended.
Likewise for start/restart.
This means that sometimes superflous units that one will not really
want to operate on will be proposed, but this seems better than
proposing a very incomplete set of names.
https://bugs.freedesktop.org/show_bug.cgi?id=66912
Since c6a373a263, we might encounter unit templates via the
'list-units' verb. These aren't restartable (and we throw errors), so
make sure they're filtered out of the completion options.
fixes downstream bug: https://bugs.archlinux.org/task/41719
This fixes the issue noted by Zbigniew in most cases.
if a unit's name is enclosed in single quotes completion still
will not happen after the first `\'.
https://bugs.freedesktop.org/show_bug.cgi?id=78388
I think that it is better to return good results slightly more slowly,
than partial quickly. Also reading from disk seems fast enough. Even
the delay on first try with completely cold cache is acceptable.
This is just for bash, 'cause zsh was already doing this.
https://bugzilla.redhat.com/show_bug.cgi?id=790768
Since this is a shortopt with an optional argument, assume the user
knows what they're doing. The longopts --boot and --this-boot will
continue to offer boot IDs as completions.
Suggested by David Wilkins <dwilkins@maths.tcd.ie> in
https://bugzilla.redhat.com/show_bug.cgi?id=967521:
> [Specific boot ID is a] bit of a palaver to obtain. I consulted the
> verbose dump of the journal to discover the _BOOT_ID for the
> timestamp, and then generated the journal dump for that boot using
> journalctl _BOOT_ID=foo -o short-monotonic.
The AA is unnecessary and only adds needless complexity. Replace it
with a case statement instead of repeatedly calling __contains_word to
overglorify string equalities.
- scope the iterator var
- use the correct, quoted, non-expansion prone positional parameter
notation
- prevent expansion on RHS of comparison
- remove unneeded explicit returns.
This really should be defined only once...
Hi,
I redid the boot ID look up to use enumerate_unique.
This is quite fast if the cache is warm but painfully slow if
it isn't. It has a slight chance of returning the wrong order if
realtime clock jumps around.
This one has to do n searches for every boot ID there is plus
a sort, so it depends heavily on cache hotness. This is in contrast
to the other way of look-up through filtering by a MESSAGE_ID,
which only needs about 1 seek + whatever amount of relative IDs
you want to walk.
I also have a linked-list + (in-place) mergesort version of this
patch, which has pretty much the same runtime. But since this one
is using libc sorting and armortized allocation, I prefer this
one.
To summarize: The MESSAGE_ID way is a *lot* faster but can be
incomplete due to rotation, while the enumerate+sort will find
every boot ID out there but will be painfully slow for large
journals and cold caches.
You choose :P
Jan
