[Toybox] Would someone please explain what bash is doing here?

[Rob Landley]

On 5/28/20 4:08 PM, Chet Ramey wrote:
> On 5/27/20 6:17 PM, Rob Landley wrote:
> 
>>> But what are you going to do with a shell script when you suspend a
>>> pipeline in it? Keep on going with reading commands in the script? That's
>>> rarely going to be what the user wants. Most people expect the shell
>>> running the script to get suspended when you hit it with SIGTSTP.
>>
>> To be honest I'm leaning towards doing that and seeing who complains.
> 
> That is, unfortunately, not conformant.

Meaning I should document the deviation.

> If you set -m in a script, and
> run an external command, that command gets put in its own process group,
> and the terminal pgid is set to that process group, and that process
> group gets the SIGTSTP. If you want, you can notice the stopped job and
> resend SIGTSTP to yourself, but nobody except ksh93 does that. It's just
> a bad idea for users to try it.

That would be the "seeing who complains" part. :)

>>>> Is it because "?" is a wildcard, or because %? is a special prefix? 
>>>
>>> It's because `%' introduces the job spec, and `?' is the notation to refer
>>> to the substring of the job name, so the latter.
>>
>> Special prefix, yay.
> 
> If you support job control IDs, you're already supporting `%' as a special
> prefix. What's the difference?

I meant we've resolved that % is one prefix and %? is another prefix with
similar but distinct meaning. I.E. %? is, itself, a special prefix.

>>>> That
>>>> question mark isn't going to act as a wildcard and match a filesystem character
>>>> during normal wildcard processing, right?
>>>
>>> It could. These are invariably used as arguments to builtins, and undergo
>>> all the usual word expansions.
>>
>> So it's %\?ce
> 
> Depending on your level of paranoia.
> 
>>
>>>> If there's a %xce in the current
>>>> directory, it won't resolve to that? 
>>>
>>> It could. Such filenames are extremely rare. I've never actually had a bug
>>> report complaining about this.
>>
>> I BREAK EVERYTHING. Trust me, if I started using this feature, I would hit this.
> 
> You often name files beginning with percents?

More likely I'd typo "echo %lan > file" as "echo > %lan file" and not notice the
debris until "kill %?an" misfired.

>>>> If a $variable expands to %?ce does it
>>>> still count? 
>>>
>>> Yes, when it's used as an argument to a shell builtin.
>>
>> Alright, it's not parsed by the shell it's just consumed by commands so I should
>> document %\? as the prefix.
> 
> Just wait until you get users saying "I typed '%\\?sle' and nothing
> happened."

I use to have a button "Nothing is foolproof because fools are so ingenious."

(Admittedly I bought every button in http://nancybuttons.com/ old paper
catalogue because there was a bulk discount that got bigger the more you ordered
and when I met her at a convention I asked "how much for one of each" and wrote
a check. And then gave them all away over the years...)

>>>> Asynchronous! Not really designed to be scripted!
>>>
>>> Asynchronous jobs are easy. Once you have something in the background, and
>>> you know its job number or how to refer to it using %name, you can run bg
>>> and fg to your heart's content, use `kill' to kill it, and use `wait' to
>>> clean up.
>>
>> A test suite that assumes all the tests _succeed_ is easy to write.
> 
> If you mean "succeed or fail in predictable ways when given incorrect
> input," sure.
> 
> If you're worried about leaving stray background jobs around, end your
> test script with `wait'.

Which will hang if the background job is hung.

> But you can always save a background job's pid
> by saving $!, so you can always have a handle to the background jobs you
> create.

In theory jobs -p should do it, in practice I've hit background-from-subshell
cases where it wasn't in the list...

> Bash-5.1 will change the way it does $SECONDS to use gettimeofday(), btw.

Meanwhile, I'm fielding:

https://github.com/landley/toybox/pull/210

Rob