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

[Rob Landley]

On 7/10/23 16:57, enh wrote:
> and i think that's the cross-purpose we're talking at here ... the 99% case is
> app code...
> the kind of collaborative command-line debugging over a mailing list that you're
> familiar with doesn't exist for the TikToks of this world.

There's no amount of leaves a tree can sprout that mean it no longer needs a
trunk or roots so you can get rid of those.

>     > i'm not a _fan_ of SIGSYS,
>     > but i do still think it was the lesser of the available evils. (but of
>     > course it's the folks who _do_ check for failures who're most likely to
>     > disagree;
> 
>     OK, I'm going to disagree.
> 
> because you have a completely different use case _and_ you're a very different
> kind of developer. there's no question it's not a good fit for you. (but you're
> running in an app _context_ even if not in an app, so you get to enjoy "one size
> fits all" :-( )

I remember the original java applet vs application divide.

I hope someday to have an application container context, with the capability to
securely perform tasks on phone hardware/OS that can currently only be performed
on PC hardware/OS. The ability to create a new system image and the ability to
install a new system image are distinct, like running as a normal user vs
running as root.

I'm also aware that getting from here to there is fraught, what with warhol
worms, evil maid attacks, state actors, and the device's nature as a 24/7
broadband connected GPS tracker with whole room microphone which some people
allow to perform payment processing.

But 30 years ago "there's a computer in every home, but we can't trust those,
you can only do systems programming by logging into at least a Vax"... is not
how history went. And would have been a BAD history, involving no teenagers
getting good at systems programming leading to no future systems programmers
outside of IBM etc. It would have prevented Linux, for one thing. (And the state
actors DO have the big iron: always did.)

>     If AC_CHECK_FUNCS doesn't do the right thing when cross-compiling, maybe
>     the autotools folks should hear about it?
> 
> i don't think autoconf is broken (given that _some_ stuff gets it right). but a
> lot of library developers just don't take cross-compilation into account.
> (obviously massive selection bias here since i was an embedded developer before
> working on Android, so i've mostly _only_ known cross-compilation, plus i
> obviously don't have to spend much time on the libraries that _do_ work.)

I've ranted about autoconf a lot over the years:

https://nondeterministic.computer/@landley@mstdn.jp/110181223774509774

https://git.busybox.net/busybox/commit/editors/sed.c?id=c06f568ddaaa

http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000860.html

Not a fan. (Also, with autoconf/automake you need more dependency packages
installed to build the repository version than you do to build the release
tarball, which is always annoying.)

That said, it exists, gotta make it work...

Rob