From: David W. Hodgins on 6 Jan 2010 21:27 On Wed, 06 Jan 2010 21:18:42 -0500, Douglas Alan <darkwater42(a)gmail.com> wrote: > that doesn't fix filename completion, which was what I've been asking > about all along. Filename completion, and nothing but filename > completion. Sorry. Can you give an example of filename completion where the difference between physical directory structure and logical structure causes a problem? I can't think of any examples, off hand, where this would matter. Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.)
From: Alan Curry on 6 Jan 2010 21:47 In article <194fa019-079c-48ac-9e9a-7beb912f146f(a)a15g2000yqm.googlegroups.com>, Douglas Alan <darkwater42(a)gmail.com> wrote: > > Unfortunately, bash still doesn't obey the physical directory >structure for FILENAME COMPLETION. > >I.e., what happens when you press <TAB> to complete the name of a >file. Why don't you show us what you meant with an actual example, in which you have set -P and it still doesn't do what you want?
From: Douglas Alan on 6 Jan 2010 21:55 On Jan 6, 6:28 pm, "Chris F.A. Johnson" <cfajohn...(a)gmail.com> wrote: > > If you type <CR> instead of <TAB>, however, ls will show you the > > contents of the root directory, as it should. > > No, it shows the contents of shortcuts, as it should. Then you either didn't follow my instructions, or you have a very different version of bash from all the ones that I have. > > $ set -P > > $ cd shortcuts/etc/.. > > > Now the working directory is "/". And all is good. > > For me the working directory is now shortcuts, as I would expect > (and want). Then you either didn't follow my instructions, or you have a very different version of bash from all the ones that I have. In any case, with all due respect, what you prefer is irrelevant to this discussion. I'm asking how to configure bash so that it works the way that *I* want it to, not to configure it the way that *you* want it to. When I tell a computer to open the file or directory named "..", then that's what I want it do to. I don't want it second guessing me. I know what I'm doing, thank you. |>ouglas
From: Douglas Alan on 6 Jan 2010 22:00 On Jan 6, 9:47 pm, pac...(a)kosh.dhis.org (Alan Curry) wrote: > Why don't you show us what you meant with an actual example, in which you > have set -P and it still doesn't do what you want? I already did, when I wrote previously: When you type the <TAB>, bash will show you the contents of "shortcuts", rather than the contents of "/". This is the behavior that I strongly dislike, and doesn't obey standard Unix semantics. I.e., bash sees the ".." and decides rather than interpreting it as the ".." directory entry in the "shortcuts/etc" directory, to interpret it as just chopping off the previous path component. |>ouglas
From: Douglas Alan on 6 Jan 2010 22:08 On Jan 6, 9:27 pm, "David W. Hodgins" <dwhodg...(a)nomail.afraid.org> wrote: > Sorry. Can you give an example of filename completion where > the difference between physical directory structure and > logical structure causes a problem? I can't think of any > examples, off hand, where this would matter. I often have symlink shortcuts that point to various places in the filesystem, and I *know* where the link points to. I'm using the symlink as a shortcut, so that I don't have to type as much. When I use ".." I want to use the UNIX meaning of "open the directory named ..", which to UNIX also means, "open the parent directory of the directory where '..' is located". I know what I'm doing, and I don't want bash second-guessing me. I don't want bash to interpret ".." as strip off the previous path component. I want the UNIX meaning of ".." which is "the parent directory". Btw, the way I want bash to behave for me is the way the Bourne Shell behaves, the way that the Korn shell behaves, the way the csh behaves, the way the tcsh behaves, AND the way that the zsh behaves. So PLEASE don't tell me that I'm asking for something weird. I just want bash to behave the same way in this regard as *every* other shell. |>ouglas
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: multiple scp using xargs Next: bash first occurrence in log file |