|
From: | Linda Walsh |
Subject: | Re: bug? "type -P xxx" returns "xxx" that isn't executable...(or readable) |
Date: | Fri, 01 Aug 2014 14:44:58 -0700 |
User-agent: | Thunderbird |
Greg Wooledge wrote:
On Thu, Jul 31, 2014 at 11:40:18PM -0700, Linda Walsh wrote:Ishtar:/> ll {,/usr}/bin/echo -rw-r--r-- 2 136753 Nov 19 2013 /bin/echo --w------- 2 136753 Nov 19 2013 /usr/bin/echosudo chmod +x /bin/echoIshtar:/> type -P echo /bin/echo #correctHow is that correct? Neither of them is executable.
--- Did you miss the "chmod" right below the "ll"?
Bash behaves as expected in POSIX compatibility mode: golem:~$ bash --posix -c 'command -v kumquat' golem:~$ bash -c 'command -v kumquat' /home/greg/bin/kumquat In non-POSIX-compatibility mode, I guess you just have to iterate through PATH yourself, or iterate through the results of "type -a". (Or toggle POSIX compatibility on just for this check.)
--- There are bugs in toggling on POSIX compatibility in that toggling it on, then off, doesn't get you back to your starting state. Example is remapping of the completion key. Go into posix, it remaps it to some value (I assume you cannot remap completion keys in posix, else there is no reason to reset the completion key at this point). Then go back -- the TAB key is unmapped as a completion char, but your old completion key is not remapped. So you end up with no completion keys. There are probably lots of other "one-way-adjustments", but I haven't hit them all. So the shell is less functional in non-posix mode in this case because functionality isn't required? Um... and people wonder why we end up with more requirements and regulation...
[Prev in Thread] | Current Thread | [Next in Thread] |