* Read/write multiple histories from non-interactive shell
@ 2023-02-13 7:35 OG Code Poet
2023-02-13 7:43 ` Lawrence Velázquez
2023-02-13 8:18 ` Roman Perepelitsa
0 siblings, 2 replies; 6+ messages in thread
From: OG Code Poet @ 2023-02-13 7:35 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
Let's say there is a non-interactive script with multiple form fields (each
with a different vared), and a user can enter the form multiple times. I
want to preserve individual history for each form field.
There are two possibilities:
1. Keep history internal to the script
I couldn't find an interface for this. Doing ``fc -p`` once in the
beginning of script does provide an internal history, but it is shared
between all vareds (which is not ideal).
2. Keep history external to the script
Not all ``fc`` commands work. ``fc -R`` does read correctly from
external history files. But ``print -s``, ``fc-W`` and ``fc -A`` do not.
Seems the only option is to do an echo "$string"
>>~/path//form_entry_1.hist file. But I guess that has disadvantages
because it lacks the benefits that zsh provides in resolving duplicates.
Is there a way out? Should this also be copied to zsh-workers for feature
request?
Thanks!
P.S. I can be slow to respond.
[-- Attachment #2: Type: text/html, Size: 1187 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Read/write multiple histories from non-interactive shell
2023-02-13 7:35 Read/write multiple histories from non-interactive shell OG Code Poet
@ 2023-02-13 7:43 ` Lawrence Velázquez
2023-02-13 8:18 ` Roman Perepelitsa
1 sibling, 0 replies; 6+ messages in thread
From: Lawrence Velázquez @ 2023-02-13 7:43 UTC (permalink / raw)
To: OG Code Poet; +Cc: zsh-users
On Mon, Feb 13, 2023, at 2:35 AM, OG Code Poet wrote:
> Should this also be copied to zsh-workers for feature request?
No, zsh-users is already forwarded to zsh-workers automatically.
--
vq
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Read/write multiple histories from non-interactive shell
2023-02-13 7:35 Read/write multiple histories from non-interactive shell OG Code Poet
2023-02-13 7:43 ` Lawrence Velázquez
@ 2023-02-13 8:18 ` Roman Perepelitsa
2023-02-13 8:57 ` OG Code Poet
1 sibling, 1 reply; 6+ messages in thread
From: Roman Perepelitsa @ 2023-02-13 8:18 UTC (permalink / raw)
To: OG Code Poet; +Cc: zsh-users
On Mon, Feb 13, 2023 at 8:36 AM OG Code Poet <ogcodepoet@gmail.com> wrote:
>
> Let's say there is a non-interactive script with multiple form fields (each with a different vared), and a user can enter the form multiple times. I want to preserve individual history for each form field.
>
> There are two possibilities:
>
> 1. Keep history internal to the script
> I couldn't find an interface for this. Doing ``fc -p`` once in the beginning of script does provide an internal history, but it is shared between all vareds (which is not ideal).
> 2. Keep history external to the script
> Not all ``fc`` commands work. ``fc -R`` does read correctly from external history files. But ``print -s``, ``fc-W`` and ``fc -A`` do not. Seems the only option is to do an echo "$string" >>~/path//form_entry_1.hist file. But I guess that has disadvantages because it lacks the benefits that zsh provides in resolving duplicates.
>
> Is there a way out? Should this also be copied to zsh-workers for feature request?
How about this?
#!/usr/bin/env -S zsh -fi
histdir=~/.formhist
mkdir -p -- $histdir || exit
function read-field() {
emulate -L zsh
local var=$1
local desc=$2
fc -pa $histdir/$var 1000 1000
trap 'exit 130' INT
vared -hep "Enter $desc: " -c $var || exit
print -rs -- ${(P)var}
}
while true; do
read-field first_name '%F{green}First Name%f'
typeset -p first_name
unset first_name
read-field email '%F{yellow}Email Address%f'
typeset -p email
unset email
done
The trap is a workaround for what looks like a bug. Without it, if
interrupt vared with Ctrl-C, the history file gets truncated to its
first entry.
Roman.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Read/write multiple histories from non-interactive shell
2023-02-13 8:18 ` Roman Perepelitsa
@ 2023-02-13 8:57 ` OG Code Poet
2023-02-13 9:43 ` Roman Perepelitsa
0 siblings, 1 reply; 6+ messages in thread
From: OG Code Poet @ 2023-02-13 8:57 UTC (permalink / raw)
To: Roman Perepelitsa; +Cc: zsh-users
[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]
I tried pretty much same code but without "zsh -i", that's why the subject
says "non-interactive". My larger script misbehaves and exits with 0 before
it could complete if I replace #!/usr/bin/env zsh with #!/usr/bin/env -S
zsh -fi or #!/usr/bin/env -S zsh -i. Is there a restriction on starting any
existing functional zsh program with -fi? Put another way, are all
non-interactive shell scripts guaranteed to function when shebang is
changed to #!/usr/bin/env -S zsh -fi??
On Mon, Feb 13, 2023 at 12:18 AM Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:
> On Mon, Feb 13, 2023 at 8:36 AM OG Code Poet <ogcodepoet@gmail.com> wrote:
> >
> > Let's say there is a non-interactive script with multiple form fields
> (each with a different vared), and a user can enter the form multiple
> times. I want to preserve individual history for each form field.
> >
> > There are two possibilities:
> >
> > 1. Keep history internal to the script
> > I couldn't find an interface for this. Doing ``fc -p`` once in
> the beginning of script does provide an internal history, but it is shared
> between all vareds (which is not ideal).
> > 2. Keep history external to the script
> > Not all ``fc`` commands work. ``fc -R`` does read correctly from
> external history files. But ``print -s``, ``fc-W`` and ``fc -A`` do not.
> Seems the only option is to do an echo "$string"
> >>~/path//form_entry_1.hist file. But I guess that has disadvantages
> because it lacks the benefits that zsh provides in resolving duplicates.
> >
> > Is there a way out? Should this also be copied to zsh-workers for
> feature request?
>
> How about this?
>
> #!/usr/bin/env -S zsh -fi
>
> histdir=~/.formhist
> mkdir -p -- $histdir || exit
>
> function read-field() {
> emulate -L zsh
> local var=$1
> local desc=$2
> fc -pa $histdir/$var 1000 1000
> trap 'exit 130' INT
> vared -hep "Enter $desc: " -c $var || exit
> print -rs -- ${(P)var}
> }
>
> while true; do
> read-field first_name '%F{green}First Name%f'
> typeset -p first_name
> unset first_name
>
> read-field email '%F{yellow}Email Address%f'
> typeset -p email
> unset email
> done
>
> The trap is a workaround for what looks like a bug. Without it, if
> interrupt vared with Ctrl-C, the history file gets truncated to its
> first entry.
>
> Roman.
>
[-- Attachment #2: Type: text/html, Size: 3122 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Read/write multiple histories from non-interactive shell
2023-02-13 8:57 ` OG Code Poet
@ 2023-02-13 9:43 ` Roman Perepelitsa
2023-02-16 6:14 ` OG Code Poet
0 siblings, 1 reply; 6+ messages in thread
From: Roman Perepelitsa @ 2023-02-13 9:43 UTC (permalink / raw)
To: OG Code Poet; +Cc: zsh-users
On Mon, Feb 13, 2023 at 9:57 AM OG Code Poet <ogcodepoet@gmail.com> wrote:
>
> My larger script misbehaves and exits with 0 before it could
> complete if I replace #!/usr/bin/env zsh with #!/usr/bin/env -S zsh
> -fi or #!/usr/bin/env -S zsh -i.
You might want to try to figure out why.
> Is there a restriction on starting any existing functional zsh
> program with -fi? Put another way, are all non-interactive shell
> scripts guaranteed to function when shebang is changed to
> #!/usr/bin/env -S zsh -fi??
If you put something like this in a script, it won't work the same way
in interactive shell:
[[ -o interactive ]] && exit
In general, if your script needs interactive features, it makes
perfect sense to use an interactive shell as the interpreter.
Roman.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Read/write multiple histories from non-interactive shell
2023-02-13 9:43 ` Roman Perepelitsa
@ 2023-02-16 6:14 ` OG Code Poet
0 siblings, 0 replies; 6+ messages in thread
From: OG Code Poet @ 2023-02-16 6:14 UTC (permalink / raw)
To: Roman Perepelitsa; +Cc: zsh-users
[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]
I wish it were that simple a case. Turns out there are other cases where a
script that runs well in non-interactive move would crash when run with -i.
In my case it was trap for TSTP. A workaround is to put ``setopt
nomonitor``, which in my case is valid as I don't need job control. Though
what is interesting is that the script ends with an error code of 0. Anyway
the exit behavior itself is inconsitent. Try two experiments: 1) add ``trap
'foo=1' TSTP`` as first line of your sample code in this thread. This time
zsh would complain but not exit. 2) add ``trap 'foo=1' TSTP`` to your
function read-field() or in while loop. This time zsh will exit with error
code 1. In my script, where the trap is somewhere in 3 or 4th level
function in the stack, the script exits with exit code 0.
Here's the link to relevant part of code:
https://github.com/zsh-users/zsh/blob/b1533066ca7d50c88b37ce72093c12cf19807818/Src/signals.c#L921-L924
```
if (jobbing && (sig == SIGTTOU || sig == SIGTSTP || sig == SIGTTIN)) {
zerr("can't trap SIG%s in interactive shells", sigs[sig]);
return 1;
}
```
I figured ``setopt nomonitor`` disables jobbing, and bypasses executing
that if block.
On Mon, Feb 13, 2023 at 1:43 AM Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:
> On Mon, Feb 13, 2023 at 9:57 AM OG Code Poet <ogcodepoet@gmail.com> wrote:
> >
> > My larger script misbehaves and exits with 0 before it could
> > complete if I replace #!/usr/bin/env zsh with #!/usr/bin/env -S zsh
> > -fi or #!/usr/bin/env -S zsh -i.
>
> You might want to try to figure out why.
>
> > Is there a restriction on starting any existing functional zsh
> > program with -fi? Put another way, are all non-interactive shell
> > scripts guaranteed to function when shebang is changed to
> > #!/usr/bin/env -S zsh -fi??
>
> If you put something like this in a script, it won't work the same way
> in interactive shell:
>
> [[ -o interactive ]] && exit
>
> In general, if your script needs interactive features, it makes
> perfect sense to use an interactive shell as the interpreter.
>
> Roman.
>
[-- Attachment #2: Type: text/html, Size: 2857 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-02-16 6:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-13 7:35 Read/write multiple histories from non-interactive shell OG Code Poet
2023-02-13 7:43 ` Lawrence Velázquez
2023-02-13 8:18 ` Roman Perepelitsa
2023-02-13 8:57 ` OG Code Poet
2023-02-13 9:43 ` Roman Perepelitsa
2023-02-16 6:14 ` OG Code Poet
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).