[Toybox] [PATCH] sh: pass "\" to the later app

[Chet Ramey]

On 7/8/23 7:41 AM, Rob Landley wrote:
> On 7/6/23 20:09, Chet Ramey wrote:

> ...
>>    Distinguishing : from true seems deeply silly
>>
>> true wasn't a special builtin in the Bourne shell.
> 
> It isn't because it wasn't. Historical reasons, no other pattern or logic.

Is there pattern or logic in the original 7th Edition Bourne shell special
builtins? POSIX certainly wasn't going to invent new special builtins. The
ones we have are bad enough.




> I note that "help times" does not actually explain that if you don't
> already know... 

The accumulated user (1) and system (2) times for the shell (line 1) and
its children (line 2). This maps nicely into getrusage (RUSAGE_SELF, ...)
and getrusage (RUSAGE_CHILDREN, ...). It seems straightforward.

> And it explains the waited for grandchildren but presumably not
> the ignore sigchld or reparent-to-init children.)

You get whatever getrusage gives you.

>>>>> I
>>>>> remember I did make "continue&" work, but don't remember why...)
>>>>
>>>> Why would that not work? It's just a no-op; no semantic meaning.
>>>
>>> Not _quite_ a NOP:
>>
>> I mean, it creates a child process which immediately exits, but it has
>> no effect on the shell other than to note that we created an asynchronous
>> child process (which sets $!) that exited. It certainly doesn't affect
>> flow control.
> 
> The & terminates the statement as usual but the command does not run in a child
> process.

Come on, of course it does. If you don't execute asynchronous commands in a
subshell, even builtins, you're going to have problems.


>  Especially with continue [n] being able to take an argument, that took
> a little special casing in my code.

How so?

> 
>>>     $ for i in one two three; do echo a=$i; continue& b=$i; done
>>>     a=one
>>>     [1] 30698
>>>     a=two
>>>     [2] 30699
>>>     a=three
>>>     [3] 30700
>>>     [1]   Done                    continue
>>>     [2]-  Done                    continue
>>>
>>> Notice the child processes and lack of b= lines.
>>
>> Why would you expect a b= line?
> 
> If it were actually a NOP because the continue ran in a subshell.

What does this mean? Or did you think there was an echo there?

>> Reference counting is ok. Bash just copies the parsed function body (x in
>> this case) and executes that, then frees it. That way you can let the
>> function get unset and not worry about it.
> 
> Each time you call the function? Including all the strings?

Yep. It means you can change the flags associated with the commands without
worrying about restoring them.


>> You have to parse it to find the end of the command substitution, bottom
>> line. You can't get it right otherwise.
> 
> I acknowledge that it's not right. I expect to hit something that breaks it deep
> in some package build, but I'm holding off that bout of re-engineering until
> then because I've got so much else to do and in hopes of coming up with a less
> hideous way to represent the result by then...

I held out for years.


> I'm aware they did it. It failed. They will not acknowledge that.

I suppose it depends on how you define success. They got a standard that
was approved. That wouldn't have happened without pax.


>>> The result of $(blah) and $BLAH are handled the same there? Quotes _inside_ the
>>> subshell are in their own context.
>>
>> Yes, that's the point I was trying to make.
>>
>>> Hmmm... Smells a bit like indexed arrays are just associative arrays with an
>>> integer key type, but I guess common usage leans towards a span-based
>>> representation?
>>
>> It depends on whether or not you want to support very large arrays. The
>> bash implementation has no trouble with
>>
>> a=( [0x1000000]=$'\371\200\200\200\200' [0x1000001]=$'\371\200\200\200\201'
>> [0x1000002]=$'\371\200\200\200\202' [0x1000003]=$'\371\200\200\200\203'
>> [0x1000004]=$'\371\200\200\200\204' )
>>
>> Which will eat huge amounts of memory if you use a C-type array. Bash uses
>> a doubly-linked list with some saved indices to make sequential access
>> very fast.
> 
> Depends on your definition of "large array". 5 entries large, or large address
> space large.

Mostly the latter. If your arrays aren't sparse in some way, you're just
going to allocate huge chunks of memory.


>>> Ok, now I'm even more confused. It's exporting inaccessable values? (I know that
>>> you can export a local, which goes away when the function returns...)
>>
>> Creating a local variable, which does not inherit the attributes from any
>> global variable, does not cause the environment to be recreated.

Behavior varies. Maybe bash's local variable unset code should preserve
the export attribute, since several other POSIX shells seem to magically
export the variable if it's given a value after being unset.





> Depends whether you're trying to get them to learn C at the same time?
> 
> Explaining that you _could_ say printf abc:$X or you can say printf abc:%s $X
> and there's multiple ways to do it but you're not expected to understand the
> difference between them until much later and as long as you never try to print
> anything with a % in it you're fine except yes the $X context expanding to %s
> can mean something and no quoting it won't help because...

Hah, then explain to them why they try to echo `-n' it works when they
write it but not when they try to run it somewhere else. But I suppose
when you try to move a script from one system to another, you're no longer
a `newbie'.



> I'm looking for a Linux standard

I think you're going to have to keep looking.


> You've already mentioned you personally took your project through posix
> certification. Just possibly a little bit of selection bias there.

I didn't. I said I ran the shell through the test suite. That's not
certification; I'm not certifying an entire system here, and the Open
Group doesn't care -- and isn't going to give me anything -- whether or
not I did it. I did it for my own purposes, because posix conformance is a
goal for the shell, and it doesn't have anything to do with whether or not
ls reorders arguments, or whether pax or sccs are installed, or what's in
libc.



>>> (And yes I have a TODO item to have wildcards expand to "./-file" as necessary...)
>>
>> Contortions like that are why argument reordering is a bad idea.
> 
> Sure, but that's been how Linux works since about 1993.

And yet bash has never done that, and I've never felt the need to add it.


>> Refer to my previous comment about pounding sand. The standard would not
>> have been approved in 1992 with tar and cpio. There were a lot more
>> companies with a stake in it back then.
> 
> Chesterton's fence again.

You keep saying that, but the real-world situation was that the POSIX
committee considered an approved standard more important. The state of
affairs at the time was pretty clear.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/