I have googled for what seems to be an simple and obvious thing but somehow I seem to be unable to find what I'm looking for. So here goes. I have this function, called via keyboard shortcut while editing a line: expandDir2() { zle backward-kill-word local _dir=$CUTBUFFER _dir=${_dir:gs/*/.+/} _dir=${_dir:gs/?/./} _dir=${_dir:gs/:/(?i)/} _dir=$(command grep -hP "$_dir" ~/other/dirlist_*.txt | rofi -dmenu -p \"Directory\") echo Never reached on Esc. [[ "$_dir" == "" ]] && BUFFER=$BUFFER$CUTBUFFER || BUFFER=$BUFFER$_dir CURSOR=$#BUFFER } This basically reads a search string (say "u*sh*z"), greps a set of files with directory lists (created by a custom script) and runs rofi in dmenu mode to select one directory which then replaces the search string. This works very well. The trouble starts when rofi is terminated not via selecting one of the shown directories (exit value 0) but with Esc/Ctrl-G (exit value 1). In this case the function just breaks and I have found no way to actually check for either the returned string of rofi or its exit value. Bash has set +-e and I am sure there is sth similar for zsh but I can't for the life of me find it (I have for now "solved" the problem by writing a two-liner that calls rofi and always returns exit 0 but that's a kludge at best). THX Tom
On Tue, Feb 8, 2022 at 9:16 AM Thomas Lauer <thomas.lauer@virgin.net> wrote:
>
> The trouble starts when rofi is terminated
> not via selecting one of the shown directories (exit value 0) but with
> Esc/Ctrl-G (exit value 1).
>
> In this case the function just breaks
Preface: I have no way to test this directly, I no longer have an X
interface to play with. However, I can't repeat this using a simpler
pipeline that exits 1 from inside the $(...).
Are you sure the exit status is 1? Could instead for example the grep
be receiving a SIGPIPE because rofi stopped reading too soon? I tried
to simulate that, too, but without ill effect.
Zsh does have "set +e" and "set -e" but unless -e (errexit) is in
effect from outside the function you've presented, that shouldn't
matter.
> On Tue, Feb 8, 2022 at 9:16 AM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > > > The trouble starts when rofi is terminated > > not via selecting one of the shown directories (exit value 0) but with > > Esc/Ctrl-G (exit value 1). > > > > In this case the function just breaks > > Are you sure the exit status is 1? Yes. > Could instead for example the grep > be receiving a SIGPIPE because rofi stopped reading too soon? Well... as I wrote in my OP: if I replace the rofi call with a tiny script that does precisely the same thing but *always* exits with error code 0, all works as it should. So I am pretty sure that rofi exiting with 1 is indeed the culprit here.
On Wed, Feb 9, 2022 at 10:45 AM Thomas Lauer <thomas.lauer@virgin.net> wrote:
>
> Well... as I wrote in my OP: if I replace the rofi call with a tiny
> script that does precisely the same thing but *always* exits with error
> code 0, all works as it should. So I am pretty sure that rofi exiting
> with 1 is indeed the culprit here.
If you use your tiny script and replace "exit 0" with "exit $?" (so it
exits with the same status as rofi) does that still reproduce the
problem?
Incidentally, what's the $ZSH_PATCHLEVEL ?
> > Well... as I wrote in my OP: if I replace the rofi call with a tiny > > script that does precisely the same thing but *always* exits with error > > code 0, all works as it should. So I am pretty sure that rofi exiting > > with 1 is indeed the culprit here. > > If you use your tiny script and replace "exit 0" with "exit $?" (so it > exits with the same status as rofi) does that still reproduce the > problem? Yes, the function still breaks. > Incidentally, what's the $ZSH_PATCHLEVEL ? "debian/5.7.1-1" It's no big deal but I find it strange that I can't have a function which executes to the very end when an external call fails.
[-- Attachment #1: Type: text/plain, Size: 640 bytes --] On Thu, 10 Feb 2022 at 14:56, Thomas Lauer <thomas.lauer@virgin.net> wrote: > > > Well... as I wrote in my OP: if I replace the rofi call with a tiny > > > script that does precisely the same thing but *always* exits with error > > > code 0, all works as it should. So I am pretty sure that rofi exiting > > > with 1 is indeed the culprit here. > > > > If you use your tiny script and replace "exit 0" with "exit $?" (so it > > exits with the same status as rofi) does that still reproduce the > > problem? > > Yes, the function still breaks. What happens if you add `emulate -L zsh` (without quotes) at the top of the function? Roman. [-- Attachment #2: Type: text/html, Size: 1097 bytes --]
> From: Roman Perepelitsa <roman.perepelitsa@gmail.com>
>
> What happens if you add `emulate -L zsh` (without quotes) at the top of the
> function?
Something good happens... it now works as I'd expect! Thanks, will have
to read up about this!
Tom
On Thu, Feb 10, 2022 at 5:20 PM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > > From: Roman Perepelitsa <roman.perepelitsa@gmail.com> > > > > What happens if you add `emulate -L zsh` (without quotes) at the top of the > > function? > > Something good happens... it now works as I'd expect! Thanks, will have > to read up about this! This means that err_return option is set in your interactive zsh. This is likely the result of invoking a function that has `setopt err_return` in it without `emulate -L zsh` and without `setopt local_options`. That function needs to be fixed. For example, you could replace `setopt err_return` with `emulate -L zsh -o err_return`. You can read about zsh options and `emulate -L` here: https://zsh.sourceforge.io/Doc/Release/Options.html Roman.
> From: Roman Perepelitsa <roman.perepelitsa@gmail.com>
>
> This means that err_return option is set in your interactive zsh. This
> is likely the result of invoking a function that has `setopt
> err_return` in it without `emulate -L zsh` and without `setopt
> local_options`. That function needs to be fixed. For example, you
> could replace `setopt err_return` with `emulate -L zsh -o err_return`.
>
> You can read about zsh options and `emulate -L` here:
> https://zsh.sourceforge.io/Doc/Release/Options.html
Yep. Indeed, I have err_return set in my .zshrc (there are so many
options there that I have no idea when or even why I did include this).
Removed and things now work w/o "emulate -L zsh".
Appreciate your explanation and help. Tom
On 2022-02-10 09:20, Thomas Lauer wrote:
>
> (there are so many
> options there that I have no idea when or even why I did include this).
>
When I first got involved I learned to turn absolutely everything
'config' off except for my one and only .zshrc file so that I'd at least
know where to look if things went strange. Then I picked a sample
.zshrc on faith off the internet and slowly by trial and error figured
out what half of it does. The other half is still a mystery, mostly the
'complete completer completion completing' stuff -- and I get the
feeling no one really understands it fully anyway. Like with everything
else, the docs assume you are already an expert. But a beginner's guide
to configuration would have sure been nice. I bitched about this a
little bit: the setup utility should offer you several config options
complete with a brief description of what each one offers. Mind, I was
coming from DOS whereas most zsh converts are already shell experts, so
my culture shock was much worse than for most.
--- Ursprüngliche Nachricht --- Von: Ray Andrews <rayandrews@eastlink.ca> Datum: 10.02.2022 22:26:02 An: zsh-users@zsh.org Betreff: Re: zsh function breaks after error On 2022-02-10 09:20, Thomas Lauer wrote: > > (there are so many > options there that I have no idea when or even why I did include this). >mostly the 'complete completer completion completing' stuff -- and I get the feeling no one really understands it fully anyway. I understand and think, we should work out a commented .zshrc step by step project, archiving it, so any newbie has a chance to work out a working .zshrc by himself.
Thomas Paulsen wrote on Thu, 10 Feb 2022 21:45 +00:00: > I understand and think, we should work out a commented .zshrc step by > step project, archiving it, so any newbie has a chance to work out a > working .zshrc by himself. Like this? https://gitlab.com/zsh-sensible/zsh-sensible/ Looking in this list's archives for discussions of zsh-newuser-install should turn up related threads.
> From: Ray Andrews <rayandrews@eastlink.ca>
> On 2022-02-10 09:20, Thomas Lauer wrote:
> >
> > (there are so many
> > options there that I have no idea when or even why I did include this).
> >
> When I first got involved I learned to turn absolutely everything
> 'config' off except for my one and only .zshrc file so that I'd at least
> know where to look if things went strange. Then I picked a sample
> .zshrc on faith off the internet and slowly by trial and error figured
> out what half of it does. The other half is still a mystery, mostly the
> 'complete completer completion completing' stuff -- and I get the
> feeling no one really understands it fully anyway. Like with everything
> else, the docs assume you are already an expert. But a beginner's guide
> to configuration would have sure been nice. I bitched about this a
> little bit: the setup utility should offer you several config options
> complete with a brief description of what each one offers. Mind, I was
> coming from DOS whereas most zsh converts are already shell experts, so
> my culture shock was much worse than for most.
Well... I tend to know what I am doing and I think (or thought) that all
the options in my .zshrc are there for a reason. I literally went
through the options documentation one by one over a few days, looked
into each option and (tried to understand and) decide whether it was a
Good (tm) thing or not. For most options this worked pretty well, but
there were a few which were then over my head (probably some still are).
But I agree that the density of the documentation can be a problem,
especially for people who are no developers and are perhaps not used to
dense docs :-)
I'm a Windows refugee as well but over there I've used a command
processor called Take Command (the former 4NT) for decades and so I was
already used to a powerful and complex beast of a shell.
And yes, the completion still is mostly a mystery but with judicious use
of Google, Stackexchange, Reddit etc etc and a lot of trial and error I
have cobbled together something that works pretty much as I want.
Actually it was the completion that convinced me to drop bash and start
using zsh.
But if there ever was a case of YMMV *and* RTFM then zsh must be it:-)
Tom
> From: "Thomas Paulsen" <thomas.paulsen@firemail.de>
> --- Ursprüngliche Nachricht ---
> Von: Ray Andrews <rayandrews@eastlink.ca>
> Datum: 10.02.2022 22:26:02
> An: zsh-users@zsh.org
> Betreff: Re: zsh function breaks after error
>
> On 2022-02-10 09:20, Thomas Lauer wrote:
> >
> > (there are so many
> > options there that I have no idea when or even why I did include this).
>
> >mostly the 'complete completer completion completing' stuff -- and I get the
> feeling no one really understands it fully anyway.
> I understand and think, we should work out a commented .zshrc step by step project, archiving it, so any newbie has a chance to work out a working .zshrc by himself.
This would certainly help but many things zsh are interconnected in a
way that means that you have to understand something in order to
understand something else... but to understand the first thing you have
to understand the second (I am exaggerating but in a way reading and
trying to digest the zsh docs did remind me of the time when I went
through the Big Blue Book of KIM (this was a 6502-based "microcomputer"
as these things were called then) and tried to understand the 6502 and
its assembler language. I read this book three times before I had the
first tiny glimmer of understanding what it was all about and it took me
another two times to get to grips with the 6502.)
Anyway, if such a project comes into being I would be willing to help
within my capabilities and time constraints. I have written loads of
tech docs over the years so perhaps I could add some value.
Tom
On 2022-02-11 06:58, Thomas Lauer wrote: > > But I agree that the density of the documentation can be a problem, > especially for people who are no developers and are perhaps not used to > dense docs :-) You can say that again. It gets easier with exposure of course, but even now I'd say that zsh/unix/linux docs -- especially the old 'man pages' are often spectacularly badly written. 'Dense' might be a charitable way of putting it. > I'm a Windows refugee as well but over there I've used a command > processor called Take Command (the former 4NT) 4DOS and Take Command ruined me. I got to just taking for granted that level of polished perfection and when I moved over here, the culture shock nearly killed me. > but with judicious use > of Google, Stackexchange, Reddit etc etc and a lot of trial and error > Yeah, resources are out there if you just beat the bushes long enough. Like Daniel's link above. But how about if it were all collated and condensed and brought in-house? > This would certainly help but many things zsh are interconnected in a way that means that you have to understand something in order to understand something else... but to understand the first thing you have to understand the second Heck yes, which is why layering is a good idea. The newbie's 'introduction to zsh config' won't even attempt to tell you everything, it will merely get you to 90% of what might be your eventual, expert configuration, but hold you by the hand and get you there painlessly. 90% of what you want in 10% of the time it would otherwise have taken. Advanced wizards can devote years of study to mastering the remaining 10%. A sample line might have this sort of feel: HISTSIZE=SAVEHIST=20000 #Trust us, you want a big history recall buffer. If your machine is pathetically short of resources make it smaller.
On Fri, Feb 11, 2022 at 8:00 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Yeah, resources are out there if you just beat the bushes long enough.
> But how about if it were all collated and condensed and
> brought in-house?
Consensus is hard. For example, I personally I think tens of
thousands of lines of history is unnecessary no matter how much RAM
you have to throw at it.
The other question that constantly arises is whether the goal is to
make the shell more helpful out of the box for relatively
knowledgeable users, or to make it more attractive to newbies. If the
latter, is the most important thing to give it a flashy appearance?
In either case, where do you draw the line to "get you to 90%"?
On 2022-02-11 15:31, Bart Schaefer wrote: > > Consensus is hard. For example, I personally I think tens of > thousands of lines of history is unnecessary no matter how much RAM > you have to throw at it. I picked that line almost at random. Thinking about it, mine probably is too big. Point is that some reasonable amount of history is something that almost everyone wants. > > The other question that constantly arises is whether the goal is to > make the shell more helpful out of the box for relatively > knowledgeable users, or to make it more attractive to newbies. That's why you have several offerings, from basic to ... well, the 'advanced' configs could almost become rococo fun-fests, just showing off for the fun of it. Don't hafta get anything perfect, just close. I still vividly remember the very first time I got Linux installed and booted. There I am at a stone age prompt and I had some instructions printed off (from Windows) as to what to do next. Well, it was bash of course, but NO history, NO backspace key, NO prompt (to speak of) ... other missing stuff, can't remember ... anyway it was so bloody primitive that DOS looked elegant by comparison. Eventually I got an editor working and I think it was 'joe' or something, that made edlin look sophisticated. I almost quit. Initiation hazing or something? But, after jumping to zsh, I remember when I started thinking about prompts -- I can't remember where but there were samples named 'Oliver's prompt' and 'Bart's prompt' and so on and you picked one and tried it. Marvelous. Tune to perfection later, in the mean time it's very good at least. Suffering is not good for the soul.
> From: Ray Andrews <rayandrews@eastlink.ca> > > On 2022-02-11 06:58, Thomas Lauer wrote: > > > I'm a Windows refugee as well but over there I've used a command > > processor called Take Command (the former 4NT) > 4DOS and Take Command ruined me. I got to just taking for granted that > level of > polished perfection and when I moved over here, the culture shock > nearly killed me. Interesting. Take Command *was* (or is) powerful but IMO it's no match for zsh. I happily invested a lot of time investigating zsh and its options because I found many things immediately appealing. > On 2022-02-11 15:31, Bart Schaefer wrote: > > > > Consensus is hard. For example, I personally I think tens of > > thousands of lines of history is unnecessary no matter how much RAM > > you have to throw at it. > I picked that line almost at random. Thinking about it, mine probably > is too big. > Point is that some reasonable amount of history is something that almost > everyone > wants. I am with Bart on this one. Many so-called "defaults" in all sorts of software, including zsh, are far removed from what I find reasonable (or at least work-flow enhancing). The whole point of "optionising" features is to give people choice. But with that comes of course a learning curve and some responsibility for the choices one makes. Tom
On 2022-02-12 08:45, Thomas Lauer wrote: > > Interesting. Take Command *was* (or is) powerful but IMO it's no match > for zsh. Indeed not. Zsh is 'bigger' and more powerful in every way, but also less consistent. To some degree this is inevitable and quite forgivable. Projects that grow by accretion must encounter this sort of thing and solutions are far from simple. I am with Bart on this one. Many so-called "defaults" in all sorts of > software, including zsh, are far removed from what I find reasonable (or > at least work-flow enhancing). The whole point of "optionising" features > is to give people choice. But with that comes of course a learning curve > and some responsibility for the choices one makes. Sure, so my notion of several different default configurations gives you several possible starting points, and then invites you and helps you to start customizing. The difference is that instead of starting from 'zero', you're starting from one of a suite of configurations that are considered reasonable by real users. And of course the 'zero option' would be there as well so all of the above can be ignored as desired.
On Fri, Feb 11, 2022 at 03:31:08PM -0800, Bart Schaefer wrote: > On Fri, Feb 11, 2022 at 8:00 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > > > Yeah, resources are out there if you just beat the bushes long enough. > > But how about if it were all collated and condensed and > > brought in-house? > > Consensus is hard. For example, I personally I think tens of > thousands of lines of history is unnecessary no matter how much RAM > you have to throw at it. > > The other question that constantly arises is whether the goal is to > make the shell more helpful out of the box for relatively > knowledgeable users, or to make it more attractive to newbies. If the > latter, is the most important thing to give it a flashy appearance? > In either case, where do you draw the line to "get you to 90%"? For shell configuration in particular consensus seems particularly thorny because each user has their own opinions on what's sane. Rather than try to come up with some sane default config, I think zsh-newuser-install goes in the right direction; however, it seems nearly all new users find it intimidating. I've taken a stab at a newuser like wizard but as a webpage to hopefully make it more approachable https://storage.googleapis.com/zsh-guide/index.html If people like it, I can put it on a real domain. The idea is to just be good enough to not need a framework and get running in 5 minutes or so. For what to include I looked at zsh-newuser-install, oh my zsh, zsh4humans, and zsh-sensible. The repo is at https://github.com/phy1729/zsh-guide .