| Message ID | 20210701061611.957918-6-seanga2@gmail.com |
|---|---|
| State | RFC |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | cli: Add a new shell | expand |
Hi Sean, On Thu, 1 Jul 2021 at 00:16, Sean Anderson <seanga2@gmail.com> wrote: > > Several functions have different names than they do in TCL. To make things > easier for those familiar with TCL, rename them to their TCL equivalents. > At the moment, this is only done for functions not used by LIL_FULL. Some > functions need more substantive work to conform them to TCL. For example, > in TCL, there is a `string` function with a subcommand of `compare`, which > is the same as the top-level function `compare`. Several functions also > have no TCL equivalent. Do we need these? > > TODO: do this for all functions > > Signed-off-by: Sean Anderson <seanga2@gmail.com> > --- > > common/cli_lil.c | 28 ++++++++++++++-------------- > 1 file changed, 14 insertions(+), 14 deletions(-) Is your intent to create a fork of this in U-Boot? Could we not update things upstream, at least as an option, to avoid carrying these patches? Regards, Simon
On 7/5/21 11:29 AM, Simon Glass wrote: > Hi Sean, > > On Thu, 1 Jul 2021 at 00:16, Sean Anderson <seanga2@gmail.com> wrote: >> >> Several functions have different names than they do in TCL. To make things >> easier for those familiar with TCL, rename them to their TCL equivalents. >> At the moment, this is only done for functions not used by LIL_FULL. Some >> functions need more substantive work to conform them to TCL. For example, >> in TCL, there is a `string` function with a subcommand of `compare`, which >> is the same as the top-level function `compare`. Several functions also >> have no TCL equivalent. Do we need these? >> >> TODO: do this for all functions >> >> Signed-off-by: Sean Anderson <seanga2@gmail.com> >> --- >> >> common/cli_lil.c | 28 ++++++++++++++-------------- >> 1 file changed, 14 insertions(+), 14 deletions(-) > > Is your intent to create a fork of this in U-Boot? Yes. I believe some of the major additions I have made (especially "[RFC PATCH 21/28] cli: lil: Add a distinct parsing step") would not be accepted by upstream. > Could we not update things upstream, at least as an option, to avoid > carrying these patches? For some of the smaller patches, that may be possible. However, I am not a fan of the major amount of ifdefs that Hush has. For something as core as a shell, I think we should be free to make changes as we see fit without worrying about how it will affect a hypothetical backport. For this patch in particular, I believe upstream would no accept it because it would break backwards compatibility for existing LIL users. However, I view compatibility with TCL as a whole more valuble than compatibility with LIL. --Sean
Dear Sean, In message <d808990b-623d-d962-c7d6-e40063bc5dab@gmail.com> you wrote: > > > Is your intent to create a fork of this in U-Boot? > > Yes. I believe some of the major additions I have made (especially "[RFC > PATCH 21/28] cli: lil: Add a distinct parsing step") would not be > accepted by upstream. Ouch... > > Could we not update things upstream, at least as an option, to avoid > > carrying these patches? > > For some of the smaller patches, that may be possible. However, I am not > a fan of the major amount of ifdefs that Hush has. For something as core > as a shell, I think we should be free to make changes as we see fit > without worrying about how it will affect a hypothetical backport. I'm afraind I cannot understand your thinking. You complain that the existing port of hus has a number of severe limitations or bugs which have long been fixed upstream, but cannot be easily fixed in U-Boot because we essentially created an unmaintained fork - and as a cure, you recommend to do the same thing again, but this time intentionally and deliberately? If you had not apparently already invested a lot of effort into this thing I would assume you must be joking... To me such an approach is unacceptable. Best regards, Wolfgang Denk
On Mon, Jul 05, 2021 at 07:58:18PM +0200, Wolfgang Denk wrote: > Dear Sean, > > In message <d808990b-623d-d962-c7d6-e40063bc5dab@gmail.com> you wrote: > > > > > Is your intent to create a fork of this in U-Boot? > > > > Yes. I believe some of the major additions I have made (especially "[RFC > > PATCH 21/28] cli: lil: Add a distinct parsing step") would not be > > accepted by upstream. > > Ouch... > > > > Could we not update things upstream, at least as an option, to avoid > > > carrying these patches? > > > > For some of the smaller patches, that may be possible. However, I am not > > a fan of the major amount of ifdefs that Hush has. For something as core > > as a shell, I think we should be free to make changes as we see fit > > without worrying about how it will affect a hypothetical backport. > > I'm afraind I cannot understand your thinking. > > You complain that the existing port of hus has a number of severe > limitations or bugs which have long been fixed upstream, but cannot > be easily fixed in U-Boot because we essentially created an > unmaintained fork - and as a cure, you recommend to do the same > thing again, but this time intentionally and deliberately? > > > If you had not apparently already invested a lot of effort into this > thing I would assume you must be joking... > > To me such an approach is unacceptable. I think I want to try and address this. While with "hush" we have something that's in heavy active development outside of U-Boot, with LIL we have something that's mature and "done". Tracking an active outside development is HARD and requires constant resync. Look at the last few LIL releases. That could be easily re-worked in to our fork if needed. I see that as a positive, not a negative.
On 7/5/21 1:58 PM, Wolfgang Denk wrote: > Dear Sean, > > In message <d808990b-623d-d962-c7d6-e40063bc5dab@gmail.com> you wrote: >> >>> Is your intent to create a fork of this in U-Boot? >> >> Yes. I believe some of the major additions I have made (especially "[RFC >> PATCH 21/28] cli: lil: Add a distinct parsing step") would not be >> accepted by upstream. > > Ouch... I don't particularly mind if Kostas doesn't view these patches as good additions to upstream. We have different goals and requirements, and so not all changes will be compatible. >>> Could we not update things upstream, at least as an option, to avoid >>> carrying these patches? >> >> For some of the smaller patches, that may be possible. However, I am not >> a fan of the major amount of ifdefs that Hush has. For something as core >> as a shell, I think we should be free to make changes as we see fit >> without worrying about how it will affect a hypothetical backport. > > I'm afraind I cannot understand your thinking. > > You complain that the existing port of hus has a number of severe > limitations or bugs which have long been fixed upstream, The bugs are fairly minor. The particular characteristics of Hush have not changed. These characteristics make Hush difficult to adapt to the limitations of U-Boot. When we cannot support the basic abstractions expected by Hush, the shell will necessarily change for the worse. > but cannot be easily fixed in U-Boot Because they are core to the design of Hush (and other bourne derived shells). > because we essentially created an unmaintained fork I plan to maintain this fork. --Sean > - and as a cure, you recommend to do the same > thing again, but this time intentionally and deliberately? > If you had not apparently already invested a lot of effort into this > thing I would assume you must be joking... > > To me such an approach is unacceptable. > > Best regards, > > Wolfgang Denk >
Hi Tom, On Mon, 5 Jul 2021 at 12:51, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Jul 05, 2021 at 07:58:18PM +0200, Wolfgang Denk wrote: > > Dear Sean, > > > > In message <d808990b-623d-d962-c7d6-e40063bc5dab@gmail.com> you wrote: > > > > > > > Is your intent to create a fork of this in U-Boot? > > > > > > Yes. I believe some of the major additions I have made (especially "[RFC > > > PATCH 21/28] cli: lil: Add a distinct parsing step") would not be > > > accepted by upstream. > > > > Ouch... > > > > > > Could we not update things upstream, at least as an option, to avoid > > > > carrying these patches? > > > > > > For some of the smaller patches, that may be possible. However, I am not > > > a fan of the major amount of ifdefs that Hush has. For something as core > > > as a shell, I think we should be free to make changes as we see fit > > > without worrying about how it will affect a hypothetical backport. > > > > I'm afraind I cannot understand your thinking. > > > > You complain that the existing port of hus has a number of severe > > limitations or bugs which have long been fixed upstream, but cannot > > be easily fixed in U-Boot because we essentially created an > > unmaintained fork - and as a cure, you recommend to do the same > > thing again, but this time intentionally and deliberately? > > > > > > If you had not apparently already invested a lot of effort into this > > thing I would assume you must be joking... > > > > To me such an approach is unacceptable. > > I think I want to try and address this. While with "hush" we have > something that's in heavy active development outside of U-Boot, with LIL > we have something that's mature and "done". Tracking an active outside > development is HARD and requires constant resync. Look at the last few > LIL releases. That could be easily re-worked in to our fork if needed. > I see that as a positive, not a negative. Yes I wondered about that, since hush has been in busybox, an active project, all these years. I think this is a good point and perhaps means that forking it should not be too much of a concern. Still, if we can send some things upstream, we should. Regards, Simon
On Mon, Jul 05, 2021 at 03:02:24PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 5 Jul 2021 at 12:51, Tom Rini <trini@konsulko.com> wrote: > > > > On Mon, Jul 05, 2021 at 07:58:18PM +0200, Wolfgang Denk wrote: > > > Dear Sean, > > > > > > In message <d808990b-623d-d962-c7d6-e40063bc5dab@gmail.com> you wrote: > > > > > > > > > Is your intent to create a fork of this in U-Boot? > > > > > > > > Yes. I believe some of the major additions I have made (especially "[RFC > > > > PATCH 21/28] cli: lil: Add a distinct parsing step") would not be > > > > accepted by upstream. > > > > > > Ouch... > > > > > > > > Could we not update things upstream, at least as an option, to avoid > > > > > carrying these patches? > > > > > > > > For some of the smaller patches, that may be possible. However, I am not > > > > a fan of the major amount of ifdefs that Hush has. For something as core > > > > as a shell, I think we should be free to make changes as we see fit > > > > without worrying about how it will affect a hypothetical backport. > > > > > > I'm afraind I cannot understand your thinking. > > > > > > You complain that the existing port of hus has a number of severe > > > limitations or bugs which have long been fixed upstream, but cannot > > > be easily fixed in U-Boot because we essentially created an > > > unmaintained fork - and as a cure, you recommend to do the same > > > thing again, but this time intentionally and deliberately? > > > > > > > > > If you had not apparently already invested a lot of effort into this > > > thing I would assume you must be joking... > > > > > > To me such an approach is unacceptable. > > > > I think I want to try and address this. While with "hush" we have > > something that's in heavy active development outside of U-Boot, with LIL > > we have something that's mature and "done". Tracking an active outside > > development is HARD and requires constant resync. Look at the last few > > LIL releases. That could be easily re-worked in to our fork if needed. > > I see that as a positive, not a negative. > > Yes I wondered about that, since hush has been in busybox, an active > project, all these years. I think this is a good point and perhaps > means that forking it should not be too much of a concern. Still, if > we can send some things upstream, we should. Well, that's part of the problem. If we re-port modern hush, who is going to keep it in sync, and how often? Yes, there will be changes we don't need, but there will be bugfixes we do as well.
Dear Sean, In message <7143cb1e-4061-3034-57b9-1a12753fa642@gmail.com> you wrote: > > > > You complain that the existing port of hus has a number of severe > > limitations or bugs which have long been fixed upstream, > > The bugs are fairly minor. The particular characteristics of Hush have > not changed. These characteristics make Hush difficult to adapt to the > limitations of U-Boot. When we cannot support the basic abstractions > expected by Hush, the shell will necessarily change for the worse. This is not true. Just have a look what hush in a recent version of Busybox offers. > > but cannot be easily fixed in U-Boot > > Because they are core to the design of Hush (and other bourne derived > shells). Oh, this is an interesting opinion. I doubt if a majority (or even a significant percentage) of U-Boot users share it. If you were right, there would be far less users of bash (or other "bourne derived shells"). Guess which percentage of users of UNIX operating systems is using a Tcl based command interpreter as their login shell? Best regards, Wolfgang Denk
Dear Tom, In message <20210705185141.GA9516@bill-the-cat> you wrote: > > I think I want to try and address this. While with "hush" we have > something that's in heavy active development outside of U-Boot, with LIL > we have something that's mature and "done". Mature? And still without consequent error checking? And done, i. e. this will never be fixed? > Tracking an active outside development is HARD and requires > constant resync. Based on that logic we should stop supporting Linux, and stop using DTs or file systems - all of these are under "active outside development". This is a bogus argiment. > Look at the last few > LIL releases. That could be easily re-worked in to our fork if needed. > I see that as a positive, not a negative. OK, this is your opinion. Mine differs. Please consider this as a full NAK from me when when you think of it as a _replacement_ (even an optional one) of the standard shell. If you like, have it added as an _additional_ command, of course fully optional and without impact on the rest of U-Boot if not intentionally selected. Best regards, Wolfgang Denk
Hi Wolfgang, On Tue, 6 Jul 2021 at 01:53, Wolfgang Denk <wd@denx.de> wrote: > > Dear Tom, > > In message <20210705185141.GA9516@bill-the-cat> you wrote: > > > > I think I want to try and address this. While with "hush" we have > > something that's in heavy active development outside of U-Boot, with LIL > > we have something that's mature and "done". > > Mature? And still without consequent error checking? And done, > i. e. this will never be fixed? > > > > Tracking an active outside development is HARD and requires > > constant resync. > > Based on that logic we should stop supporting Linux, and stop using > DTs or file systems - all of these are under "active outside > development". > > This is a bogus argiment. > > > > Look at the last few > > LIL releases. That could be easily re-worked in to our fork if needed. > > I see that as a positive, not a negative. > > OK, this is your opinion. Mine differs. > > Please consider this as a full NAK from me when when you think of it > as a _replacement_ (even an optional one) of the standard shell. If > you like, have it added as an _additional_ command, of course fully > optional and without impact on the rest of U-Boot if not > intentionally selected. That seems reasonable to me. There is certainly interest in these threads in reporting hush, perhaps with a goal of upstreaming the U-Boot-specific changes back to busybox. But so far no one has done it... Regards, Simon
On Tue, Jul 06, 2021 at 09:52:56AM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20210705185141.GA9516@bill-the-cat> you wrote: > > > > I think I want to try and address this. While with "hush" we have > > something that's in heavy active development outside of U-Boot, with LIL > > we have something that's mature and "done". > > Mature? And still without consequent error checking? And done, > i. e. this will never be fixed? Intentional design by upstream, and then for the actual problem part (error checking, test suite), Sean is saying he'll fix it, and has started on it. > > Tracking an active outside development is HARD and requires > > constant resync. > > Based on that logic we should stop supporting Linux, and stop using > DTs or file systems - all of these are under "active outside > development". > > This is a bogus argiment. Alright, go and update our Kbuild integration to be in sync with current Linux. Or just v5.0. I'd suggest picking up the metadata_csum support patch but someone did say they'd try and update that (off-list) so that ext4 filesystem made with default options in the last 5 years (not exaggerating) work. I'm not even going to talk about the various level of out of sync our DTs files are but I do have some hope there will be more re-syncs especially as it comes to more light that the DT U-Boot uses can just be the DT the OS gets. Then tell me it's easy to keep this stuff in sync. Because we certainly don't want to just fork-and-forget again, right? Because that's why we have both crazy parse bugs as well as lack of now old-and-expected features. OK, snark aside, I'm very serious here, any "we'll just import ..." needs to have a plan to keep it up to date, or be easy enough to do such that I can set a monthly reminder to check for and do the update. Every area where we don't do this is a set of problems waiting to get worse, as we can see with the hush shell right now as it's one of the oldest things we stopped syncing with. > > Look at the last few > > LIL releases. That could be easily re-worked in to our fork if needed. > > I see that as a positive, not a negative. > > OK, this is your opinion. Mine differs. > > Please consider this as a full NAK from me when when you think of it > as a _replacement_ (even an optional one) of the standard shell. If > you like, have it added as an _additional_ command, of course fully > optional and without impact on the rest of U-Boot if not > intentionally selected. Any new cli for U-Boot won't be a default build as a command for a long while after it's merged. I'm not sure how much past that point it would further need to be to become the default cli. And I'll even repeat what I said elsewhere about how an sh syntax is a good user feature. But I really think we want a shell environment that is not actively adding new features is a good thing, for the default. Just how much stuff should we be doing or need to be doing before we hand things over to the OS?
On 7/6/2021 6:33 PM, Tom Rini wrote: >> Mature? And still without consequent error checking? And done, >> i. e. this will never be fixed? > > Intentional design by upstream, and then for the actual problem part > (error checking, test suite), Sean is saying he'll fix it, and has > started on it. To clarify, the intentional design aspect is for the language (e.g. giving garbage to "expr"). The library does need better memory alloc checks (this is the main thing missing because i never had to use LIL on an environment without virtual memory... or where malloc would ever practically fail), though IIRC there aren't any other cases where failure could happen and isn't checked. Similarly i do plan on implementing a proper test suite (currently there is a shell script that runs all the examples in the source code - many examples were made to expose previous bugs - with two different implementations which can be used to find regressions in subsequent releases and differences between implementations, but the examples do not exhaust the code paths the parser could take) at some point - the latter is more likely to happen soon than the former. The same applies with LIL being "done" (well, mostly done) - this is about the language, not the implementation which (as i mentioned in another email) does need improvements, especially around performance (which is also a reason i need to implement better automated tests). Kostas
Dear Tom, In message <20210706153327.GS9516@bill-the-cat> you wrote: > > > Mature? And still without consequent error checking? And done, > > i. e. this will never be fixed? > > Intentional design by upstream, and then for the actual problem part > (error checking, test suite), Sean is saying he'll fix it, and has > started on it. Seriously - any piece of software that omits error checking intentionally be design should be indented six feet downward and covered with dirt. We should not even consider looking at it. > OK, snark aside, I'm very serious here, any "we'll just import ..." > needs to have a plan to keep it up to date, or be easy enough to do such > that I can set a monthly reminder to check for and do the update. Every > area where we don't do this is a set of problems waiting to get worse, > as we can see with the hush shell right now as it's one of the oldest > things we stopped syncing with. Which exact _new_ problems do we see with hush right now? I can only see old ones, that have been known (and worked around) for nearly two decades. The limitations and bugs have all been there since the beginning - the limitations actually being intentional due to the typical resource situation at that time. > But I > really think we want a shell environment that is not actively adding new > features is a good thing, for the default. Just how much stuff should > we be doing or need to be doing before we hand things over to the OS? You are shooting yourself in the knee here. If you think out CLI should not be adding new features, then we should just stick with our ancient hush and neither update it nor replace it with something else that adds not only new features, but breaks backward compatibility, hard. Best regards, Wolfgang Denk
On Wed, Jul 07, 2021 at 10:16:13AM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20210706153327.GS9516@bill-the-cat> you wrote: > > > > > Mature? And still without consequent error checking? And done, > > > i. e. this will never be fixed? > > > > Intentional design by upstream, and then for the actual problem part > > (error checking, test suite), Sean is saying he'll fix it, and has > > started on it. > > Seriously - any piece of software that omits error checking > intentionally be design should be indented six feet downward and > covered with dirt. We should not even consider looking at it. > > > OK, snark aside, I'm very serious here, any "we'll just import ..." > > needs to have a plan to keep it up to date, or be easy enough to do such > > that I can set a monthly reminder to check for and do the update. Every > > area where we don't do this is a set of problems waiting to get worse, > > as we can see with the hush shell right now as it's one of the oldest > > things we stopped syncing with. > > Which exact _new_ problems do we see with hush right now? I can > only see old ones, that have been known (and worked around) for > nearly two decades. > > The limitations and bugs have all been there since the beginning - > the limitations actually being intentional due to the typical > resource situation at that time. There's all of the new features that've been suggested for our current hush, many by Sean, for which the reply has been "our hush is old, it should be updated!". And you didn't address my point, taking code from another project requires dedicated maintenance to keep it up to date and we do have a lot of in-tree examples right now of where that lack of dedicated maintenance is a problem. > > But I > > really think we want a shell environment that is not actively adding new > > features is a good thing, for the default. Just how much stuff should > > we be doing or need to be doing before we hand things over to the OS? > > You are shooting yourself in the knee here. > > If you think out CLI should not be adding new features, then we > should just stick with our ancient hush and neither update it nor > replace it with something else that adds not only new features, but > breaks backward compatibility, hard. Honestly, adding new features to the CLI (which is NOT the same as adding new commands, or enhancing existing commands) is very low on my priority list. We need to get the Kconfig migration done. We need to get DM migration done (which will help with the Kconfig one by showing hardware no one cares for anymore, and reducing symbols). We need to make adding new hardware easier. We need to get DTS files in-sync more often. There are very important developer use cases for a more flexible CLI interpreter. But the main use case is still "boot the (redundant) OS ASAP". So, what is my priority on this series right here? Well, a developer has posted a series. They believe it's useful and addressing a long-standing problem. They want feedback. I'm trying to provide feedback as it's to a general area of the codebase.
On 7/6/21 3:50 AM, Wolfgang Denk wrote: > Dear Sean, > > In message <7143cb1e-4061-3034-57b9-1a12753fa642@gmail.com> you wrote: >>> >>> You complain that the existing port of hus has a number of severe >>> limitations or bugs which have long been fixed upstream, >> >> The bugs are fairly minor. The particular characteristics of Hush have >> not changed. These characteristics make Hush difficult to adapt to the >> limitations of U-Boot. When we cannot support the basic abstractions >> expected by Hush, the shell will necessarily change for the worse. > > This is not true. Just have a look what hush in a recent version of > Busybox offers. Busybox runs in a Linux environment. Many of its features rely on the core functionality provided by Linux, which we do not provide in U-Boot. This is what makes porting features difficult. > >>> but cannot be easily fixed in U-Boot >> >> Because they are core to the design of Hush (and other bourne derived >> shells). > > Oh, this is an interesting opinion. I doubt if a majority (or even > a significant percentage) of U-Boot users share it. If you were > right, there would be far less users of bash (or other "bourne > derived shells"). Guess which percentage of users of UNIX operating > systems is using a Tcl based command interpreter as their login > shell? And yet, this is not the field we compete in. While bourne-style shells can take advantage of a multi-threaded environment, embedded shells tend to implement a much wider set of languages. See [1] for a survey of examples. --Sean [1] https://github.com/dbohdan/embedded-scripting-languages
Dear Sean, In message <d8447d79-f1d4-8a2f-39b9-a6650c936b88@gmail.com> you wrote: > ... > And yet, this is not the field we compete in. While bourne-style shells > can take advantage of a multi-threaded environment, embedded shells tend > to implement a much wider set of languages. See [1] for a survey of > examples. > > [1] https://github.com/dbohdan/embedded-scripting-languages "Embedded scripting languages" is probably not a good match for what we are discussing. I don't think this comparison was made for restricted boot loader environments, but for use in general purpose / embedded operating systems. Hey, they even list Forth there. Maybe somebody should port OpenBoot, so we can have a Forth interpreter as new commandline language? We could implement device trees in the old, traditional way then, too :-) Best regards, Wolfgang Denk
diff --git a/common/cli_lil.c b/common/cli_lil.c index a2e5cdf35a..a6c77ee19c 100644 --- a/common/cli_lil.c +++ b/common/cli_lil.c @@ -1829,10 +1829,10 @@ static struct lil_value *fnc_reflect(struct lil *lil, size_t argc, return lil_clone_value(func->code); } - if (!strcmp(type, "func-count")) + if (!strcmp(type, "proc-count")) return lil_alloc_integer(lil->cmds); - if (!strcmp(type, "funcs")) { + if (!strcmp(type, "procs")) { struct lil_list *funcs = lil_alloc_list(); for (i = 0; i < lil->cmds; i++) @@ -1878,7 +1878,7 @@ static struct lil_value *fnc_reflect(struct lil *lil, size_t argc, return r; } - if (!strcmp(type, "has-func")) { + if (!strcmp(type, "has-proc")) { const char *target; if (argc == 1) @@ -1948,7 +1948,7 @@ static struct lil_value *fnc_reflect(struct lil *lil, size_t argc, return NULL; } -static struct lil_value *fnc_func(struct lil *lil, size_t argc, +static struct lil_value *fnc_proc(struct lil *lil, size_t argc, struct lil_value **argv) { struct lil_value *name; @@ -2472,8 +2472,8 @@ static struct lil_value *real_inc(struct lil *lil, const char *varname, return pv; } -static struct lil_value *fnc_inc(struct lil *lil, size_t argc, - struct lil_value **argv) +static struct lil_value *fnc_incr(struct lil *lil, size_t argc, + struct lil_value **argv) { if (argc < 1) return NULL; @@ -2482,8 +2482,8 @@ static struct lil_value *fnc_inc(struct lil *lil, size_t argc, argc > 1 ? lil_to_integer(argv[1]) : 1); } -static struct lil_value *fnc_dec(struct lil *lil, size_t argc, - struct lil_value **argv) +static struct lil_value *fnc_decr(struct lil *lil, size_t argc, + struct lil_value **argv) { if (argc < 1) return NULL; @@ -2786,8 +2786,8 @@ static struct lil_value *fnc_rtrim(struct lil *lil, size_t argc, return real_trim(lil_to_string(argv[0]), chars, 0, 1); } -static struct lil_value *fnc_strcmp(struct lil *lil, size_t argc, - struct lil_value **argv) +static struct lil_value *fnc_compare(struct lil *lil, size_t argc, + struct lil_value **argv) { if (argc < 2) return NULL; @@ -2940,18 +2940,18 @@ static struct lil_value *fnc_lmap(struct lil *lil, size_t argc, static void register_stdcmds(struct lil *lil) { - lil_register(lil, "dec", fnc_dec); + lil_register(lil, "decr", fnc_decr); lil_register(lil, "eval", fnc_eval); lil_register(lil, "expr", fnc_expr); lil_register(lil, "for", fnc_for); lil_register(lil, "foreach", fnc_foreach); - lil_register(lil, "func", fnc_func); + lil_register(lil, "proc", fnc_proc); lil_register(lil, "if", fnc_if); - lil_register(lil, "inc", fnc_inc); + lil_register(lil, "incr", fnc_incr); lil_register(lil, "local", fnc_local); lil_register(lil, "return", fnc_return); lil_register(lil, "set", fnc_set); - lil_register(lil, "strcmp", fnc_strcmp); + lil_register(lil, "compare", fnc_compare); lil_register(lil, "try", fnc_try); lil_register(lil, "while", fnc_while);
Several functions have different names than they do in TCL. To make things easier for those familiar with TCL, rename them to their TCL equivalents. At the moment, this is only done for functions not used by LIL_FULL. Some functions need more substantive work to conform them to TCL. For example, in TCL, there is a `string` function with a subcommand of `compare`, which is the same as the top-level function `compare`. Several functions also have no TCL equivalent. Do we need these? TODO: do this for all functions Signed-off-by: Sean Anderson <seanga2@gmail.com> --- common/cli_lil.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-)