[Solved] Asking for recomendations on the shell script formatting.

[GNUser]

Unfortunately it is sad to see that the latest commits on such scripts go back 10 or more years.

Why is it sad? Since the scripts still work perfectly on the current version of busybox ash (TCL's default shell), what would be the point of changing them? I think the age of the commits speaks to the quality of the scripts and the stability of TCL's goals and design.

[CardealRusso]

Sorry, maybe I didn't make myself clear. My point is simply modernization. The discussion I propose is precisely the extent to which this modernization will violate tinycore's "keep everything small" principles.

I don't think that the long age of something functional is reason enough for it to stop in time.
Maybe I'm being a little extreme in making this comparison, but I can make Windows XP work perfectly.

[jazzbiker]

Hm, how different approaches are! For me the code which is in the age of 10 years and works well is 10 times better than the code in age of 1 year ) Like a wine, I guess. The sign and proof that it was mastered perfectly.
By the way, CardealRusso, I completely don't understand what is modern syntax??? Probably it means that I'm outdated ) along with Lua )
Thanks for tce-size script! I will gladly test it later. And some Core scripts may be a little bit sluggish. As we've seen not long ago when GNUser proposed his version of update-everything script, which appeared to be 10 times faster, if I am not mistaken. Maybe some performance bottlenecks exist and may be made more comfortable at least.

[GNUser]

TCL is stable, fast, small, understandable, easily extendable, runs on old machines, runs on new machines. Extensions (applications) are updated when necessary to fix breakage or provide security fixes. New applications become available when users find new uses for TCL and are generous enough to submit new extensions for the repository.

The above is what I care about. If the TCL infrastructure is able to support the above--and it is--then the age of the infrastructure makes little difference to me. (If anything, I'd say older infrastructure is better because it has had time to prove its stability. Would you rather drive on a 10 year-old bridge or on a 1 week-old bridge?)

But I speak only for myself, not for the project. I'm not a TCL developer, just a grateful user+contributor.

[CardealRusso]

TCL is stable, fast, small, understandable, easily extendable, runs on old machines, runs on new machines.

I've made my point clear, now maybe it's time to make yours clear. You don't make clear what you are arguing against. I just suggested a modernization, but nothing specific. I initially suggested NIM, but soon abandoned this idea in favor of lua, which I also abandoned because I thought it was outdated.

As for lua, it is available in all TinyCore repositories, the package and its dependencies in total barely reach 1MB. What do you necessarily mean? That if TCL migrated to LUA, it would be done wrong and break the system?

That those 500KB would be too much to support? I need you to enlighten me so that I can also enlighten you. My point about the migration is a syntax that facilitates the contribution of other users.
Bash scripts do work but they are also extremely delicate, maybe that's why everyone is afraid to make any changes. While it's working, it's very easy to break a bash script with one or two changes.

The tce-update for example, I was trying to find a piece of code to ignore non-existent extensions from the repository, so that the update wouldn't be interrupted by things like "mylocale.tcz", but I got so lost that I gave up.

I completely don't understand what is modern syntax???

Perhaps this is subjective. By "modern" in this context of scripts and small programs, I necessarily mean you typing less to achieve the same without sacrificing code readability for future and third party maintenance.

It is clearly impossible to achieve all these points at once, but some manage to achieve this balance. Perhaps there are more, but of the ones I've tested, the ones that achieve this are: Python, Nim, and Node. Today I checked that Lua was on this list until recently, he clearly left recently.

[Rich]

Hi CardealRusso

... The constant use of "ends" and other redundancies makes lua outdated. ...

I'm not familiar with Lua programming, but assuming the syntax
you provided is correct, I would describe it as:
The consistent use of "ends".

Don't all languages have some way of marking where a function ends?
How about where  if, while, for, case,  and other conditional clauses end?
Ash/bash uses }, fi, done, done, and esac for these.
C uses } but allows ; for one liners.

[jazzbiker]

It is clearly impossible to achieve all these points at once, but some manage to achieve this balance. Perhaps there are more, but of the ones I've tested, the ones that achieve this are: Python, Nim, and Node. Today I checked that Lua was on this list until recently, he clearly left recently.

What is Node? Is this the language name?

[CardealRusso]

Don't all languages have some way of marking where a function ends?

Certainly. I assume it's a must.... That  can be anything from "e n d" to a simple "<return>" or, actually, nothing (assuming it already has a line break)

What is Node? Is this the language name?

Sorry, are you asking a genuine question or being sarcastic?

Assuming this is a genuine question, anyone who has mastered the basics of JS understands that interpreters are easier to speak than JS itself. After all, if I suggest the JS, I have to immediately suggest the interpreter...

Which could be the 1mb QuickJS or the 40mb node (plus many others of course, this was just to demonstrate the difference in size)

Assuming you're being sarcastic:

[jazzbiker]

No, I was not sarcastic. Don't do too many assumptions.

[GNUser]

I've made my point clear, now maybe it's time to make yours clear. You don't make clear what you are arguing against.

I'm arguing against making drastic changes to TCL's infrastructure because of potential stability issues. As it is (i.e., powered by shell scripts including some that are a decade old), TCL is stable, does absolutely everything I need it to do (and well), and has qualities that make it the only distro that I want to use and contribute to.

The TCL developers do not discriminate against new technologies and will accept your contributions if they are good. Good luck!

I don't have anything else to add to this discussion. Happy hacking!

[Rich]

Hi CardealRusso

Don't all languages have some way of marking where a function ends?

Certainly. I assume it's a must.... That  can be anything from "e n d"  ...

Didn't you just criticize  The constant use of "ends"  in a previous post?

... to a simple "<return>" or, actually, nothing (assuming it already has a line break) ...

I take it you mean a blank line. That would mean no blank lines inside
of functions, and for or while loops, blocks of code in if statements, etc.

[CardealRusso]

Didn't you just criticize  The constant use of "ends"  in a previous post?

Hello Rich.
Please allow me to explain what I'm referring to with some examples.

Python:

Code: [Select]

for a in range(3):
     for b in range(3):
         for c in range(3):
             for d in range(3):
                 println("Hello, World!")

Nim:

Code: [Select]

for a in 0..3:
   for b in 0..3:
     for c in 0..3:
       for d in 0..3:
         echo "Hello, World!"

Lua:

Code: [Select]

for a = 1, 3 do
   for b = 1, 3 do
     for c = 1, 3 do
       for d = 1, 3 do
         println("Hello, World!")
       end
     end
   end
end
But that's just a point I make, I don't mean that Lua is totally bad for that. In fact, it looks like it has the potential to be the best option, as you have to follow some basic rules of "script yes. not the compiled language" as well as a small binary.

Following these limitations, it seems to me that the second viable option would be QuickJS (which, by the way, the package present in the x64 repository is badly organized, since the libraries are not dependencies of the binaries, there should be "-bin"  with qjs only, "-libs" with libraries and "-tools" with qjsc)

[Rich]

Hi CardealRusso
I see. So rather than using braces or keywords, they
determine scope through indentation.

I prefer properly indented braces or keywords on their
own lines myself. I don't mind a little extra typing.

[mocore]

I'm arguing against making drastic changes to TCL's infrastructure because of potential stability issues. As it is
>(i.e., powered by shell scripts including some that are a decade old),<
TCL is stable, does absolutely everything I need it to do (and well), and has qualities that make it the only distro that I want to use and contribute to.

wrt above quote spesificly bold section i was reminded of a post on the web titled "More shell, less egg"
previously mentioned @ https://forum.tinycorelinux.net/index.php/topic,22762.msg142399.html

http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ || https://web.archive.org/web/20130209012208/http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/

Knuth wrote his program in WEB, a literate programming system of his own devising that used Pascal as its programming language.
His program used a clever, purpose-built data structure for keeping track of the words and frequency counts; and the article interleaved with it presented the program lucidly.
McIlroy’s review started with an appreciation of Knuth’s presentation and the literate programming technique in general.
He discussed the cleverness of the data structure and Knuth’s implementation,

pointed out a bug or two, and made suggestions as to how the article could be improved.

And then he calmly and clearly eviscerated the very foundation of Knuth’s program.

What people remember about his review is that McIlroy wrote a six-command shell pipeline
that was a complete (and bug-free) replacement for Knuth’s 10+ pages of Pascal.

[jazzbiker]

Hi mocore,

You propose the McIlroy's script as an example of the true formatting? Then my initial script is absolutely ok ;-)