write a command line.

write a command line.

[Ray Andrews]

Gentlemen,

Back to attempting suicide by zsh.

Just kidding, I'm sure if I could live to be 200 by then this would all 
make perfect sense.
It's awesome that you guys have some grasp of all this.

Anyway, for now I'm trying to make a script that will create but *not* 
execute a command. That is to say it  will write a string (which will be 
a command) to the command line but not press the ENTER key. Rather, when 
the script exits it will just leave the created string on the command 
line so that I can modify it as needed and *then* I  will press the 
ENTER key at my pleasure.

A guy at StackOverflow came up with this:


function hello ()
{
BUFFER=hellothere
zle end-of-line
}
zle -N hello
#bind to Alt+a:
bindkey "\ea" hello

... Which does exactly what I want when I press 'Alt+a' , but I don't 
want to bind a key, I just want to 'do it', that is to leave 
"hellothere" on the command line after my script exits.

I tried to fool around with the 'hello' function but I can't get it to 
run by itself from the command line. With 'autoload -U zle' in my .zshrc 
I get:

     zle: function definition file not found

... with my .zshrc unmodified I get:

     zle: widgets can only be called when ZLE is active

Apart from that, the closest I've come so far is to have my script echo 
the command it generates to the history file just before quitting. I can 
then use the up arrow to retrieve it, modify it as required, and then 
execute it. If there was some way of performing an 'auto up arrow' that 
would do it I think.  But I can't believe that  zsh doesn't have some 
simple way of writing some string to the prompt line and just leaving it 
there.

Regards,

Re: write a command line.

[Mikael Magnusson]

On 13 April 2012 19:15, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Gentlemen,
[...]
> But I can't believe that  zsh doesn't have some simple way of
> writing some string to the prompt line and just leaving it there.

print -z hello

-- 
Mikael Magnusson

Re: write a command line.

[Bryan Hunt]

On Fri, 13 Apr 2012 10:15:39 -0700, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Gentlemen,
> 
> Back to attempting suicide by zsh.

  Sounds like a really convoluted way of doing easy stuff.

  bindkey -v
  autoload -U edit-command-line
  zle -N edit-command-line
  bindkey '^E' edit-command-line

  Press ctrl-e to edit command line of arbitrary complexity.

  Works from vi insert mode, does not work from vi command mode.

  Best Regards,

  Bryan Hunt

Re: write a command line.

[Ray Andrews]

On 13/04/12 10:55 AM, Mikael Magnusson wrote:
> On 13 April 2012 19:15, Ray Andrews<rayandrews@eastlink.ca>  wrote:
>> Gentlemen,
> [...]
>> But I can't believe that  zsh doesn't have some simple way of
>> writing some string to the prompt line and just leaving it there.
> print -z hello
>
Mikael,

Thanks, that's exactly what I want. Now I can just create my command 
inside the script, save it as '$string' and: 'print -z $string'  does 
the trick.  I expected the answer would be dead simple but it is amazing 
how hard it can be to find an answer to even something  so basic.  It's 
mostly a question of knowing how to express the problem.  The way I've 
expressed it, people seem to think I'm looking for something complicated.

Re: write a command line.

[Bart Schaefer]

On Sat, Apr 14, 2012 at 8:43 AM, Ray Andrews <rayandrews@eastlink.ca> 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:

> 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.

> 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.

Re: write a command line.

[Ray Andrews]

On 14/04/12 12:03 PM, Bart Schaefer wrote:
> On Sat, Apr 14, 2012 at 8:43 AM, Ray Andrews<rayandrews@eastlink.ca>  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'.

Re: write a command line.

[Bart Schaefer]

On Sat, Apr 14, 2012 at 12:42 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 14/04/12 12:03 PM, Bart Schaefer wrote:
>>
>> 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

In saying "this works" you've still only told half the story.  How do
those several lines of code get executed?  Apparently they're in a
file.  Do you read that file with the "source" command (or its cryptic
synonym ".")?  Do you pass the file name to "autoload" and then type
its name?  Or do you just put the file in a directory in your $path
somewhere and then type its name?

The most common meaning of "script" is the last of those, and the next
most common is the first of those, but only the first two will do
anything useful with "print -z".  If you did the second,
congratulations, you've made a "function" -- that's what autoload
does, it creates functions.

>> 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.
>>
> 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'.

With all respect, you've missed the point.  You've never yet explained
what problem you have that is solved by this script that contains
"print -z".  Having a script or function to construct something to put
on the command line for you to edit is a step B for which "print -z"
is step C and you doing the editing is step D.  But why did you need
to get there in the first place?

The people who were telling you about zle and bindkey were attempting
to guess what X is.  Mikael just ignored that and answered your
question in the most direct way possible.  (Of course I'm now
answering in the most indirect way possible. :-)

For example, given the snippet above that you say works the way you
want it to, I might also try to guess what X is, and ask:  Have you
tried the "vared" command?

% vared path