On Sat, Mar 16, 2024 at 2:33 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> I'm looking for the name of the *sourced* script. So it would be
> something like $ZSH_SOURCE (if it existed).
I'm back to $funcstack[1] then.
% echo $'print -l $funcstack' > /tmp/saymyname
% Src/zsh -fc 'source /tmp/saymyname'
/tmp/saymyname
On Sat, Mar 16, 2024 at 3:43 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Fri, Mar 15, 2024 at 5:29 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Actually I realized that it's ${(%):-%x} what I'm looking for, since
> > that is the best equivalent for ${BASH_SOURCE[0]}.
> >
> > According to StackOverflow there are no better options [1].
>
> Better in what sense? What are the shortfalls of ${(%):-%x} from your
> point of view?
There aren't any shortfalls, it works fine. It's just complicated.
Given that this seems to be commonly used I just thought perhaps there
was something straightforward like $ZSH_SOURCE.
--
Felipe Contreras
On Fri, Mar 15, 2024 at 5:29 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Actually I realized that it's ${(%):-%x} what I'm looking for, since
> that is the best equivalent for ${BASH_SOURCE[0]}.
>
> According to StackOverflow there are no better options [1].
Better in what sense? What are the shortfalls of ${(%):-%x} from your
point of view?
Roman.
On Fri, Mar 15, 2024 at 11:07 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> On Fri, Mar 15, 2024 at 9:28 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > I meant the name of the source script file
>
> Like $ZSH_SCRIPT ?
No. Le'ts get the terminology straight from zsh manpages:
In describing $0 it says:
If the FUNCTION_ARGZERO option is set, $0 is set ... upon entry to a
sourced script to the name of the script
So when you do "source ./lib.sh" inside that script "./lib.sh" is the
name of the sourced script.
On the other hand this is the description of $ZSH_SCRIPT:
If zsh was invoked to run a script, this is the name of the script
So if "lib.sh" is sourced from "foo.sh", then $ZSH_SCRIPT would be
"foo.sh", whereas ${BASH_SOURCE[0]} would be "./lib.sh".
Both are "names of a script", but one is an "invoked script" and the
other is a "sourced script". Correct?
I'm looking for the name of the *sourced* script. So it would be
something like $ZSH_SOURCE (if it existed).
--
Felipe Contreras
On Fri, Mar 15, 2024 at 9:28 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> I meant the name of the source script file
Like $ZSH_SCRIPT ?
On Wed, Mar 6, 2024 at 11:16 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Wed, Mar 6, 2024 at 1:57 PM Felipe Contreras > <felipe.contreras@gmail.com> wrote: > > > > But what if someone wants to do the opposite? Use the zsh $0 even if > > POSIX_ARGZERO is on? > > Of course the zsh $0 depends on the setting of FUNCTION_ARGZERO, but I > know what you mean. I meant the name of the source script file, which I suppose it's FUNCTION_ARGZERO when you aren't inside a function. In other words: ${BASH_SOURCE[0]}. > > So far I've found that ${(%):-%N} is the best option, but I wonder if > > there is a better one. > > $funcstack[1] would be the other option, unless for some odd reason > the zsh/parameter module is not available. > > An advantage of $funcstack is that you can use > ${${(@)funcstack:#'(anon)'}[1]} to get the name of the nearest > non-anonymous function. Actually I realized that it's ${(%):-%x} what I'm looking for, since that is the best equivalent for ${BASH_SOURCE[0]}. According to StackOverflow there are no better options [1]. Cheers. [1] https://stackoverflow.com/a/28336473/10474 -- Felipe Contreras
2024-03-10 19:53:05 -0400, Mark J. Reed: > On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote: > > > BTW interesting to learn that ksh is still in active development, I > > thought it was on > > ice, like bash. > > > Around twenty years ago, AT&T moved ownership of ksh to their open source > arm, the AT&T Software Technology group (AST), which maintained it as an > open project on GitHub. Quite a few approximations in there (some and omissions at https://en.wikipedia.org/wiki/KornShell as well actually). Github didn't exist 20 years ago. ksh93's code was released as OpenSource around 2000. The code could be downloaded from AT&T research (http://www.research.att.com/sw/download/). See https://web.archive.org/web/20001205164600/http://kornshell.com/ AFAICT, the move to github (and to using git for revision control) didn't happen until 2016. > As with prior releases, the year of the major > release (and corresponding edition of the book) was kept as the "major > revision" number Though contrary to ksh85, ksh86, ksh88 before it, ksh93 was a rewrite from scratch and significantly incompatible. > while subsequent releases incremented an alphabetic > suffix. The last AST release was 93u, released in December 2012 - the 23rd > release of the 1993 version of ksh. https://github.com/att/ast/blob/2016-01-10-beta/src/cmd/ksh93/RELEASE or https://github.com/ksh93/ksh93-history/blob/master/src/cmd/ksh93/RELEASE Ksh93u was released on 2011-02-08, and stable development carried on with two(!) "releases" tagged ksh93u+, and one ksh93v- beta release with a bunch of new, unstable and more experimental than ever features. As there's been some k+, n+... releases, ksh93u is rather the 29th (ksh93a being the second). > After that the codebase was dormant > for a while. Then in 2019 a developer got excited about reviving the > project and updating it. If you're referring to Kurtis Rader, he was active starting around early 2018. > They started with the in-progress incomplete 93v > release, which they called "93v-" It was already called v-, v hadn't been released. > but the result was dubbed "ksh 2020". > 2020 had some bug fixes and improvements, but the code changes were > substantial, performance suffered, there was a lot of drama on the project. > I saw accusations that the new developer was hacking and slashing the > codebase without taking the time to understand it or listen to those who > did. I wasn't paying enough attention to know how valid the criticism was, > but the drama seems to have been enough to torpedo the project. However, if > you run "brew install ksh93" on macOS, 2020.0 is what you get to this day. > > Then some of the 2020 contributors decided to start over from the AT&T > source code, backporting the bug fixes from ksh2020 onto the > last-known-stable 93u, and building up from there. Their approach is to > tread carefully and not do anything drastic. That effort has given us the > ksh93u+X/1.x.y versions, most recently ksh93u+m/1.0.8 at the end of last > year; 1.1.0 is expected soon. No, AFAIK, the m is for Martijn Dekker aka McDutchie, who's at the initiative and main contributor of that new main stable development. He's or at least used to be a contributor to these zsh mailing lists as well, and might be able to give more insight if he's still around here. > The GNU folks haven't been idle, though. The latest official bash release > is 5.2, from 2022, but the patchlevel is up to 5.2.26, and there have been > commits as recently as this week on the devel branch. > > There are still at least bugfixes going into ash and dash (and busybox, > whose sh is based on ash), too. So yeah, Zsh is far from the only > Bourne-family shell still seeing active development. [...] Not to mention yash, mksh (MirBSD and Android shell) and the sh of other BSDs (based on pdksh like on MirBSD or OpenBSD or ash like on NetBSD or FreeBSD). yash despite being much younger could almost be considered to have overtaken bash in terms of feature level. -- Stephane
On 2024-03-10 19:35, Bart Schaefer wrote: > On Sun, Mar 10, 2024 at 7:22 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> Rather dramatic there with ksh. Goes to show you the >> reason that caution should prevail. > A similar thing happened with zsh back in the early 90s when Paul F. > and I both got real jobs (Paul never came back to zsh) I sure do wish he'd show up and say hi. It mystifies me that he's so uncaring of his masterpiece. > and some others > took over for a while. There's a reason you don't really find zsh 2.5 > mentioned anywhere. Of those others ... let's just say they'd rather > have been working on ksh if it had been open sourced then. I do dream of a Grand Unified Shell, where all the talent is focused on a single target. But that's not the way things work. It's a bazaar, not a cathedral. Still the competition is healthy. >
On Sun, Mar 10, 2024 at 7:22 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Rather dramatic there with ksh. Goes to show you the
> reason that caution should prevail.
A similar thing happened with zsh back in the early 90s when Paul F.
and I both got real jobs (Paul never came back to zsh) and some others
took over for a while. There's a reason you don't really find zsh 2.5
mentioned anywhere. Of those others ... let's just say they'd rather
have been working on ksh if it had been open sourced then.
On 2024-03-10 16:53, Mark J. Reed wrote:
>
> There are still at least bugfixes going into ash and dash (and
> busybox, whose sh is based on ash), too. So yeah, Zsh is far from the
> only Bourne-family shell still seeing active
> development.
Thanks Mark. Rather dramatic there with ksh. Goes to show you the
reason that caution should prevail.
[-- Attachment #1: Type: text/plain, Size: 2220 bytes --] On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote: > BTW interesting to learn that ksh is still in active development, I > thought it was on > ice, like bash. Around twenty years ago, AT&T moved ownership of ksh to their open source arm, the AT&T Software Technology group (AST), which maintained it as an open project on GitHub. As with prior releases, the year of the major release (and corresponding edition of the book) was kept as the "major revision" number, while subsequent releases incremented an alphabetic suffix. The last AST release was 93u, released in December 2012 - the 23rd release of the 1993 version of ksh. After that the codebase was dormant for a while. Then in 2019 a developer got excited about reviving the project and updating it. They started with the in-progress incomplete 93v release, which they called "93v-", but the result was dubbed "ksh 2020". 2020 had some bug fixes and improvements, but the code changes were substantial, performance suffered, there was a lot of drama on the project. I saw accusations that the new developer was hacking and slashing the codebase without taking the time to understand it or listen to those who did. I wasn't paying enough attention to know how valid the criticism was, but the drama seems to have been enough to torpedo the project. However, if you run "brew install ksh93" on macOS, 2020.0 is what you get to this day. Then some of the 2020 contributors decided to start over from the AT&T source code, backporting the bug fixes from ksh2020 onto the last-known-stable 93u, and building up from there. Their approach is to tread carefully and not do anything drastic. That effort has given us the ksh93u+X/1.x.y versions, most recently ksh93u+m/1.0.8 at the end of last year; 1.1.0 is expected soon. The GNU folks haven't been idle, though. The latest official bash release is 5.2, from 2022, but the patchlevel is up to 5.2.26, and there have been commits as recently as this week on the devel branch. There are still at least bugfixes going into ash and dash (and busybox, whose sh is based on ash), too. So yeah, Zsh is far from the only Bourne-family shell still seeing active development. -- Mark J. Reed <markjreed@gmail.com> [-- Attachment #2: Type: text/html, Size: 3067 bytes --]
On 2024-03-10 15:48, Bart Schaefer wrote: > On Sun, Mar 10, 2024 at 3:16 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> In a sentence or two, what is a namespace and why do we want it? > Quoting the updated FAQ file: > > 2.9: What is a `namespace' anyway? Sorta like a first name and a last name for a variable? Even I have often run into name crowding. Just recently there was that grief about an unrealized existing integer making mischief. So 'family names' could sure be a good thing. > > As of this writing, namespaces in zsh are little more than syntactic > sugar for grouping related parameters.
On 2024-03-10 15:45, Lawrence Velázquez wrote: > On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote: >> BTW interesting >> to learn that ksh is still in active development, I thought it was on >> ice, like bash. > Neither is "on ice". Both are quite active. Not that I'm in the loop, but I recall some time back, there was an exploit in bash and the talk was that there was no one available to fix it. Then I heard that bash development was down to one guy, namely Chet. Mind ... looking at your link, it seems he's quite active, so thereyago. Thanks. It's healthy. I know zsh has taken huge inspiration from ksh, so having those dudes 'competing' is good for everybody. > > https://github.com/ksh93/ksh/commits/dev/ > https://git.savannah.gnu.org/cgit/bash.git/log/?h=devel >
On Sun, Mar 10, 2024 at 3:16 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> In a sentence or two, what is a namespace and why do we want it?
Quoting the updated FAQ file:
2.9: What is a `namespace' anyway?
As of this writing, namespaces in zsh are little more than syntactic
sugar for grouping related parameters. For example, as of the update
to PCRE2, the parameters ${.pcre.match} and ${.pcre.subject} are used
for regular expression substring capture. The `.pcre.' part is
the namespace, and when you refer to a parameter that has one, you
*must* use the `${...}' braces around the name. Assignments
are not special, they have the form `.nspace.var=value' as usual.
Parameters using a namespace have the additional property that, like
file names beginning with a dot for globbing, they're hidden from
`typeset' output unless explicitly asked for.
On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote: > BTW interesting > to learn that ksh is still in active development, I thought it was on > ice, like bash. Neither is "on ice". Both are quite active. https://github.com/ksh93/ksh/commits/dev/ https://git.savannah.gnu.org/cgit/bash.git/log/?h=devel -- vq
[-- Attachment #1: Type: text/plain, Size: 702 bytes --] On 2024-03-10 13:08, Bart Schaefer wrote: > Given all this uncertainty and that we're already more than 2 years > past the 5.9 release, I'd rather get the tractable parts out there > sooner. I thought I'd be able to pick it up as the thread progressed, but I still have no idea what a namespace even is. It sure sounds complicated. I keep seeing structures because of the dots but I know that's not the case. In a sentence or two, what is a namespace and why do we want it? But I do remember vaguely that I once had a question where the future solution was going to be just that. BTW interesting to learn that ksh is still in active development, I thought it was on ice, like bash. [-- Attachment #2: Type: text/html, Size: 1353 bytes --]
On Sun, Mar 10, 2024 at 5:14 AM Stephane Chazelas <stephane@chazelas.org> wrote: > > 2024-03-09 14:58:10 -0800, Bart Schaefer: > [...] > > > except with things like: > > > > > > typeset -p ${(kM)parameters:#.*} > > > > Also "typeset -pm pattern" > > Thanks, that makes it significantly easier to list variables in > a namespace. I note in passing that "typeset -pm" does unexpected things if the GLOBALEXPORT option is NOT set ... I'll start another -workers thread when I have a better idea what's going on. > Would it be correct to say that the main goal for introducing > namespaces then would be to tidy-up the output of typeset -p/set > for all the subsystems of zsh written in zsh (completion, > zle...) and third party plugins? No, actually, my main goal for introducing namespaces was to be able to write the zsh/ksh93 module, and because lack of parameter names containing a dot has popped up several times (at widely scattered intervals) over the past multiple years. "Invisible" parameters was an unexpected benefit, I didn't even know ksh did that until I was mostly done with the rest. It would be nice to make function names starting with a dot "invisible" as well, but that needs wider discussion. > Wouldn't having the .space.var variables and namespace {...} in > two separate releases be counter-productive [for] plugin authors I'm a little more concerned with internal uses like zsh/hlgroup than with shell-code plugins. After all if you've once changed shell code to use .myplugin.myglobal there's no requirement to rewrite it with "namespace". And you can do something along the lines of: typeset -g .myplugin.myglobal .myplugin.otherglobal typeset -nu mygobal=.myplugin.myglobal otherglobal=.myplugin.otherglobal myglobal=whatever otherglobal=something and then replace those two typesets with "namespace myglobal { ... }" later. Implementing the "namespace" keyword means a bunch of fairly deep changes, including adding more wordcode elements as the output of new parsing routine besides figuring out the logic for inserting the current namespace (at both definition and expansion) and trying again without it (at expansion). I'm not (yet at least) familiar enough with the wordcode implementation to attempt the first part, and I'd rather have any kinks worked out of the underlying syntactic implementation before trying the rest. > Like if we allow ${.space} and ${.space.1} now but we find that > it prevents adding namespace {...} in the future, it will be > harder then to say "oh you can't do that anymore". There shouldn't be any clash with ${.space} because anything declared with the "namespace" keyword will get dots both before and after. If you attempt either of namespace newspace { .space=value } or namespace newspace { .otherspace.place=value } -- I believe (given the ban on nested namespaces) that both of those would simply skip prefixing with ".newspace." during assignment/reference. The potential clash with ${.space.1} is in practice I think also a non-issue, because ksh doesn't allow a direct assignment "1=one" anyway, so there's no incompatibility in declaring positional parameters exempt from auto-prefixing the same way that ${.space} is exempt. If you want ${.space.1} you have to always write that out. There are a bunch of questions to be resolved about how namespaces actually work. Ksh doc says "Commands and functions ... that modify variables or create new ones, create a new variable" -- does "modify" there mean that if I do -- namespace foo { PATH="/usr/local/bin:${PATH}"; } -- that I now have a (useless, as it doesn't affect path search?) new global variable ${.foo.PATH}? Alternately, does that mean that we now have to alter the environment PATH by copy of ${.foo.PATH} and restore again, on every entry/exit of any subsequent "namespace foo" block? What about locals? Do they get auto-prefixed with the namespace too? What about: inner() { local foo; bar=$1; ... } namespace outer { inner whatever; ... } Is "inner" now implicitly using ${outer.foo} during that call? Did it create global ${.outer.bar} rather than (as the writer of "inner" may have expected) creating an actual global ${bar}? How could the writer of "inner" protect the function from this effect? E.g., would/should using "typeset -g bar=$1" be different? Given all this uncertainty and that we're already more than 2 years past the 5.9 release, I'd rather get the tractable parts out there sooner.
2024-03-09 14:58:10 -0800, Bart Schaefer: [...] > > (and not having them starting with . > > is discouraged, presumably because that would conflict with > > ksh93's compound variables which zsh might want to support in > > the future?) > > Something like that. Ksh has a couple of special meanings of > ${var.func} in addition to compound variables. It's all rather messy > if you ask me, but we might pick and choose. Thanks Bart for the detailed feedback! Yes, all of the namespace, compounds, types, disciplines, nested assoc/array in ksh93 give an "experimental" vibe and of being unfinished and/or not fully thought through. A lot of it is also not hugely useful in a shell, and is not documented much and I don't expect many people have used even half of it which likely also explains why it's still quite bogus. I've just raised https://github.com/ksh93/ksh/issues/727 this morning about "echo" not working in namespaces making me thinking there can't be many people using those namespaces there (even if we take into account that "print" is preferred over "echo" in ksh) See also https://github.com/ksh93/ksh/issues/325 and more generally https://github.com/ksh93/ksh/issues?q=is%3Aissue+is%3Aopen+namespace there. [...] > That's also correct, except that -h doesn't mean the same thing at > all, so it's not really a meaningful "even with". > > > except with things like: > > > > typeset -p ${(kM)parameters:#.*} > > Also "typeset -pm pattern" Thanks, that makes it significantly easier to list variables in a namespace. [...] > > Is there a chance that ksh93's namespace keyword be added in the > > future? > > Yes, adding the namespace keyword is planned, probably for a > next-after-next release when we have some more real-world usage of the > current code. [...] > > Would the fact that function names have been allowing . > > since forever or that .foo or .foo.1 are allowed not be a problem? > > There's a small chance of backward-compatibility issues if someone is > using function names beginning with a dot, yes. Names containing a > dot are only an issue if the part before the dot is the same as the > name of a parameter > > We'd have to make some decisions about .foo.1 and similar with respect > to assignments -- it's not a large problem for expansions given that > namespace foo { echo $1; } > "fails upward" to the positional parameter $1 if ${.foo.1} does not exist. Would it be correct to say that the main goal for introducing namespaces then would be to tidy-up the output of typeset -p/set for all the subsystems of zsh written in zsh (completion, zle...) and third party plugins? Wouldn't having the .space.var variables and namespace {...} in two separate releases be counter-productive as plugin authors would first change their code from: myplugin() { myplugin_myglobal=whatever ... } To: myplugin() { .myplugin.myglobal=whatever ... } in 6.0 (say) as an improvement to limit the typeset output pollution. Only to change it again to: myplugin() namespace myplugin { myglobal=whatever ... } (or however namespace is going to be meant to be used then) In 7.0 (and possibly have to maintain 3 versions for zsh 5, 6, 7). If it's going to be done in a staged way, it seems it would be safer to start strict and relax later rather than the other way round to limit the risk of breaking backward compatibility in the future. Like if we allow ${.space} and ${.space.1} now but we find that it prevents adding namespace {...} in the future, it will be harder then to say "oh you can't do that anymore". Deferring the introduction of the "namespace" keyword (which sounds to me like it's the key missing part for the feature to be really useful) sounds risky unless we already have a clear idea of how it's going to work as we might find that the whole design and possibly user API would need to be rethought (like the namespaces would need to be declared in advance like in ksh93). (having said that, I've not given it much thought myself so my apprehensions may very well be baseless). -- Stephane
On Sat, Mar 9, 2024 at 6:30 AM Stephane Chazelas <stephane@chazelas.org> wrote: > > (not sure which of zsh-users or zsh-workers is best suited for > this discussion, I'm picking zsh-users for now but please feel > free to move to zsh-workers in follow-ups). For -users who haven't been following the -workers list, namespaces are a new feature appearing in the next release (version number TBD). Reordered some excerpts below to group responses better ... > - "." can now be used in the name of a variable, though with > limitations: > * .foo, foo., a.b, .a.b, a.1, .a.1x are OK, but not > ..foo, .foo., .1.a, foo.., a.b.c, .a.b.c > * you can refer them as ${a.b}, but not $a.b (understandably) So far so good. > - the ones starting with . are hidden from the output of "set"/"typeset" Yes. > (and not having them starting with . > is discouraged, presumably because that would conflict with > ksh93's compound variables which zsh might want to support in > the future?) Something like that. Ksh has a couple of special meanings of ${var.func} in addition to compound variables. It's all rather messy if you ask me, but we might pick and choose. > and there's no way to unhide them even with typeset -h That's also correct, except that -h doesn't mean the same thing at all, so it's not really a meaningful "even with". > except with things like: > > typeset -p ${(kM)parameters:#.*} Also "typeset -pm pattern" > It's always been possible to use . (or any character or > non-character, even the empty string) in function names, so > functions are not covered in the new feature. Also correct. > In particular, as noted in the doc, there's no support for > ksh93's: > > $ namespace foo { a=1 b=2 c=3; }; echo "${.foo.a} ${.foo.b} ${.foo.c}" > 1 2 3 > > Is there a chance that ksh93's namespace keyword be added in the > future? Yes, adding the namespace keyword is planned, probably for a next-after-next release when we have some more real-world usage of the current code. > So why would I use a ${.mynamespace.myvar} over > $_mynamespace_myvar, $ːmynamespaceːmyvar or $𐅂mynamespace𐅂myvar [...] > for my variables which I would want namespaced? > > I could also hide my _mynamespace_myvar variable with typeset > -h if I wanted to. The -h option of typeset does not hide the name, it hides the "specialness" of a parameter. If you apply it at the top level (which most autoloaded specials do), then in order to make a local with the same properties you must do e.g. typeset +h parameters to get a local that behaves like the global autoloaded $parameters association. If there's a global special like $status that does not use -h, then typeset -h status gives you a local that doesn't mirror the global. The -H option hides the value, but does not hide the name. So only using a namespace hides the whole thing. > AFAICT, that doesn't give me more guarantee of avoiding clashes, > and that means I have to use those braces. Given dynamic scoping, the only thing that really comes close to a guarantee of avoiding clashes is zsh/param/private, so that is true. > Would the fact that function names have been allowing . > since forever or that .foo or .foo.1 are allowed not be a problem? There's a small chance of backward-compatibility issues if someone is using function names beginning with a dot, yes. Names containing a dot are only an issue if the part before the dot is the same as the name of a parameter We'd have to make some decisions about .foo.1 and similar with respect to assignments -- it's not a large problem for expansions given that namespace foo { echo $1; } "fails upward" to the positional parameter $1 if ${.foo.1} does not exist. > How about nested namespaces? They don't work / aren't allowed. Each "namespace" keyword starts a new global namespace even if used inside another namespace declaration. > Is using ${.foo.bar} going to be recommended going forward for > namespacing variables in user-contributed code shipped with zsh? Probably only for user-contributed code that needs to maintain global state for re-entrancy, but I wouldn't expect it to be more than a recommendation. OTOH for example Oliver is already doing that. > Is the intention to reserve those for code included with zsh to > users can be sure not to clash with the zsh ones if they don't > use them? It's the intention to reserve some namespaces, the way ksh reserves the ".sh" namespace, yes. So far there's only been minimal discussion of which names would be included. Possibilities are things like ".zsh", ".zle", ".compsys". The mkshadow (_shadow) utility has already co-opted ".shadow", and Oliver's "hlgroup" module is using ".zle".
(not sure which of zsh-users or zsh-workers is best suited for this discussion, I'm picking zsh-users for now but please feel free to move to zsh-workers in follow-ups). I didn't read the initial discussions around the introduction of namespaces in the current development version of zsh, but from what I can tell it means: - "." can now be used in the name of a variable, though with limitations: * .foo, foo., a.b, .a.b, a.1, .a.1x are OK, but not ..foo, .foo., .1.a, foo.., a.b.c, .a.b.c * you can refer them as ${a.b}, but not $a.b (understandably) - the ones starting with . (and not having them starting with . is discouraged, presumably because that would conflict with ksh93's compound variables which zsh might want to support in the future?) are hidden from the output of "set"/"typeset" and there's no way to unhide them even with typeset -h, except with things like: typeset -p ${(kM)parameters:#.*} It's always been possible to use . (or any character or non-character, even the empty string) in function names, so functions are not covered in the new feature. And unless I'm missing something, that's it. In particular, as noted in the doc, there's no support for ksh93's: $ namespace foo { a=1 b=2 c=3; }; echo "${.foo.a} ${.foo.b} ${.foo.c}" 1 2 3 So why would I use a ${.mynamespace.myvar} over $_mynamespace_myvar, $ːmynamespaceːmyvar or $𐅂mynamespace𐅂myvar (which do work on GNU systems at least as ː, 𐅂 as well as hundreds of other characters which look appropriately shaped for the purpose are classified as alpha (in locales whose charmap have them) there) for my variables which I would want namespaced? AFAICT, that doesn't give me more guarantee of avoiding clashes, and that means I have to use those braces. I could also hide my _mynamespace_myvar variable with typeset -h if I wanted to. Is there a chance that ksh93's namespace keyword be added in the future? Would the fact that function names have been allowing . since forever or that .foo or .foo.1 are allowed not be a problem? How about nested namespaces? Is using ${.foo.bar} going to be recommended going forward for namespacing variables in user-contributed code shipped with zsh? Is the intention to reserve those for code included with zsh to users can be sure not to clash with the zsh ones if they don't use them? Thanks Stephane
On Wed, Mar 6, 2024 at 1:57 PM Felipe Contreras <felipe.contreras@gmail.com> wrote: > > But what if someone wants to do the opposite? Use the zsh $0 even if > POSIX_ARGZERO is on? Of course the zsh $0 depends on the setting of FUNCTION_ARGZERO, but I know what you mean. > So far I've found that ${(%):-%N} is the best option, but I wonder if > there is a better one. $funcstack[1] would be the other option, unless for some odd reason the zsh/parameter module is not available. An advantage of $funcstack is that you can use ${${(@)funcstack:#'(anon)'}[1]} to get the name of the nearest non-anonymous function.
Hi, In order to write code that always uses the POSIX $0 regardless of the POSIX_ARGZERO option one can simply use ZSH_ARGZERO. But what if someone wants to do the opposite? Use the zsh $0 even if POSIX_ARGZERO is on? So far I've found that ${(%):-%N} is the best option, but I wonder if there is a better one. Either way it would be nice if there was a variable for that, say ZSH_0. This also might simplify the zsh plugin standard: https://wiki.zshell.dev/community/zsh_plugin_standard Cheers. -- Felipe Contreras
On Tue, Mar 5, 2024 at 4:28 AM sergio <sergio@outerface.net> wrote:
>
> ```
> #!/bin/zsh -e
> (( test = 0 ))
> ```
>
> 2. How to do arithmetic evaluation properly in zsh sripts? postpend with
> || true
When I end up in a situation like this, I use this pattern:
(( expr, 1 ))
Although the more general patterns works here, too:
list || true
I never use `set -e`, a.k.a. `setopt err_exit`, on its own, because
its behavior within functions is counter to what I need. In fact, I
don't think I ever wanted this option to behave the way it does in
functions. Let me show what I mean.
set -e
false
launch-missiles
If you put these lines at the top level of a zsh script,
launch-missiles won't execute because the previous command (false)
fails. But if you put the same code in a function, this guarantee is
lost.
% zsh -fc '
foo() {
set -e
false
print launch missiles
}
if ! foo; then :; fi
foo || false
foo && true
print the end'
The output:
launch missiles
launch missiles
launch missiles
the end
This issue can be solved by turning on err_return together with err_exit.
foo() {
setopt local_options err_return err_exit
false
launch-missiles
}
Now, we can either handle errors from the function gracefully:
if ! foo; then
do-something
fi
Or we can let it take the default error handling action, which is to
exit the script:
foo
In no case will the missiles launch.
Roman.
2024-03-04 20:23:51 -0800, Bart Schaefer: > On Mon, Mar 4, 2024 at 7:28 PM sergio <sergio@outerface.net> wrote: > > > > I believe -e is best practices for scripts > > Leaving opinions aside ... [...] https://mywiki.wooledge.org/BashFAQ/105 https://fvue.nl/wiki/Bash:_Error_handling https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail (for bash but most of it applies to other Bourne-like shells) are good references about the problems with errexit. One might add that using option names rather than letters is preferable as more legible (and more portable like for -f vs noglob where -f means something different in zsh and other shells), and that it's preferable to set them via "set" rather than via the shebang as the shebang is not honours when the script is invoked as zsh path/to/the/script or source path/to/the/script or zsh < path/to/the/script and on most systems, shebang can have only one extra argument and using options there prevents adding the option delimiter. So: #! /bin/zsh - set -o errexit -o nounset -o pipefail (or setopt if you prefer but I like set -o better as that's supported by many other shells) Rather than #! /bin/zsh -euopipefail Of those 3 options, nounset is the least controversial. errexit is a minefield and pipefail can be problematic when using pipe consumers that exit (successfully) without reading their whole input (where a death by SIGPIPE of the feeder is not necessarily a failure. Best to do proper error handling. I usually define a die function for that: die() { print -ru2 -C1 -- "$@" exit 1 } cmd1 || die cmd2 || die "some error message" -- Stephane
On Mon, Mar 4, 2024, at 11:23 PM, Bart Schaefer wrote:
> On Mon, Mar 4, 2024 at 7:28 PM sergio <sergio@outerface.net> wrote:
>> 1. What is the reason for returning 1 when an arithmetic evaluation
>> succeeds but is zero?
>
> (( ... )) is intended to be useful in tests:
> if (( status == 1 )); then ...
Put another way, you can think of ((...)) as "translating" C's
notion of true/false into the shell's. C considers zero-valued
expressions to be false, so ((...)) "translates" them into an exit
status of 1, which the shell considers false/failing. Similarly,
C considers non-zero-valued expressions to be true, so for those
((...)) returns 0, which the shell considers true/successful.
--
vq