Re: symlink chain.

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

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