Re: write a command line.

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 14/04/12 12:03 PM, Bart Schaefer wrote:
> On Sat, Apr 14, 2012 at 8:43 AM, Ray Andrews<rayandrews@xxxxxxxxxxx>  wrote:
> > It's mostly a question of knowing how to express the problem.
> This can indeed be the most difficult part, particularly becoming
> familiar with the terminology.  Just as an example:
Right. Especially when Googling, one must use the correct words.  But 
Mikael is smarter than Google so he sees what I want even though my 
terminology is poor.

Another problem is that one's knowledge of an OS is like an iceberg, 90% 
of it is underwater.  Those who are longtime users of Linux/zsh take a 
huge number of things for granted which means that most of what they 
know they know without knowing that they know it, so to speak.  For the 
new person, coming from DOS or Windows, that body of unconcious 
knowledge is quite different so many assumptions are wrong.
> > Now I can just create my command inside
> > the script, save it as '$string' and: 'print -z $string'  does the trick.
> Usually a "script" refers to something that runs as a stand-alone
> program separate from an interactive shell.  "print -z" in a script
> would be meaningless, whereas your original solution of appending to
> the incrementally-shared history file works perfectly for such an
> external program.  If "print -z" really works for you, you must be
> referring to a "function" rather than a "script.
Well, as a trivial example, this works:

#!/usr/bin/zsh

export string="echo $PATH"
print -z $string

> >   The way I've expressed it, people seem
> > to think I'm looking for something complicated.
> An extremely common mistake is:
>
> I have problem X.  I come up with a solution which involves steps A,
> B, C, and D, but I run into a problem at step C.  Instead of
> describing the original problem X, I attempt to describe the execution
> of C, and everyone gets lost in the details.  If I'd described X in
> the first place, I might have learned that I was already going wrong
> at step B, which is why C is causing such a headache.
>
> The best part about starting with X is that *usually* the description
> of X does not need to discuss whether the solution involves a script
> or a function or any of the other terminology that might cause
> confusion.
Very true.  For example with my problem people were trying to help me 
with 'zle' and 'bindkey' whereas the real problem was ignored.  Mikael 
saw that 'zle' and 'bindkey' are irrelevant, they are only 'A,B,C' 
whereas what is wanted is 'X'.