From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21459 invoked by alias); 4 Jan 2015 20:50:03 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 19689 Received: (qmail 9025 invoked from network); 4 Jan 2015 20:49:49 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Authority-Analysis: v=2.1 cv=T/C1EZ6Q c=1 sm=1 tr=0 a=POX++im/jDXCAosQcDcdLQ==:117 a=POX++im/jDXCAosQcDcdLQ==:17 a=Hpgzp-inWqAA:10 a=N659UExz7-8A:10 a=K9vnTqgtx-4d2Q3w8TQA:9 a=pILNOxqGKmIA:10 Message-id: <54A9A76A.7020303@eastlink.ca> Date: Sun, 04 Jan 2015 12:49:46 -0800 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-version: 1.0 To: zsh-users@zsh.org Subject: Re: symlink chain. References: <549E3A7B.9010209@eastlink.ca> <20150102170307.7d2e644a@ntlworld.com> <54A6E6B1.6070201@eastlink.ca> <20150102212422.3a761af5@ntlworld.com> <54A7136C.1060102@eastlink.ca> <20150102222140.1303a633@ntlworld.com> <54A72CEF.9090102@eastlink.ca> <54A740F3.4040902@eastlink.ca> <150102210337.ZM22099@torch.brasslantern.com> <54A783C3.3000006@eastlink.ca> <150102231734.ZM22168@torch.brasslantern.com> <54A82374.1030208@eastlink.ca> <150103120252.ZM23074@torch.brasslantern.com> <54A85B6C.4020103@eastlink.ca> <150103164002.ZM23676@torch.brasslantern.com> <54A8B4EE.30908@eastlink.ca> <150104003130.ZM24261@torch.brasslantern.com> In-reply-to: <150104003130.ZM24261@torch.brasslantern.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit On 01/04/2015 12:31 AM, Bart Schaefer wrote: Sorry for the length of this, most will not want to read it. > On Jan 3, 7:35pm, Ray Andrews wrote: > } > } I take the more superficial view and don't want -m killing a search > } that would work fine without it. I expect -m to *just* *add* the > } ability to search for patterns, not to kill otherwise acceptable > } searches. > > There are a couple of ways in which this is eventually going to get > you into trouble. > > First, whence is not the only command where some switches are mutually > exclusive rather than cumulative, or where switches change many details > of the action performed even when they can be combined. I'm glad you're still interested in this, because I'd like to flog it right to death myself. I'm actually trying to study the subject of switches with rigor, and it's quite astonishing how much taxonomy and logic can go into what might seem like a very simple subject. It turns out that poor old whence is a useful test case for this. So, we certainly have cumulative switches 'whence -v -s -S -a': show me matches && show verbose info && expand sysmlinks && expand full chains of symlinks (-S subsumes -s) && (now, with Peter's change) show all matches on the path, not just the first (if there is only one match, then that's just fine). Note, that none of these switches interfere with any other, and none force any limitation on the argument-- what 'whence' can eat it can still eat with any and/or all of those switches. (But that was not the case with -a previously). IMHO, this is 'good'. We have minimal gotchas, minimal exceptions and maximum utility. In short, the man page is shorter, our wrench works on Tuesdays too! There is, at one and the same time, more power *and* less to learn. And we certainly have mutually exclusive switches 'whence -v -c -w': Only one can be true at any given time, but that's the nature of the thing, I'd say that this is intuitively acceptable, and not limiting in any way, dinner is served on silver, or on china, it can't be both. And yes, we have naturally limiting switches: 'ls -B': ignore backups. But, would we not agree that it is the natural thing to prefer cumulative switches over limiting switches? Is it not intuitive that as you 'add' switches you 'add' features? No rule there, just a preference. (BTW, you convinced me of that yourself not too long ago, I was wanting something to come with all bells and whistles blowing by default, and that was a juvenile mistake, as you showed me.) And then we have the question of the 'smartness' of switches. 'ls -g': group directories first. Imagine if the output was nothing if it turned out that there *were* no directories to sort first. IOW, 'ls -g' returns nothing even tho there are lots of files because there are no directories to sort. Not very friendly eh? As I put it, when -g has nothing to do it just does nothing (and it certainly does not sabotage the output). I'm wanting 'whence -m' to be smart the same way as 'ls -g' is smart. I'm wanting it to 'add' functionality without constraining the arguments. My thinking being that that maximizes utility without breaking anything because -m will just 'step aside' when the argument is not valid for it's intended use. IOW just as 'ls -g' says: "Sort directories first (if there *are* any)" but it does *not* say: "Sort directories first and don't show *anything* if there are no directories", so 'whence -m' should say: "Expand the search to use pattern matching *IF* a pattern is supplied, and if there is no valid pattern supplied then just do nothing. i.e. if a full path is given, then -m just does nothing at all in the same way that 'ls -g' does nothing at all when there are no directories to sort. In practical terms this lets me bury 'whence -mavs $1' inside a wrapper or alias and know that it will work no matter what I throw at it (needless to say, what I throw at it must be legal for bare 'whence'.) The counter argument is to explore what my smart -m would break. What would it break? Now, there is no logical reason why -m should *not* be exclusionary--to abort the search if a valid pattern is not given (as it is now) but is that the most desirable thing? I say that 99% of the time, it is not. But maybe what really defeats me is that I can handle it more or less like this: local ma=ma # Anything with a path in it can't be used with -m or -a! [[ $1 =~ / ]] && ma= find_count=`whence -$ma "$nnocase$1" | wc -l` < micro-rant> I myself will never, ever use a slash for anything but what God meant it to be used for and I think it is monstrous that anyone would think of doing otherwise, nor should zsh even permit such blasphemy. ... That more or less does what Peter's modification does. So all I really have 'left' to argue is that I think it would be polite of whence to handle it for me. I'd like a kinder, gentler zsh. Fat chance ;-) > Second, pattern matching really isn't the same thing as simple string > comparison, and it's also not exactly the same thing as globbing even > though for the shell the same metacharacters are used. I think we > discussed that last part in a different thread. True, as you've explained. But I'm not asking -m to process a full path, I'm asking it to just 'step aside' and do nothing and let whence revert to the 'normal' search, 'intelligently'. (Which BTW, demolishes my 'wrench' analogy ... wrenches have no brains. If I apply a crescent wrench to a pipe, it will not tell me: "Pardon Ray, you need a pipe wrench for this, and I'm an adjustable spanner.") > } Well, one analogy is as good as another. With so many of these issues, > } it comes down to how you look at it. For me, switches add features, > } they don't invalidate arguments ... but is that really a rule? ... > > Switches often change the meaning of arguments. Look at the example > we just went through with (print '\e') vs. (print -r '\e'). Good example. Still -r never 'invalidates' an argument. Imagine if -r forced print to print nothing if there were no escapes for it to handle-- is that not the symmetric comparison with -m? -r is smart, if it has nothing to do, it does nothing. -m should be smart, if it has nothing to do, it does nothing. This is imperfect reasoning, but not without some force. > > } As we were saying it's not really about the slash, I'd say it's more > } a test for an existing, specific file, no? > > Well, no, it's not about that, actually. It's about the difference > between a file path and a pattern. Slashes mean something in a file > path, but in a pattern (as opposed to a glob!) they're just another > character; they might as well be dots or colons or "x" for all that > the pattern matching code cares. Yes, quite right, I figured that out myself last night. It may indeed be that what I want can not be done robustly. If so it must of course be omitted. No matter how friendly it might seem, if it introduces any 'maybes' then it's poison. I probably 'loose' this discussion based on that. And fairly beaten. > ... You're expecting the -m switch to mean "try this as a pattern, but if that doesn't seem to work, then ignore that I used -m and try it the other way too, but only if it actually IS a file path, because file paths work when they aren't patterns." Well, yes, that's exactly it. whence: trynormalstearch || error whence -m: trypatternsearch || trynormalsearch || error Not to strange, is it? Just for arguments sake we could: whence -m: trypatternsearch || error whence -M: trypatternsearch || trynormalsearch || error ... so -m would remain unchanged, and -M would give me what I want. In code terms, it would introduce a 'goto' (try again as a normal search). As -S expands on -s, so -M would expand on -m. In the manual: " -M will attempt a pattern match, (as -m), but will then attempt a normal match if the pattern match fails. This can be useful where whence is used in, say, an alias that might receive either a normal argument, or a pattern argument." We'd have it both ways. So IMHO the question becomes, would that add utility? I say it would. Do I need it, strictly speaking? No. Could it be coded robustly, without breaking anything? That's for you guys to decide. (But Peter likes it for -a at least even if not for -m, but I think the implementation is more of a 'try again' at failure than a filtering out of the slash up front). > You think the current interpretation sabotages the output. It does! > I think your expected interpretation sabotages the inputs. Maybe :( > Which is why I'm spending all this time trying to explain myself. It will be worth it in the long run. I think my 'challenge' is valid, but it is not certain that it should triumph. But if it fails, then (given it's obvious superficial utility) the reasons should be very clear. These conclusions will apply widely. > } I hafta learn how to do this patching (I don't want to blow something up > } doing it wrong) and I have to learn how to ask git to preserve any local > } changes while still pulling whatever needs to be pulled. > > If you "git commit" your changes and then use "git pull --rebase" you > should have what you want most of the time, unless some of the changes > in origin/master are in direct conflict with what you committed. Many thanks. I've stopped reading the manual, hafta get back to it. > You just have to be careful about "git push" in that case, if you have > permission to do so. Maybe five years from now. > If you have changes you never want to be pushed > to the master, create a branch and commit them there. > Arigato sensei