[Toybox] [PATCH] Implement mv -n / cp -n (no clobber).

[Andy Chu]

> A) It's in posix,
>
> B) It shares infrastructure with the shell $((math)) functions,
>
> C) It's used rather a lot in autoconf and shell scripts. Let's see,the
> first package that always broke in my linux from scratch builds when I
> was making busybox work with that was binutils...

Those all seemed like reasons that *toybox* has expr, not Android.  I
was wondering why expr was pulled out of pending, rather than just
having a defconfig build on Android.

But Elliot basically answered my question below -- it seems they're
aiming for a POSIX compliant environment on Android.  (That certainly
wasn't the case when Android launched; it was Linux but not Unix).

Anyway, I'm definitely in favor of Android being more Unix-like, to
the point of spending my time writing code for it (and it's not paid).
I WANT expr to be used of course!

>> I only know a little about Android (from building AOSP
>> 18 months ago), but my impression was that the use of shell scripts
>> was limited, and they were all "in-tree" so you can patch them.
>
> If you want to turn Android into a build environment that has at least
> the _option_ to build existing packages, you need expr, yes.

As I said, I'm definitely for that goal, but AFAIK nobody's building
the Linux kernel on an Android device now...  I'm trying to wrap my
head around things that have a 1 year time frame vs things that have a
5 or 10 year time frame.

>> Who uses the shell?  I would have guessed it's for the boot process
>> mainly?
>
> Didn't he just said that a shell problem broke his build?

I think he was saying mksh doesn't compile with Clang, which makes it
annoying to maintain.  I was asking a different question.


>> I think it would be cool to have my shell on Android, and it's written
>> in Google-style C++ like Ninja like I said, with unit tests, no
>> globals and (tasteful) dependency injection and everything.  It's only
>> 2 weeks of work and 2800 lines of code now, so that's a long ways off
>> :)
>
> Toybox needs an integrated shell and isn't going to import c++ code, but
> if android winds up using your shell instead of that one it's Elliott's
> call, not mine.
>
> Writing a shell isn't actually _hard_, what it is is _elaborate_.
> There's a lot of surface area to cover, and I want to do it _right_
> which means not stopping and restarting 30 times while interrupted by
> something else. (Once I open this can of worms it's going to eat 6
> months of my life.)

I wouldn't really agree with that.  You could say programming isn't
hard then either.  IMO one of the most important parts of programming
is controlling complexity, and shell is inherently complex.  It's also
big, and big things are hard.

In addition, parsing is not a solved problem, and the shell language
shows that (and bash shows that; I refer to the aosabook chapter
again.)  It's a fair bit more elaborate than what they teach you about
parsing in compiler class.

> That said I may need to start on this for $DAYJOB soon, since the only
> nommu shell we've got right now is busybox hush and they don't want to
> ship gpl code in userspace either, especially from a project with a
> history of litigation. (Can't say I blame 'em...)
>
>> But I'm curious about the use cases.  I think I can probably get some
>> other shell users at Google to contribute, because I've done a lot of
>> the hard parts in a clean way.  Lexing and parsing shell are
>> particularly hard IMO; compare with mksh's yylex() and associated
>> macros in lex.c, which is about 1000 lines in a single function, and
>> it only does part of the job my lexer does.
>
> *shrug* Toybox will eventually have a shell anyway, but if you want a
> different one written in a different language, have fun?

I am having a lot of fun :)  I have finally gotten to work on
something I've wanted to work on for years.  In 2009, I actually tried
to convince Rob Pike and Russ Cox that there needs to be a shell
paired with Go, since Go is an updated C (and I'm sure they didn't
take it seriously, which was wise.)

You talk about your TODO list in a lot of messages... it seems to be a
decade or two long.  So I don't really think there is any harm in
parallelizing the effort.  My goals overlap with yours but aren't
identical.  I suspect it may converge at some point, but if not that's
fine too.  At the very least, the research I'm doing -- looking into 3
or 4 shell implementations and POSIX -- will be useful for what you
want to do.  Hopefully I will find some time to make a writeup of it.

Andy