From: Ray Andrews <rayandrews@eastlink.ca>
To: zsh-users@zsh.org
Subject: Re: .zsh_history
Date: Sun, 16 Apr 2023 07:53:30 -0700 [thread overview]
Message-ID: <1decbc88-2df8-8aff-3e2c-72e66fbae5de@eastlink.ca> (raw)
In-Reply-To: <CAN=4vMqXY8tgT+zm07BXYZZt4rdAnFQwZveoQJHZoPeWyXNG6g@mail.gmail.com>
On 2023-04-16 00:38, Roman Perepelitsa wrote:
> On Sat, Apr 15, 2023 at 5:31 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> $ my_function $path $(eval 'ls *') one two three ! < > ``.."" &>^!
>>
>> my tail, exactly as typed, is: $path $(eval 'ls *') one two three ! < >
>> ``.."" &>^!
> What would this do?
>
> % list=(my_function arg)
> % $list
>
> What I typed is `$list`, but what is "tail"?
>
> Roman.
I don't understand. You're assigning a variable no? In that case 'arg'
.... hmmmm .... good question. In practice the problem wouldn't arise,
I'm concerned with newly typed keystrokes. In theory tho that's quite
mind stretching. Is there a logical necessity or are options
available? My first stab at it would be that any syntax enclosing
'my_function' must needs be executed as normal since there's no way of
'pre-knowing' that my_function wants special access to its tail as raw
keystrokes. Or, not? Naively the tail is just 'arg'. Dunno, whatever
history does is what I want. History stores commands as typed and
that's what I want. There's just that: "% echo one; echo two; echo
three" problem -- I'd like the middle 'echo' to know that it's tail is
'two' and nothing more or nothing less but of course recall from history
gives all three commands in one serving.
% my_function one; my_function $PATH; my_function three > filename
my tail, exactly as typed, is: one
my tail, exactly as typed, is: $PATH
my tail, exactly as typed, is: three > filename
... I guess the semicolon is the character that must logically end the
tail and can't be part of the tail for obvious reasons. Or in practice
the ENTER key cuz I'm never actually going to chain these commands which
is why in practice just writing to history and recalling from history
works fine (along with 'noglob') ... but it's laborious. And one
intuitively sees that zle will be a good candidate for a solution
because once ENTER is pressed, what it has in it's buffer must needs be
a sequence of raw keystrokes. Give me those keystrokes! Raw. On the
half-shell. But, broken by semicolons so that chained commands know
where their own tail ends. Thing is that the shell obviously does all
this internally -- chained commands are obviously broken down into their
individual units at the semicolon. The information is obviously there I
just want to see it prior to expansion.
I'm not communicating any of this well. If I wasn't me I'd not be
understanding these posts myself, they are not clear.
next prev parent reply other threads:[~2023-04-16 14:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-08 16:16 .zsh_history Perry Smith
2023-04-08 16:53 ` .zsh_history Roman Perepelitsa
2023-04-08 17:23 ` .zsh_history Ray Andrews
2023-04-08 17:27 ` .zsh_history Roman Perepelitsa
2023-04-08 17:35 ` .zsh_history Perry Smith
2023-04-08 17:54 ` .zsh_history Ray Andrews
2023-04-14 14:36 ` .zsh_history Felipe Contreras
2023-04-14 15:27 ` .zsh_history Ray Andrews
2023-04-15 4:49 ` .zsh_history Felipe Contreras
2023-04-15 15:29 ` .zsh_history Ray Andrews
2023-04-15 19:47 ` "Pull just the text of a single command" (was Re: .zsh_history) Bart Schaefer
2023-04-15 22:47 ` Ray Andrews
2023-04-15 23:26 ` Bart Schaefer
2023-04-16 15:53 ` Bart Schaefer
2023-04-16 16:37 ` Ray Andrews
2023-04-16 19:24 ` Ray Andrews
2023-04-16 7:38 ` .zsh_history Roman Perepelitsa
2023-04-16 14:53 ` Ray Andrews [this message]
2023-04-16 15:28 ` .zsh_history Bart Schaefer
2023-04-16 15:29 ` .zsh_history Roman Perepelitsa
2023-04-14 14:28 ` .zsh_history Felipe Contreras
2023-04-14 15:18 ` .zsh_history Ray Andrews
2023-04-14 14:00 ` .zsh_history Felipe Contreras
2023-04-14 14:51 ` .zsh_history Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1decbc88-2df8-8aff-3e2c-72e66fbae5de@eastlink.ca \
--to=rayandrews@eastlink.ca \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).