> 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
ba
Sorry for not getting back earlier.
I think I have found the cause for the problem at our site.
As I said we have a mixed environment with different versions of ubuntu and
redhat.
In our common bashrc there is a check if the variable $BASH_COMPLETION is set.
On Redhat and until ubuntu 12 this va
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 t
> Did you mean ln -s /tmp /tmpX ?
Sorry. Yes I meant ln -s /tmp /tmpX.
Thanks for pointing me to do tests as non root.
I usually don't work on the desktop but only do admin tasks over ssh.
We have a link /applics -> /nfs/AppServer/applics on all our clients.
If I do as regular user: ls /appl
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.)
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/
another observation as an addon to my previous post (I'd liked to edit
it but unfortunately I can't)
less /tmpX # gives "less /tmpX/" on the same line
type lv # gives "lv is /usr/bin/lv"
lv /tmpX # gives "lv /tmpX " with a trailing space
So it is suppose
I have a freshly installed ubuntu 14.04.1 LTS and it also shows the problem.
Thus I doubt that it a legacy package.
I found that it occurs repeatable with symlinks and aliased commands as shown
below
TEST SCENARIO
ln -s /tmpX /tmp
alias ll='ls -l'
ls /tmp # gives "tmp/" and "tmpX/"
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 sup
** 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 cr
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 no
If we can figure out if there's one bad file that is commonly left lying
around, and breaks things, a workaround can be shipped in bash-
completion to blacklist it.
I'm going to close any pre-trusty reports of this, since they're
probably the acroread crap. And point those bugs to here.
I editt
This doesn't happen on a normal Trusty system, but yeah, there are
similar reports of this happening to people. Must be some kind of
leftover stuff from upgrades. My system has an upgrade chain going back
to Edgy (6.10), but I keep it tidy with aptitude and other tools.
You may have some cruft i
** Summary changed:
- tab bash-completion adds an unwanted space so path name expansion fails
+ unwanted space after directory completion
--
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:
14 matches
Mail list logo
