Re: bash expanding relative paths in auto-complete

2015-08-16 Thread Linda Walsh



Andreas Schwab wrote:

Linda Walsh b...@tlinx.org writes:


in bash 4.3.39,
if I type a command, (like .(source)) and a relative path
like : ../confcomplete,
it expands the relative pathname to absolute pathnames.


Worksforme.  Make sure to run complete -r first.

---
You didn't say what version of bash you were using... but
that may not be relative:

It seems to be direxpand -- do you have it on or off.

It is supposed to perform word expansion.  It doesn't
say it will convert relative paths to absolute.

Has it always been that way? (I thought direxpand expanded
variables in a path?)




Re: bash expanding relative paths in auto-complete

2015-08-14 Thread Andreas Schwab
Linda Walsh b...@tlinx.org writes:

 in bash 4.3.39,
 if I type a command, (like .(source)) and a relative path
 like : ../confcomplete,
 it expands the relative pathname to absolute pathnames.

Worksforme.  Make sure to run complete -r first.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.



Re: bash expanding relative paths in auto-complete

2015-08-14 Thread Linda Walsh



Andreas Schwab wrote:

Linda Walsh b...@tlinx.org writes:


in bash 4.3.39,
if I type a command, (like .(source)) and a relative path
like : ../confcomplete,
it expands the relative pathname to absolute pathnames.


Worksforme.  Make sure to run complete -r first.

---
Nope -- didn't change anything.

But throwing in a complete -D prevented any expansions 
until I typed in complete -r again.


complete -r says to remove all completion specifications.

I tried complete -p ../lcomplete -- and that printed
out all the files starting w/'l' in my 'bin' dir
(currently in ~/bin/sys;  so from there, I can type 
ls ../lib and see all the lib supporting stuff under ~/bin/lib, but

it changes a typed ls ../l - ls /home/law/bin/l

Also tried a clean environment:
env bash --norc --noprofile -- and that undefined my
aliases until I typed a new command:

Ishtar:law/bin/sys env bash --norc --noprofile
bash: _pf: command not found
...elided 22 copies of same ...
bash: _pf: command not found
Ishtar: which bash ##short prompt
/bin/bash
Ishtar:law/bin/sys
=
Notice the 1st prompt before I type which bash doesn't
show the 'cwd' (_pf, BTW, is an alias for printf for when I'm
writing out my spwd (short pwd) to print out a shortened
version of my current directory for my prompt and window title).

I do have expand_tilde, but I'm not using a tilde and the
same happens in:

Ishtar:/etc/local ls ../rc.
rc.d@  rc.splash  rc.status.orig rc.status.rpmsave*
rc.include rc.status  rc.status.rpmorig* rc.status.systemd
Ishtar:/etc/local ls /etc/rc.  -- .. changed to /etc

I ran into this, BTW, when I was looking at a src-tree that used
symlinks w/abs. paths, so when I ran it with make clean,
the symlinks pointed at the real root-based binaries rather than
the tree-based binaries.  


This resulted in rmx -fr * (rmx=rm --one-file-system) not seeing that the
symlinks (or mount-points) in the starting dir were on different
file systems and rm only checks to see that *descendants* of cmdline-args
are on the same FS -- which used to not be a problem when you could
do an rmx -fr . which would delete the contents before failing on .
at the end (w/msg suppressed by -f).

Sigh.