[-- Attachment #1: Type: text/plain, Size: 416 bytes --] Hello, given this test code: test(){ setopt -L extended_glob local glob=${(q)1}'.[0-9]##' touch $1.1 $1.2 echo -E - $~glob } > test tmp tmp.1 tmp.2 > test {tmp} test:4: no matches found: \{tmp\}.[0-9]## test '<tmp>' <tmp>.1 <tmp>.2 It seems the quoting of the {} makes the expansion fail (on zsh 5.1.1) is there any way I can quote the file name according to the glob expansion rules? thanks Pier Paolo Grassi [-- Attachment #2: Type: text/html, Size: 881 bytes --]
On 3/2/21, Pier Paolo Grassi <pierpaolog@gmail.com> wrote:
> Hello, given this test code:
>
> test(){
> setopt -L extended_glob
> local glob=${(q)1}'.[0-9]##'
> touch $1.1 $1.2
> echo -E - $~glob
> }
>
>> test tmp
> tmp.1 tmp.2
>
>> test {tmp}
> test:4: no matches found: \{tmp\}.[0-9]##
>
> test '<tmp>'
> <tmp>.1 <tmp>.2
>
> It seems the quoting of the {} makes the expansion fail (on zsh 5.1.1)
> is there any way I can quote the file name according to the glob expansion
> rules?
> thanks
I think you want (b), not (q).
--
Mikael Magnusson
[-- Attachment #1: Type: text/plain, Size: 751 bytes --] it seems I do, missed that. thanks! Pier Paolo Grassi Il giorno mar 2 mar 2021 alle ore 12:58 Mikael Magnusson <mikachu@gmail.com> ha scritto: > On 3/2/21, Pier Paolo Grassi <pierpaolog@gmail.com> wrote: > > Hello, given this test code: > > > > test(){ > > setopt -L extended_glob > > local glob=${(q)1}'.[0-9]##' > > touch $1.1 $1.2 > > echo -E - $~glob > > } > > > >> test tmp > > tmp.1 tmp.2 > > > >> test {tmp} > > test:4: no matches found: \{tmp\}.[0-9]## > > > > test '<tmp>' > > <tmp>.1 <tmp>.2 > > > > It seems the quoting of the {} makes the expansion fail (on zsh 5.1.1) > > is there any way I can quote the file name according to the glob > expansion > > rules? > > thanks > > I think you want (b), not (q). > > -- > Mikael Magnusson > [-- Attachment #2: Type: text/html, Size: 1486 bytes --]
Hi Confused as to whether disown behaves differently between zsh & bash in zsh >disown -a disown: job not found: -a bash david@mint-HP-600B $ sleep 200 ^Z [1]+ Stopped sleep 200 david@mint-HP-600B $ disown -a bash: warning: deleting stopped job 1 with process group 47533 I desire to use disown -a in zsh but it's not working and not documented Best regards David Rayner
zzapper wrote on Tue, 02 Mar 2021 23:31 +00:00: > Confused as to whether disown behaves differently between zsh & bash > Presumably you mean "why" rather than "whether". About that, see https://github.com/zsh-users/zsh/blob/5ede2c55f144593c16498c3131a76e188114a9c6/Etc/FAQ.yo#L2056-L2102, the first and penultimate paragraphs. More below. > in zsh > > >disown -a > disown: job not found: -a > > > bash > > david@mint-HP-600B $ sleep 200 > ^Z > [1]+ Stopped sleep 200 > david@mint-HP-600B $ disown -a > bash: warning: deleting stopped job 1 with process group 47533 > > > I desire to use disown -a in zsh but it's not working and not documented zsh is not a bug-for-bug reimplementation of bash. As to a workaround, you don't specify what -a should do, but perhaps this: disown %${(k)^jobstates[(R)suspended:*]} The references for that are spread across several parts of the manual (zshexpn(1) for ${^foo}, zshmodules(1) for $jobstates, etc), but in a nutshell, it disowns the jobs that are listed as "suspended" in $jobstates. You can even syntactic sugar that: function disown() { if [[ $# -eq 1 && #1 == -a ]] ; then set -- %${(k)^jobstates[(R)suspended:*]} ; fi builtin disown "$@" }
Also, don't start a new thread by replying to an existing one and changing the subject. Emails carry threading information and changing the subject doesn't reset it.
2021-03-03 00:05:38 +0000, Daniel Shahaf:
[...]
> zsh is not a bug-for-bug reimplementation of bash.
>
> As to a workaround, you don't specify what -a should do, but perhaps this:
>
> disown %${(k)^jobstates[(R)suspended:*]}
[...]
For the record, AFAICT "disown" is a zsh invention. Already
there in 1.0 in 1990.
ksh added it in ksh93 (a rewrite) released in late 1993.
bash in 2.0 released in late 1996 (so the path there is likely
to be zsh -> ksh93 -> bash, as ksh93 is generally the shell bash
took inspiration from). With also a -h option.
yash in 2.0a2 in 2008.
In fish, disown is a wrapper function around its disown builtin
added in 2.6b1 in 2017.
pdksh-based, ash-based, csh-based ones don't seem to have a
disown builtin.
Of the ones that have a disown builtin above, only bash and yash
support -a (also --all in yash).
bash added that option (as well as -r) in 2.02 (1998).
To this day, it seems the -h and -r options are specific to
bash. ksh93's disown supports the usual
--help/--usage/--nroff/--man/--author... like all its builtins.
See also the related hup and nohup builtins of tcsh (from 1993).
--
Stephane
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --] out of curiosity, how have you assembled this informations? from memory or digging in the source trees? Il giorno mer 3 mar 2021 alle 08:16 Stephane Chazelas <stephane@chazelas.org> ha scritto: > 2021-03-03 00:05:38 +0000, Daniel Shahaf: > [...] > > zsh is not a bug-for-bug reimplementation of bash. > > > > As to a workaround, you don't specify what -a should do, but perhaps > this: > > > > disown %${(k)^jobstates[(R)suspended:*]} > [...] > > For the record, AFAICT "disown" is a zsh invention. Already > there in 1.0 in 1990. > > ksh added it in ksh93 (a rewrite) released in late 1993. > > bash in 2.0 released in late 1996 (so the path there is likely > to be zsh -> ksh93 -> bash, as ksh93 is generally the shell bash > took inspiration from). With also a -h option. > > yash in 2.0a2 in 2008. > > In fish, disown is a wrapper function around its disown builtin > added in 2.6b1 in 2017. > > pdksh-based, ash-based, csh-based ones don't seem to have a > disown builtin. > > Of the ones that have a disown builtin above, only bash and yash > support -a (also --all in yash). > > bash added that option (as well as -r) in 2.02 (1998). > > To this day, it seems the -h and -r options are specific to > bash. ksh93's disown supports the usual > --help/--usage/--nroff/--man/--author... like all its builtins. > > See also the related hup and nohup builtins of tcsh (from 1993). > > -- > Stephane > > -- Pier Paolo Grassi [-- Attachment #2: Type: text/html, Size: 1956 bytes --]
On 03/03/2021 07:15, Stephane Chazelas wrote:
> 2021-03-03 00:05:38 +0000, Daniel Shahaf:
> [...]
>> zsh is not a bug-for-bug reimplementation of bash.
>>
>> As to a workaround, you don't specify what -a should do, but perhaps this:
>>
>>
>> pdksh-based, ash-based, csh-based ones don't seem to have a
>> disown builtin.
>>
>> Of the ones that have a disown builtin above, only bash and yash
>> support -a (also --all in yash).
>>
>> bash added that option (as well as -r) in 2.02 (1998).
>>
>>
thanks for this interesting and comprehensive answer.
Now something I've never quite got my head round is or isn't the
underlying binary in bash & zsh for say disown or grep actually the
same on any particular system?
Best regards
zzapper
> On 03 March 2021 at 09:36 zzapper <zsh@rayninfo.co.uk> wrote:
> Now something I've never quite got my head round is or isn't the
> underlying binary in bash & zsh for say disown or grep actually the
> same on any particular system?
This is one of the family of the commands that do job control, like
fg, bg, jobs. Jobs are maintained by the shell itself. That's
necessary so that, for example, if you run "fg" on the job the
shell can tweak it to start running and then sit back and wait for
it to exit. An external programme wouldn't be able to do all that.
So, when you get to the point where you're not actually interested
in the job any more, you need to tell the shell to forget it,
and that's what disown is doing.
pws
On 03/03/2021 00:12, Daniel Shahaf wrote:
> Also, don't start a new thread by replying to an existing one and
> changing the subject. Emails carry threading information and changing
> the subject doesn't reset it.
(sorry about that: when do you stop learning new things?)
and to clear up my own query
> which disown
disown: shell built-in command
2021-03-03 08:57:15 +0100, Pier Paolo Grassi:
> out of curiosity, how have you assembled this informations? from memory or
> digging in the source trees?
[...]
I do collect a number of old archives of various shell source
codes downloaded from here and there and look in there for this
kind of information. I enjoy this kind of archeological digging.
For recent versions, you can generally look in cvs/svn/git logs,
or use git blame/svn ann or git log --grep...
For older versions, most shells keep changelogs. zsh has some
Etc/ChangeLog*, bash has a NEWS and CWRU/changelog. zsh links
its changelog to the mailing list. So not only you can find the
change, but also the reasoning and discussions behind it. That's
quite unique and invaluable.
It's hard to obtain old ksh versions. All I have is ksh86 (from
some bsd source tree), svr4.2 ksh88d from archive.org, the
leaked solaris11's ksh88i, ksh93d from dtksh, ksh85's man page
and some of ksh93's since it's been made opensource. There's a
RELEASE file in there (and more for the libraries) but it's a
bit patchy.
BSD shells (based on ash originally published on usenet in 1989,
so easy to find, except for OpenBSD which switched to pdksh) are
easy as the sccs history is publicly available.
For tcsh, someone compiled all versions back to 6.06.1 in the
git repo. Some older versions can be found on usenet.
I started using zsh around the time bash 2.0 came out. But that
was 25 years ago. I can't say I remember much from then. Back
then, bash was already quite limited compared to zsh. It didn't
even have arrays.
--
Stephane
[-- Attachment #1: Type: text/plain, Size: 2189 bytes --] that's quite interesting, for me at least. If you have any good link to articles or books about the history of shell programs and the motivations behind various choices and want to share I would really appreciate it idk if this is interesting to the list also or I should message privately about topics not directly related to zsh, or if I should start a new thread, I would appreciate some direction on this Pier Paolo Grassi Il giorno mer 3 mar 2021 alle ore 11:23 Stephane Chazelas < stephane@chazelas.org> ha scritto: > 2021-03-03 08:57:15 +0100, Pier Paolo Grassi: > > out of curiosity, how have you assembled this informations? from memory > or > > digging in the source trees? > [...] > > I do collect a number of old archives of various shell source > codes downloaded from here and there and look in there for this > kind of information. I enjoy this kind of archeological digging. > > For recent versions, you can generally look in cvs/svn/git logs, > or use git blame/svn ann or git log --grep... > > For older versions, most shells keep changelogs. zsh has some > Etc/ChangeLog*, bash has a NEWS and CWRU/changelog. zsh links > its changelog to the mailing list. So not only you can find the > change, but also the reasoning and discussions behind it. That's > quite unique and invaluable. > > It's hard to obtain old ksh versions. All I have is ksh86 (from > some bsd source tree), svr4.2 ksh88d from archive.org, the > leaked solaris11's ksh88i, ksh93d from dtksh, ksh85's man page > and some of ksh93's since it's been made opensource. There's a > RELEASE file in there (and more for the libraries) but it's a > bit patchy. > > BSD shells (based on ash originally published on usenet in 1989, > so easy to find, except for OpenBSD which switched to pdksh) are > easy as the sccs history is publicly available. > > For tcsh, someone compiled all versions back to 6.06.1 in the > git repo. Some older versions can be found on usenet. > > I started using zsh around the time bash 2.0 came out. But that > was 25 years ago. I can't say I remember much from then. Back > then, bash was already quite limited compared to zsh. It didn't > even have arrays. > > -- > Stephane > [-- Attachment #2: Type: text/html, Size: 2936 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2418 bytes --] oh I see now that you already changed the topic Pier Paolo Grassi Il giorno mer 3 mar 2021 alle ore 15:00 Pier Paolo Grassi < pierpaolog@gmail.com> ha scritto: > that's quite interesting, for me at least. If you have any good link to > articles or books about the history of shell programs and the motivations > behind various choices and want to share I would really appreciate it > idk if this is interesting to the list also or I should message privately > about topics not directly related to zsh, or if I should start a new > thread, I would appreciate some direction on this > > Pier Paolo Grassi > > > Il giorno mer 3 mar 2021 alle ore 11:23 Stephane Chazelas < > stephane@chazelas.org> ha scritto: > >> 2021-03-03 08:57:15 +0100, Pier Paolo Grassi: >> > out of curiosity, how have you assembled this informations? from memory >> or >> > digging in the source trees? >> [...] >> >> I do collect a number of old archives of various shell source >> codes downloaded from here and there and look in there for this >> kind of information. I enjoy this kind of archeological digging. >> >> For recent versions, you can generally look in cvs/svn/git logs, >> or use git blame/svn ann or git log --grep... >> >> For older versions, most shells keep changelogs. zsh has some >> Etc/ChangeLog*, bash has a NEWS and CWRU/changelog. zsh links >> its changelog to the mailing list. So not only you can find the >> change, but also the reasoning and discussions behind it. That's >> quite unique and invaluable. >> >> It's hard to obtain old ksh versions. All I have is ksh86 (from >> some bsd source tree), svr4.2 ksh88d from archive.org, the >> leaked solaris11's ksh88i, ksh93d from dtksh, ksh85's man page >> and some of ksh93's since it's been made opensource. There's a >> RELEASE file in there (and more for the libraries) but it's a >> bit patchy. >> >> BSD shells (based on ash originally published on usenet in 1989, >> so easy to find, except for OpenBSD which switched to pdksh) are >> easy as the sccs history is publicly available. >> >> For tcsh, someone compiled all versions back to 6.06.1 in the >> git repo. Some older versions can be found on usenet. >> >> I started using zsh around the time bash 2.0 came out. But that >> was 25 years ago. I can't say I remember much from then. Back >> then, bash was already quite limited compared to zsh. It didn't >> even have arrays. >> >> -- >> Stephane >> > [-- Attachment #2: Type: text/html, Size: 3543 bytes --]
To add to pws's answer:
zzapper wrote on Wed, Mar 03, 2021 at 09:36:13 +0000:
> Now something I've never quite got my head round is or isn't the underlying
> binary in bash & zsh for say disown or grep actually the same on any
> particular system?
For grep, yes. /bin/grep is the same thing regardless of what its
parent process is. (That said, a process _could_ behave differently
depending on what its parent is, if it wanted to.)
disown, as mentioned by pws and elsethread, is a shell builtin. In zsh
it's implemented as part of /bin/zsh; in bash it's presumably
implemented as part of /bin/bash. Generally, bash and zsh's
implementations of builtins are different.