Apparently bad checksums in tcpdump/wireshark captures for outgoing
traffic are normal, when hardware offload is enabled. The NIC only
fills in the correct value after data has been copied to the NIC, which
is after capture takes a snapshot of the buffer with whatever garbage
was there. See the
Public bug reported:
While playing a video with mpv, X locked up entirely (not even mouse
movement did anything). Even kill -9 won't kill the X server, although
/etc/init.d/sddm restart did get the video card to text mode. (But the
Xorg process is stuck in state D.) Unfortunately this means I
** Attachment added: "Nothing interesting"
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1602097/+attachment/4699113/+files/Xorg.0.log
** Description changed:
While playing a video with mpv, X locked up entirely (not even mouse
movement did anything). Even kill
** Attachment added: "full dmesg output, including kernel hung-task stack
traces"
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1602097/+attachment/4699112/+files/dmesg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Public bug reported:
When installing 1.3.99-1-1 on Ubuntu 15.10 (AMD64), I get the following
error while the package configures itself:
```
libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.3.99.orig.tar.bz2: OK
libdvd-pkg: Unpacking and configuring...
libdvd-pkg:
Public bug reported:
My system boots from XFS on RAID10 on GPT partitions (no LVM). The
RAID10 uses the "far2" layout, and has three component devices. I use
grub-pc for non-EFI booting, because this system is old and doesn't
support EFI (Intel DG965WH from 2008).
I added a fourth hard drive
Public bug reported:
As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787950,
/usr/share/mdadm/checkarray fails when it tries to read
/sys/block/mdX/md/sync_action, if running under dash (or apparently most
shells other than bash), with a 4.x kernel.
Present in Ubuntu 15.10, where a
If you want full-featured vim in a terminal, install vim-gtk and run it
as vim.
It only opens a new window if you run it as gvim, or vim -g.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/837882
Public bug reported:
kwin on open source drivers on a 1GB Radeon HD6870 (BARTS core) starts
off using a lot of memory, and uses more and more until it can't
allocate textures and you get black rectangles instead of windows
sometimes. kill/restart kwin_x11 gets back to the same state as on
login.
This bug is back, present in
xubuntu-daily-live-20150416-vivid-desktop-amd64.iso
but not in xubuntu-daily-live-20150414-vivid-desktop-amd64.iso from 2
days earlier.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
+ edit: derp, of course this fails, mdadm isn't installed until you chroot
+ in and do that manually. I wasn't thinking when I reported this ..
+ See http://askubuntu.com/questions/505446/how-to-install-ubuntu-14-04
+ -with-raid-1-using-desktop-installer for details on
** Package changed: grub-installer (Ubuntu) = ubiquity (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1445156
Title:
Ubiquity grub-install fails when installing to a RAID10 with manual
Public bug reported:
Ubiquity running from Kubuntu 15.04 beta2 usb image.
The installer GUI said it was going to try installing GRUB on sda, not
sda1. (This isn't a duplicate of #1322182)
my setup is:
/ on XFS on /dev/md0: RAID10 of sda2,sdb2,sdc2
/home on XFS on a different md RAID10 of
Public bug reported:
I just wanted a simple proxy, so I ran
tcpwatch-httpproxy -p 10.0.0.19:8080 -s /dev/null
(On a machine that also has a real IP)
Then I started some downloads running from another computer, and later
noticed tcpwatch-httpproxy was using 1.6GB of RAM. That might be the
full
Public bug reported:
Even after rm -r ~/.subcommander, subcommander still 2.0 beta5
(Ubuntu 14.10) still crashes when I try to do pretty much anything.
e.g. run subcommander, right click on the Subcommander project. New
repository in the dropdown - segfault.
I wasn't able to get it to do
This will get fixed upstream at some point for sure, so having the bug
here is probably only useful as a reminder to check that we have an
updated-enough GRUB before the next release, or next LTS release at
worst.
** Description changed:
Filing a note here in case I forget later.
It
Is this still the case? Natty is ancient. I thought grub1 had learned
how to deal with Linux XFS. (maybe with fsync and then FIEMAP, or the
xfs-specific ioctl that xfs_bmap -vpl some_file uses. (output is
similar to filefrag -e, but shows you when there's a hole, instead of
leaving it up to
Public bug reported:
Filing a note here in case I forget later.
It looks like GRUB (2.02-beta2-15) in 14.10 doesn't support XFS's new
on-disk metadata format that has CRCs. (rationale:
https://www.kernel.org/doc/Documentation/filesystems/xfs-self-
describing-metadata.txt)
mkfs.xfs -m
** Changed in: grub2 (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/775507
Title:
grub2 in natty fails to read xfs files
To manage notifications about this
** Description changed:
Filing a note here in case I forget later.
- It looks like GRUB in 14.10 doesn't support XFS's new on-disk metadata
- format that has CRCs. (rationale:
+ It looks like GRUB (2.02-beta2-15) in 14.10 doesn't support XFS's new
+ on-disk metadata format that has CRCs.
Public bug reported:
14.04 - 14.10 went flawlessly, on my nearly-default-install laptop.
The only problem I noticed was when prompted to yN or d for details.
After hitting d, return, then exitting from less (without doing anything
weird like ^z), the prompt for what to do next wasn't printed. I
Formatting ate the multiple blank lines. There is a blank line for
every time I pressed return, before N.
pasted to a file, too, in case anyone didn't fully understand the
description.
** Attachment added: output.txt
Sorry for not getting back earlier.
No worries. Glad you got your systems sorted.
Not closing this bug, because your problem wasn't this bug after all..
. I still want to leave this bug here for the purpose I editted the
OP to.
Nonetheless I'd like to know if there is way to detect if
still can't reproduce. Is there any chance /nfs/AppServer/applics sometimes
looks like a broken symlink? Do you get the same behaviour if you
ln -s /tmp /tmpX
and then do your examples exactly as typed? And ideally, can you do it without
writing to /?
mkdir -p test/tmp; cd test
ln -s ./tmp
ln -s /tmpX /tmpproduces:
lrwxrwxrwx 1 peter peter 5 Dec 9 11:58 /tmp/tmpX - /tmpX (a broken symlink)
Did you mean ln -s /tmp /tmpX ?
When cooking up a testcase, it's bad practice to make one that only
works for root.
mkdir -p test/tmp
cd test
ln -s ./tmp tmpX
ls ./tmp[TAB] = tmp/
Oh forgot to mention, you can toggle programmable completion on or off with
shopt -u progcomp# unset
shopt -s progcomp# set
Usually bash's builtin file/directory completion gets it right, and
doesn't trip up on unusual characters in filenames (e.g. 'foo*' leads to
problems with progcomp.)
Found a time when I didn't mind rebooting, and tested tested
linux-image-3.18.0-031800rc7-generic version 3.18.0-031800rc7.201411302035
peter@tesla:~$ uname -a
Linux tesla 3.18.0-031800rc7-generic #201411302035 SMP Mon Dec 1 01:36:38 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
peter@tesla:~$ route
Public bug reported:
Noticed the bug on trusty, still present in
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/vte3/vivid/view/head:/src/vte.sh
__vte_prompt_command():
${PWD/#$HOME/~} needs to be
${PWD/#$HOME/\~}
because ${parameter/pattern/string} does tilde expansion on string.
$HOME is a good example as a testcase, but a terrible example of it
actually being a problem, because ~/file.txt is easier to type anyway.
$OLDPWD is more annoying. I think progcomp used to expand the variable
on your cmdline, and then of course completion just worked normally. I
think that
As discussed in bug 790043 (about the slowdown of loading completions),
the out-of-the-box configuration seems to be to load programmable
completions (progcomp) for login shells, but not for non-login shells
(e.g. bash in an xterm).
TL:DR summary: ~/.bashrc should source
So to be clear, the changes I'm suggesting are:
* /etc/skel/.bashrc (pkg=base-files) change the progcomp check to an
un-commented
# enable programmable completion
[[ -e /etc/profile.d/bash_completion.sh ]] .
/etc/profile.d/bash_completion.sh
* /etc/bash.bashrc (pkg=bash): remove the progcomp
crap, wrong bug, meant to post that last on bug 1173728
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/790043
Title:
Bash-completion slows up the start of bash
To manage notifications about this
So to be clear, the changes I'm suggesting are:
* /etc/skel/.bashrc (pkg=base-files) change the progcomp check to an
un-commented
# enable programmable completion
[[ -e /etc/profile.d/bash_completion.sh ]] .
/etc/profile.d/bash_completion.sh
* /etc/bash.bashrc (pkg=bash): remove the progcomp
Good catch, but the right fix is to use command grep, like most of the uses of
grep in bash-completion do. --color=never isn't portable to systems where grep
isn't GNU grep. So yes, this is a bug, and bash-completion is supposed to not
break even if you have
alias grep='cat /dev/random'
This is already fixed upstream in git head.
** Changed in: bash-completion (Ubuntu)
Status: New = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1330173
Title:
bash-completion
looks like this has been submitted upstream by someone:
https://alioth.debian.org/tracker/index.php?func=detailaid=314875group_id=100114atid=413095
Didn't check if it was the same script or not.
** Bug watch added: alioth.debian.org/ #314875
It's done the way it is to save RAM and startup time for every
interactive bash. If bash had to store both versions of a function, and
pick at runtime, it would be slightly slower every completion, and more
importantly, slightly slower to load.
As I understand it, this is the design tradeoff
submitted upstream as
https://alioth.debian.org/tracker/index.php?func=detailaid=314898group_id=100114atid=413095
** Bug watch added: alioth.debian.org/ #314898
http://alioth.debian.org/support/tracker.php?aid=314898
--
You received this bug notification because you are a member of Ubuntu
submitted upstream:
https://alioth.debian.org/tracker/index.php?func=detailaid=314899group_id=100114atid=413095
_install_xspec '!.@(wxm?(x)|mac)' wxmaxima
is all it takes these days, prob. don't want to make a separate file.
** Bug watch added: alioth.debian.org/ #314899
attaching a patch. I think I tested everything I changed. I replaced
the loop over ls output with grep -l | sed.
I made a bunch of overall changes and improvements to the script, too.
When completing an empty word, instead of returning the full list of all
available packages, all PIDs, and all
/etc/profile.d/bash_completion.sh only sources /usr/share/bash-
completion/bash_completion if it hasn't been already. note the check on
-z $BASH_COMPLETION_COMPAT_DIR, which the giant bash_completion script
defines with
: ${BASH_COMPLETION_COMPAT_DIR:=/etc/bash_completion.d}
readonly
@Atanas: interesting idea to have bash load completions in the
background, but shell scripting as a language has NO support for doing
anything like this. You can't just have it happen in another thread,
because you need it to modify the context of the CURRENT shell.
You'd need a new major
Attached the full-fledged perl script I cooked up to investigate
obsolete conffiles.
grep the output, it doesn't take options.
When removing them, it often leaves empty directories, so don't forget
to remove them, too. (If they aren't owned by some other package...
check with dlocate, or add
Was working on completions for something else, and thought of this when
I saw completions/make checking if COMPREPLY has only a single entry.
If it does, that means completion will replace the user's word, rather
than show possible completions. In that case, run compopt -o nospace.
And maybe
** Changed in: bash-completion (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1388423
Title:
Please package completions for apt-mark into bash_completion
To
hmm, actually now that dpkg completions are dynamically loaded, you
could do whatever in completions/dpkg without being a burden for every
interactive shell. Might be worth thinking about, but really, just
don't remove dctrl-tools. :P
--
You received this bug notification because you are a
Does the completed filename look different from the output of ls?
Can you copy/paste a test-case? I don't know how to type cyrillic
characters without busting out gucharmap, but I have no problem pasting
mkdir / touch 'some UTF8' into a shell to test it out.
e.g.
touch cyrillic with spaces
echo
with 14.04:
time find -name '*.[ch]' | xargs grep -i 'volatile.*s3tc' # en_CA.utf8
real0m44.320s
user0m43.777s
sys 0m0.459s
time find -name '*.[ch]' | LANG=C xargs grep -i 'volatile.*s3tc'
real0m2.078s
user0m1.795s
sys 0m0.381s
time find -name '*.[ch]' | xargs grep
** Changed in: casper (Baltix)
Status: New = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/25496
Title:
Unable to boot Ubuntu using TORAM=yes (copy livecd to RAM)
To
bug 1173728 is about programmable completion being loaded by default, or
not. Further discussion about how and whether it is should go there.
Sorry for the tangent about it in this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The shell builtin command return can be used to exit early from a file
sourced with . or source.
bash_completion could protect itself from being re-sourced by doing
type __reassemble_comp_words_by_ref 2/dev/null return
Or maybe
complete -p paste 2/dev/null return
So complete -r; source
** Summary changed:
- incorrect bash-completion for sudo
+ command / directory mixup for completion of args to meta-commands like sudo
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to etckeeper in Ubuntu.
Input/output error? Normally you only see that when a system call
returns EIO, which usually only happens when your hard drive has an
actual error. (i.e. hard drive failure, not just file that doesn't
exist.)
I think it's unlikely that dpkg would print Input/output error when
it didn't see an
** Changed in: bash-completion (Ubuntu)
Status: New = Confirmed
** Tags removed: i386 running-unity
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1061114
Title:
Completion suggests rsync
bash_completion uses
sed -ne 's/.*\(--[-A-Za-z0-9]\{1,\}=\{0,1\}\).*/\1/p'
to parse the options out of the --help output for MANY commands, including grep.
Unfortunately, it trips up on lines like this from grep:
-r, --recursive like --directories=recurse
because the .* matches
fixed it:
echo ' -r, --recursive like --directories=recurse' | sed -ne
's/\([^-]\|-[^-]\)*\(--[-A-Za-z0-9]\{1,\}=\{0,1\}\).*/\2/p'
--recursive
using \([^-]\|-[^-]\)* instead of .* at the front of the pattern makes the
greedy match at the front stop at the first --. If there are commands that
upstream
https://alioth.debian.org/tracker/index.php?func=detailaid=314896group_id=100114atid=413095
Patch attached there. Also fixes
ls --directory --[TAB] = now completes options
rather than deciding that it's right and user is wrong, and only
accepting a directory name. Not smart for
** Changed in: bash-completion (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/724244
Title:
aptitude versions missing
To manage notifications about
Works now, in Trusty. Must have finally made it in.
** Changed in: bash-completion (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/924676
Title:
Make
** Summary changed:
- incorrect bash-completion for sudo
+ command / directory mixup for completion of args to meta-commands like sudo
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1095180
Title:
In Trusty, ping is handled by _ping, so custom code just for ping.
host just gets the generic _minimal.
completion for host was removed in commit
bd482ca2f221323aa461ca75c9457ec11f43570e
host, nslookup: Remove completions for bind utils from
bash_completion.
This fixes tests on systems
** Changed in: bash-completion (Ubuntu)
Status: New = Opinion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1004225
Title:
dramatic combination of apt-get and bash completion
To manage
upstream still has a naive _parse_help based handler for ssh-add :/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/376546
Title:
Identity filename completion for ssh-add would be nice
To manage
** Changed in: bash-completion (Ubuntu)
Status: In Progress = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/887529
Title:
Option --command-fd no longer present in dpkg but shows
I always scroll pages of completion results with space, not enter. I
didn't know enter was an option there. I just tried it, looks like
enter goes by lines, instead of pages? No wonder you were holding it
down. So... don't do that. esp. not on sudo.
To easily get a big list that you need to
adding
COMPREPLY+=( $( initctl list 2/dev/null | cut -d' ' -f1 ) )
to _services() does the trick.
submitted upstream
https://alioth.debian.org/tracker/index.php?func=detailaid=314897group_id=100114atid=413095
** Bug watch added: alioth.debian.org/ #314897
** Summary changed:
- bash autocomplete doesn't work with sudo on Ubuntu 13.04
+ bash programmable completion not loaded by default
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1173728
Title:
Is this still the case that a default install of Ubuntu doesn't enable
programmable completion out of the box? Not much point making bash-
completion a standard-priority package if it's not enabled by default.
my /etc/bash.bashrc still has the lines
# if [ -f
I don't have eg installed, but I got the completions from the .deb, and
sourced them in a shell.
Works for me on Trusty; I don't see those error messages. I am using
git from the ppa, though: 2:2.1.3-1avh1~trusty1 not Trusty's 1:1.9.1-1.
(eg uses git's completion functions, and /usr/share/bash-
You have alias ls='ls -F', and /etc/bash_completion.d/apport_completion
fails to use command ls to avoid getting your alias.
/etc/bash_completion.d/apport_completion is supplied by apport, so it's
a bug in that package.
working on a patch now.
** Package changed: bash-completion (Ubuntu) =
Oh, this is supported and documented in a .txt that the .deb doesn't
ship.
simply put
COMP_FILEDIR_FALLBACK=1
in your ~/.bash_completion (or ~/.bashrc)
doc/bash_completion.txt in the source tree.
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-
completion/bash-
*** This bug is a duplicate of bug 1188897 ***
https://bugs.launchpad.net/bugs/1188897
** This bug has been marked a duplicate of bug 1188897
Completion for service only looks up /etc/init.d/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Not seeing this in Trusty. Reopen if I made a mistake, but I think I
have just the Trusty-shipped completions loaded in the shell I tested
with, not my fixed version.
If you do see it, it might be from old cruft in /etc/bash_completion.d/.
report anything that needs to be blacklisted to bug
update: be careful with obsolete conffiles. The same file can be
obsolete in one package, but still be provided and non-obsolete in
another package. e.g. I removed my /etc/bash_completion.d/mercurial,
since my script found it, but it had moved from mercurial to mercurial-
common, and is listed
oh, I am using git 2:2.1.3-1avh1~tru, from the git PPA, not trusty's,
but at least that means its fixed upstream and will roll out eventually,
whether or not trusty has it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
There's something fishy going on,
/usr/bin/python /etc/ba[TAB] = prints a single completion, but doesn't apply
it.
bash_completion.d/
python /etc/ba[TAB] = /etc/bash_completion.d/
I think when testing this before, I had my completion dynamic loading
messed up, and wasn't getting
** Changed in: bash-completion (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1372286
Title:
unwanted space after directory completion (probably old
*** This bug is a duplicate of bug 1079641 ***
https://bugs.launchpad.net/bugs/1079641
** This bug has been marked a duplicate of bug 1079641
bash-completion errors and problems (e.g. not restricting completions to
matching current word)
--
You received this bug notification because you
Now it isn't throwing errors, but it doesn't filter the possible
completions to ones that match what's already typed.
** Summary changed:
- bash-completion of filename does not work 100% (unlike git) - gives : 1:
unary operator expected error
+ bash-completion of filename doesn't restrict
or I can get it to give errors with
eg pull [TAB]
it bash: [: 2: unary operator expected and tacks origin onto the end of the
command line.
origin
On Trusty, with git 2:2.1.3-1avh1~tru from the git PPA.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
This isn't bash-completion's bug. If anything, it's bash's bug, if
you're sure that COMPREPLY is being mishandled.
More likely, it's a bug in your own script, since the usual programmable
completion code jumps through some hoops do to the Right Thing for files
and directories. Your script has
It's a corner case of a directory in the current directory having the
same name as a command. The directory entry is superseding the command
completion.
If you sudo ettab you get a list of completions. In /etc, the only
entry for etckeeper is with a trailing /, rather than having an entry
The bug is in the core code of bash_completion, in the functions that
handle commands that take other commands as their arguments, e.g. sudo,
nice, and so on. Marked invalid for the etckeeper package, but still
confirmed for bash-completion. (I hope I'm doing this right. If
there's a way to
reported upstream as
https://alioth.debian.org/tracker/index.php?func=detailaid=314893group_id=100114atid=413095
** Bug watch added: alioth.debian.org/ #314893
http://alioth.debian.org/support/tracker.php?aid=314893
** Changed in: etckeeper (Ubuntu)
Status: Confirmed = Invalid
--
reassigning this to mysql. Packages can provide their own completion
rules and install them with dh_bash-completion. Not every tool needs to
have its completions shipped in bash-completions to be installed on
every system regardless of whether the tool is installed or not.
There's already a
These test cases both work fine in 14.04. Must have been fixed sometime
between then and now.
** Changed in: bash-completion (Ubuntu)
Status: New = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Pretty sure programmable completion isn't broken out of the box anymore,
closing this.
** Changed in: bash-completion (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This is fixed upstream. They reworked the relevant code, and the line
that gratuitously used an unquoted ~ where it shouldn't have is gone.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1390061
I've never seen this, and it doesn't currently happen on Ubuntu 14.04. If you
can still reproduce this, give us a testcase.
e.g.
mkdir -p foo/bar
touch foo/bar/baz
cp foo/btab
or something.
But probably you have something bad in your ~/.bash_completion, or
/etc/bash_completion.d, or
It's a corner case of a directory in the current directory having the
same name as a command. The directory entry is superseding the command
completion.
If you sudo ettab you get a list of completions. In /etc, the only
entry for etckeeper is with a trailing /, rather than having an entry
The bug is in the core code of bash_completion, in the functions that
handle commands that take other commands as their arguments, e.g. sudo,
nice, and so on. Marked invalid for the etckeeper package, but still
confirmed for bash-completion. (I hope I'm doing this right. If
there's a way to
reported upstream as
https://alioth.debian.org/tracker/index.php?func=detailaid=314893group_id=100114atid=413095
** Bug watch added: alioth.debian.org/ #314893
http://alioth.debian.org/support/tracker.php?aid=314893
** Changed in: etckeeper (Ubuntu)
Status: Confirmed = Invalid
--
I don't think numerical sorting is possible. _kill() is getting its list of
pids from
ps axo pid=
which returns a numerically sorted list, but I guess bash is lexicographically
sorting completions like it always does.
It would be possible to add completion for %jobnum, but would you
really
/etc/bash_completion.d/dlocate-completion is in dlocate, not
bash_completion.
Also, dlocate should use dh_bash-completion when building itself, so
the completions will go in the new spot: /usr/share/bash-
completion/completions
/usr/share/doc/bash-completion/README.Debian
Anyway, back to this
not present in Trusty. Thanks Romanos for the testcase:
mkdir test{,\ space}
./testtab = test/ test space/
sudo ./testtab = test/ test space/
** Changed in: bash-completion (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a
OPs testcase works now. Even did hg init in my tmp dir, to test that it
was filtering hg add to only show not-already-added paths. Reopen this
if you can still reproduce, and give us a testcase. (touch / mkdir some
stuff, hg init, and say what you typed and where you pressed tab)
** Changed
Doesn't seem to be a problem anymore. git clotab outside of any git
repo correctly completes to git clone, on Trusty. My ~/.git isn't
broken, possibly breaking it could spit errors?
If anyone does still see a bug, reopen this and post a testcase.
(touch / mkdir, and exactly where to press tab
not happening anymore on Trusty
** Changed in: bash-completion (Ubuntu)
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/485149
Title:
Typing arch and then
** Changed in: bash-completion (Ubuntu)
Status: New = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/470824
Title:
spurious trailing space after tab completion
To manage
dput fixed this sometime before trusty, assigning to the correct
package, and closing.
** Package changed: bash-completion (Ubuntu) = dput (Ubuntu)
** Changed in: dput (Ubuntu)
Status: New = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs,
1 - 100 of 547 matches
Mail list logo
