posix vs default mode nonsense
Was "'wait -n' with and without id arguments"
On Sun, Oct 20, 2024 at 10:30 PM Grisha Levit wrote:
>
>
> On Sun, Oct 20, 2024, 20:52 Zachary Santer wrote:
>>
>>
>> Item 8 is just odd and is on the verge of being a dealbreaker. Not to
>> go off on another tangent, but what on Earth?
>
>
> AFAICT it's the non-POSIX-mode Bash behavior that is unusual.
>
> While all shells will have treat single quotes as literal here:
>
> $ V=set
> $ echo "${V+'x'}"
> 'x'
>
> Pretty much every other shell (and bash in posix mode) will continue to do so
> for:
>
> $ echo "${V+'x}"
> 'x
>
> ...while bash will treat this as an unterminated command. Because in bash,
> this is a weird kind of quoting, where the quotes are preserved but any }
> character within them loses its special meaning:
>
> $ unset U
> $ (set +o posix; echo "${U+'}'y}")
>
> $ (set -o posix; echo "${U+'}'y}")
> 'y}
I misinterpreted Item 8, then.
POSIX file:
> 8. When parsing and expanding a ${...} expansion that appears within
> double quotes, single quotes are no longer special and cannot be
> used to quote a closing brace or other special character, unless
> the operator is one of those defined to perform pattern removal.
> In this case, they do not have to appear as matched pairs.
I took "defined to perform pattern removal" as specific to
${parameter#pattern} and ${parameter%pattern},so I thought quote
removal wouldn't be performed on 'pattern' and 'replacement' in
${parameter//pattern/replacement} in POSIX mode. I could've tested
that, but I didn't. Replacing 'pattern' with 'replacement' is also
removing 'pattern', isn't it?
I'll admit that it surprises me that regular quote removal isn't
performed on 'word' in stuff like ${parameter:+word}, but whatever.
Not going to argue with all shells.
On Sun, Oct 20, 2024 at 10:49 PM Lawrence Velázquez wrote:
>
> On Sun, Oct 20, 2024, at 8:51 PM, Zachary Santer wrote:
> > Item 8 is just odd and is on the verge of being a dealbreaker. Not to
> > go off on another tangent, but what on Earth?
> >
> > Item 3 is also a weird thing to do
>
> Neither of these is "odd" or "weird". They are consistent with
> other shells and specified by POSIX. (Debating the requirement
> would be even more tedious than the rest of this conversation,
> and this isn't the proper forum besides.)
"Tedious" is the word.
The nontrivial stuff I do is still being run by bash 4.2 at the
moment, and I'm not willing to give up procsubs. I will keep POSIX
mode in mind for when I'm playing with at least bash 5.1.
Re: 'wait -n' with and without id arguments
On Sun, Oct 20, 2024, 20:52 Zachary Santer wrote:
>
> Item 8 is just odd and is on the verge of being a dealbreaker. Not to
> go off on another tangent, but what on Earth?
>
AFAICT it's the non-POSIX-mode Bash behavior that is unusual.
While all shells will have treat single quotes as literal here:
$ V=set
$ echo "${V+'x'}"
'x'
Pretty much every other shell (and bash in posix mode) will continue to do
so for:
$ echo "${V+'x}"
'x
...while bash will treat this as an unterminated command. Because in bash,
this is a weird kind of quoting, where the quotes are preserved but any }
character within them loses its special meaning:
$ unset U
$ (set +o posix; echo "${U+'}'y}")
$ (set -o posix; echo "${U+'}'y}")
'y}
>
Re: 'wait -n' with and without id arguments
On Sun, Oct 20, 2024, at 8:51 PM, Zachary Santer wrote: > Item 8 is just odd and is on the verge of being a dealbreaker. Not to > go off on another tangent, but what on Earth? > > Item 3 is also a weird thing to do Neither of these is "odd" or "weird". They are consistent with other shells and specified by POSIX. (Debating the requirement would be even more tedious than the rest of this conversation, and this isn't the proper forum besides.) -- vq
Re: 'wait -n' with and without id arguments
On Thu, Oct 17, 2024 at 6:14 PM Chet Ramey wrote: > > On 9/29/24 12:55 PM, Zachary Santer wrote: > > On Wed, Sep 25, 2024 at 11:06 AM Chet Ramey wrote: > >> > > I might argue that calling 'jobs' within a script being executed > > normally shouldn't make background jobs that have already terminated > > unavailable to 'wait -n' either. > > Make up your mind. Is non-interactive shell behavior good, as you've said > before, and again at the end of this message, or is it not? It's good if you don't call 'jobs'. All I was saying is that my most probable use case for 'wait -n' is fine. I don't see myself calling 'jobs' from within a script. > > I might be missing something, but bash sure seems to be doing this in > > a number of different calls to wait-n-failure::main, on the current > > devel branch commit. Are the jobs not being removed from the jobs > > table until some later point? > > What? When jobs are added to the jobs list, they use the index after > the largest index with a job. If you have four jobs, 1-4, and job 3 > terminates, the next job created gets index 5. If job 4 terminates > instead, the next job created gets index 4. Is this not what you're > seeing? Yeah it is. So I was missing something. > >> So you are saying that prompt notifications and `jobs' have the same > >> effect. POSIX implies but does not require this, and there is differing > >> behavior among current implementatations. > > > > I've got no opinion on this point, actually. > > You just described it. Are you saying you don't mind either behavior? Yeah, I thought I was saying this bit of existing behavior would remain unchanged. I wasn't correctly describing the existing behavior, though, so nevermind. > >> This is posix mode. > > > > How does the user know that? > > How does a user know anything? What's the difference between "documented > in the man page" (presumably in JOB CONTROL or the `wait' description?) > and "documented as part of posix mode"? That's fair. > > And now I know that, but I don't even use 'wait -n' for anything. > > Then we're just having an academic conversation. Yeah, I dragged myself into this from the procsub wait discussion. Nobody else really spoke up. Hopefully, this has been useful. > > The point here was to try to get the behavior of 'wait -n' to be as > > consistent as possible, between different execution environments: the > > interactive shell, a script being sourced, and a script being executed > > normally; along with different set and shopt options. If you won't > > consider modifying the behavior of 'wait -n' without id arguments in > > default mode, then that's frustrating. > > You might want to try posix mode for a while and see what happens. There > are very few people who do that; I'd be interested in feedback. I can work around function names needing to be valid shell 'name's by simply waiting to do 'set -o posix' after all the functions are defined, but items 8 and 58 in the POSIX file are a couple of head-scratchers. On item 58: My external 'kill' is from Cygwin Utilities, naturally, but its -l does what bash's 'kill -l' does in POSIX mode and its -L does something similar to what bash's 'kill -l' does in default mode. Could POSIX-mode bash 'kill -L' still give the table, instead of doing the same thing as 'kill -l'? Item 8 is just odd and is on the verge of being a dealbreaker. Not to go off on another tangent, but what on Earth? Item 3 is also a weird thing to do, but you can turn alias expansion right back off in a script with 'shopt -u expand_aliases', so whatever. I notice that I don't have to do set -o posix wait set +o posix if I want to keep POSIX mode restricted to just the behavior of 'wait'. This works POSIXLY_CORRECT='y' wait so that's cool.
Re: 'wait -n' with and without id arguments
On 10/17/24 11:27 PM, Robert Elz wrote: When an interactive shell notifies the user before printing a prompt that a job is now Done - that job should be removed (from everywhere). It all boils down to what POSIX says about this, and what shells do. I think I did a survey of existing implementations in one of my previous replies, but I can't find it right now. I think all the ash-based shells, at least, make the job unavailable to `wait'. That is, basically, this: $ sleep 2 & jobs -p 66433 $ [1] + Done sleep 2 $ wait 66433 $ echo $? 127 (I waited a few seconds at the prompt, then hit return to generate the notification.) Other shells (bash, ksh93, mksh at least) make the pid available to `wait', at least once. I don't think we need to talk about this particular aspect of this any more. It's pretty clear there is a difference, and it's pretty clear people aren't going to change their minds. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: ${param@a} should bypass unbound variable check or be processed ahead of it.
On Sun, Oct 13, 2024, 14:58 Chet Ramey wrote:
> On 10/1/24 3:54 AM, konsolebox wrote:
> > # declare -A x
> > # echo ${x@a}
> > A
> > # set -u
> > # echo ${x@a}
> > bash: x: unbound variable
> >
> > Obvious workaround would be to disable `set -u` temporarily or assign
> > a temporary array value but that shouldn't need to be done.
>
> I'll consider it, but I'm not eager to carve out more exceptions for
> `set -u'.
>
Using ${x[@]@a} at first seems to be a work around:
$ (set -u; declare -A x; echo :${x[@]@a})
:A
But, as a separate issue, the @a transformation doesn't expand to anything
here (regardless of set -u):
$ (set -u; declare -A x=(); echo :${x[@]@a})
:
Maybe just adjusting the latter to also expand to the variable's attributes
would suffice.
>
