Thanks dear Cmdte Alpha. It was indeed very informative. Thanks also to all who’re contributing, a lot to read here. — *a silent reader*.
On Sun, Mar 28, 2021 at 3:19 AM Cmdte Alpha Tigre Z <santiagopi...@gmail.com> wrote: > Oh dear, so much opposition here, isn't it? > > Please take your time and patience to read my whole message, > I put some titles so you can jump where you need to. > > 1. ANSWER TO SUSMITA/RAJIB > > Dear Susmita/Rajib, thanks for sharing your opinion. > It is very ambitious what you are proposing. > > 1.1. Introduction. > > Let's see: > > El vie, 26 mar 2021 a las 9:57, Susmita/Rajib > (<bkpsusmi...@gmail.com>) escribió: > > > > My illustrious Team Leaders and Movers of the Debian List, > > > > It has often been advised by experienced users of Debian for the > > learners to focus more on man pages. > > > > I shall seek a few examples before i place my questions. > > > > Let us for instance look at the man page of ls at: > > https://manpages.debian.org/buster/coreutils/ls.1.en.html > > This one looks very good, although there are more descriptive > manual pages out there for other packages; but, remember it is > about "ls", a very basic command so what else would we expect? > > > Then the following pages: > > https://medium.com/@isaac_70614/the-ls-command-and-wildcard-7fff5a4f7f24 > > > https://www.oreilly.com/library/view/learning-the-unix/1565923901/ch04s03.html > > https://www.tecmint.com/use-wildcards-to-match-filenames-in-linux/ > > https://www.cyberciti.biz/faq/grep-regular-expressions/ > > I see what you mean, you are talking about book-like writings that > talk in a straightforward and enjoyable way about a very specific subject. > Well, how-to's have a little common with this, but what are you proposing > is > very big. It would not be like Wikipedia, it would be like WikiHow > (https://www.wikihow.com/Main-Page) mixed with a blog. > > PS: Now that I think, the Debian Wiki [1] is a little like a Debian > Wikipedia, > perhaps it may suffice what you're looking for. > > > (...) > > Even the book that I have procured — The Linux Command Line, A > > Complete Introduction, by William Shotts — has all codes spread (or > > sprewn) across many pages and has to be brought together by exhaustive > > note taking. > > A book has to have its original sources. :) > > 1.2. Manual pages. > > > It is clearly noticed that wide applications of tricks with wildcards, > > regex and redirections aren't simply available in the man pages. > > Well, this is not completely true. Please look here > https://manpages.debian.org/buster/bash/bash.1.en.html at > section DEFINITIONS and section EXPANSION subsection > Pathname Expansion. > > These manual pages work with a little hierarchy, as I see, > so if you know how to use bash there is no need to specify > how to use ls with bash. [I didn't know that pathname expansion > is performed by bash]. > > 1.3. A very big documentation. > > > So is it then not necessary to have a repository of codes, with all > > permutations & combinations of possibilities with wildcards/regular > > expressions, redirections and so on, along with a wide variety of > > examples, be made available? Have the complete code reference hosted > > by the Debian server itself? > > Well, this is a little problematic: let's say we use three programs > on one complete command at a terminal, each one has 20 different options. > If we wrote every possible combination we would have > 1152918206075109375 possibilities [2], > not taking into account that some options could be specified multiple > times; > also, I didn't count the variable arguments (those that need to be defined > by the user, like a file name). > > Instead, you could have a list of tutorials for the most common > questions or uses. > You could organize them so well, that you could find what you want easily. > Of course it would be a very hard work, but certainly it would be very > appreciated. > > Aside that, a web search engine gives you closely the same results > searching > through the open internet for any information you want. > Blogs and other websites are a good source of information; at least > they are there. > A unified repository for such information is a little better but > it will not give you a big improvement. And as I said, such a > unified repository can not have all the information, but only the most > relevant one; > for everything else, you will need to search through the open internet > again. > > PS: again, the Debian Wiki is a good base to build upon such type of > documentation. > > 1.4. Unavailability of code and FOSS (or FLOSS). > > > Is not this general unavailability of those more complex codes — then > > becomes a de-facto non-disclosure of complex code lines — against the > > very Policy of Free and Open Source systems? > > Ok, ok... this is too much. No, there is not any unavailability of > complex code lines, just ignorance. Those complex lines must > be interpreted by the program, the program is free software with > "publicly viewable source"; so if you read the source, > you will understand everything. The complex code lines are just > a way to tell the program to do many tasks at a time or to specify > more precisely what and how things must be done. > > The only problem here, and not by Debian's failure, is that > not everyone is a programmer, or developer, or someone who > understands programming languages; also, more complex programs > are more difficult to understand, and not every programmer knows > every programming language. > > The program's command-line options are an interface to make the > programs more accessible to everyone else. > > On the other hand, be careful when you make such accusations > against something like the Debian Free Software Guidelines (if this was > what you meant). Saying that nothing in Debian is de-facto free software > is like saying that a speech is not public because it is spoken in English > and not everyone in the world understands English, or the same thing to > a free documentation. > > 1.5. What to learn. > > > Doesn't this non-disclosure encourage secrecy unless one attends a > > paid course to learn those tricks, permutations and combinations of > > wildcards/regular expressions and redirections involving internal and > > external commands? > > You don't need to learn those "tricks", you need to learn to learn. > If you know every option and its use, which you can get from the manuals, > you could figure out all those tricks; you just need to know what you want > every program to do. The real problem is what program to use to do > something on your computer; if you look close, those blog posts > sometimes starts with something to do or achieve and then introduce > the program. > > 1.6. A super safe system. > > > Shouldn't all codes and tricks involving them be available for > > everyone to use, but still have the system so robust that it can't be > > hacked? > > Emm, I'm not so sure what you are talking about here. > I think this is another topic: while secrets sometimes bring security, > openness can bring security too; the former uses the adversaries' > ignorance, while the latter uses testing, revision, assessment... > > As [someone else] said here, cryptography has something in common > with that sort of things. > > 1.7. Final words. > > > Best > > I wish you the best too. > > I hope you find my message useful. Thanks for sharing > your opinions and thoughts. I always thinks that education > should be accessible to everyone, and that documentation > would be a big step towards that goal. > > 1.8. Footnotes. > > [1] I don't know if the Debian Wiki is also a Debian package, > but it is very close to what you're looking for, I think. > > [2] I made this calculation with some math and Python > (easier, better than a calculator and was what I had at hand). > Here is the source code :) > > # Copyright (c) 2021 CmdteAlphaTigreZ > # License: BSD 3-clause > # plus "You can use http://directory.fsf.org/wiki/License:BSD_3Clause > # instead of the whole license when it is required to include the license. > # You can delete this clause for further redistributions." > # Description: too much combinations for 20 options > # for three programs on a command line. > > from math import factorial as f > > #def C(m, n): > # """A simple combination function.""" > # return f(m) // (f(m-n) * f(n)) > > def C(n): > # m = 20 Twenty different options. > return 2432902008176640000 // (f(20-n) * f(n)) > # I never tried this before, I didn't know that computers > # are so fast nor how Python works so I precomputed that big number. > > x = 0 # A coefficient for filtering repetitions of combinations. > # The coefficient is a little like a variation, but I'm not sure, > # so I calculated it manually. > r = 0 # Result > for i in range(20): > for j in range(20): > for k in range(20): > if (i<=j) and (j<=k): > if (i == j) and (j == k): > x = 1 > r += x * C(i) * C(j) * C(k) > if ((i==j) and not (j==k)) or ((i==k) and not (k==j)) > or ((j==k) and not (k==i)): > x = 3 > r += x * C(i) * C(j) * C(k) > if not (i==j) and not (j==k): > x = 6 > r += x * C(i) * C(j) * C(k) > print(r) > > #End > > 2. ANSWERS OR COMMENTS TO OTHERS > > 2.1 To Mr. Dan Ritter. > > El vie, 26 mar 2021 a las 10:43, Dan Ritter (<d...@randomstring.org>) > escribió: > > Susmita/Rajib wrote: > > > (...) > > No. This is exactly like asking: > > > > Is there a dictionary of all grammatically-correct English sentences? > > Right. > > > > (...) > > None of these things are being hidden from you. Not only did you > > find them, but you also have several different search engines > > that can produce reasonable results for you. > > Yes. > > > It turns out that big cities are often too complex for one > > person to understand everything that's going on at once, but if > > you build up your understanding one business, one building, one > > neighborhood at a time, you can not just learn what is happening > > but be able to decide what else you want to have happen, and > > understand your own reasons for choosing to build one > > neighborhood rather than another. > > I like this one: one step at a time you travel a long journey. > > 2.2. To Mr. George Shuklin. > > El vie, 26 mar 2021 a las 10:47, George Shuklin > (<george.shuk...@gmail.com>) escribió: > > But more docs are the most welcomed thing to have. > > Yes, documentation, especially good documentation is very important. > > 2.3. To Mr. Michael Grant. > > El vie, 26 mar 2021 a las 11:27, Michael Grant (<mgr...@grant.org>) > escribió: > > Unix Man pages have been around for many decades and each component > > usually (not always!) comes with a man page. There's no single > > company or organization that has any overarching responsility to make > > sure any individual man page is consistent with another. Furthermore, > > some things like some of the Gnu tools have documentation in a system > > called 'info' and there's often files distributed in /usr/share/docs > > and then some projects document things in web pages and in markdown > > files like readmes in git repositories. There just isn't a single > > point of documentation and I doubt you'll get everyone to > > double-document things by making man pages AND writing documentation > > in some global documentation repository. > > Yes, it is not easy to do a global documentation repository. I do agree > that it is better to leave some parts here and some there, and let > some people take care of this and some other of that. > Decentralized work, decentralized documentation. However, it would be > a good idea to have an organized list of external sources with URLs > pointing to websites (not single webpages). > > 2.4. To Mr. David Wright. > > El vie, 26 mar 2021 a las 11:46, David Wright > (<deb...@lionunicorn.co.uk>) escribió: > > On Fri 26 Mar 2021 at 19:11:24 (+0530), Susmita/Rajib wrote: > > > (...) > > This is why books become "well-thumbed", as their users turn back and > > forth to different sections. > > Yes, books are well done. > > > > (...) > > Correct. The man pages document fact that are specific to particular > > commands. Wildcards, regex and redirections are features of the shell > > that invokes them, and so are documented there. > > Yes, they're specific. The manual of one program won't repeat the manual > of every other program it depends on. > > > > (...) > > No. The way in which languages are generally described is by breaking > > them down into their component parts, and devising general rules for > > combining those parts. Fortunately the rules for computer languages > > are much simpler and more limited than those for natural languages. > > There is no better explanation than that, I totally agree. We always try > to make abstractions and generalizations so we can learn a few things > in order to do many different things. As you can see, my calculations > from above > involved many mathematical generalizations, I had to figure out some of > them. > If I had counted every combination one by one, I would never have finished. > > > However, the shell's rules are messy because of the way it has > > evolved. Most of us accept this because the advantages gained by > > having the features are greater than the disadvantages of dealing > > with the messiness and inconsistencies. > > I'm not sure, but I think some people are making "demessied" shells. > I thought that was the intention of zsh. Ejem, I really don't know. > > > So it's up to you, and all other users of the language, to build > > your own command lines out of those parts that you like, just as we > > combine our favoured words into sentences (possibly containing > > phrases and clauses). > > Yes, exactly. And it is a little easier, because, as Mr. Wright said, > computer languages are simpler. You just have to know what you can tell > the computer to do and then tell it to do those things it can do and that > you want it to do. > > > > (...) > > I'm not aware of any scripts in Debian linux that are not available > > for everyone to read. The only sense in which any of them are > > unavailable is that there are so many to search through for the > > hapax legomenon you seek. > > He, he. Yes. Sometimes you can get lost among lots of documentation. > It is like getting lost in a big library (the physical one). > > > > (...) > > There's no secrecy here, just incomplete knowledge. You can increase > > your knowledge through courses, or just by the experience that comes > > with frequent use. Progress tends to be much more rapid if you do this > > in the company of peers who can criticise each other. Along with your > > knowledge of the language comes knowing where to look for more. > > Totally right. I think the same. > > El vie, 26 mar 2021 a las 11:50, Greg Wooledge (<g...@wooledge.org>) > escribió: > > At no point, to the best of my knowledge, did Debian *ever* use a > > "Bourne-ish" shell as /bin/sh. I'm not even sure whether Debian *has* > > a Bourne-era compatible shell packaged, or ever did. The original > > Bourne shell is under a commercial copyright, and it's not common for > > people to re-implement it, because of its extremely limited feature set > > by today's standards. > > Excuse my limited knowledge. Is not "ash", the one that appears in > debian-installer, a Bourne-like shell? > > El vie, 26 mar 2021 a las 12:24, Greg Wooledge (<g...@wooledge.org>) > escribió: > > This is only partly true. "Wildcards" (shell matching patterns, > > traditionally known as "globs") are indeed implemented at the shell > > level, and are documented in the shell's manual. However, these globs > > were so well received that they were also implemented outside of the > > shell. There are two C library functions -- fnmatch(3) and glob(3) -- > > which describe the C library's implementation for pattern matching > > and filename expansions, respectively. > > (...) [and everything else from here to the end] > > Wow, I didn't know that. Thanks for sharing all that, Mr. Wooledge. > > El sáb, 27 mar 2021 a las 4:12, Susmita/Rajib > (<bkpsusmi...@gmail.com>) escribió: > > The day previously, someone anonymous wrote: > > > On Fri, Mar 26, 2021 at 07:11:24PM +0530, Susmita/Rajib wrote: > > > > (...) > > > > > > It is available online at the websites you enumerated. > > Yes, it is on the Web. > > > > > Have the complete code reference hosted > > > > by the Debian server itself? > > > > > > Some of those websites can be copied into Debian packages, and those > packages > > > can be added in the official Debian distributions. It's just that > nobody has > > > done the work so far. Volunteer? > > Not a bad idea, but it must be well done. Anyway, I would prefer that > information to be ported to the Debian Wiki. > > > > > Is not this general unavailability of those more complex codes — then > > > > becomes a de-facto non-disclosure of complex code lines — against the > > > > very Policy of Free and Open Source systems? > > > > > > The man pages are typically condense definitions, useful as reference > manuals, > > > not tutorials. All info is (should be) in the man pages, and the > tutorials > > > usually don't cover everything. Having man pages (and ultimately the > source > > > code of the software) available in the Debian distributions, is > exactly the > > > disclosure of all info. > > Correct. The manual pages are references. > > > > > (...) > > > It may be more efficient to pay a consultant. It's a choice to be made > by the > > > user. Tutorials are also usually more easy to read than man pages for > > > beginners. > > Yes, tutorials are very straightforward. They're made to be followed by > someone with very little knowledge about the topic. Of course, they take > too much words and explanation to do simple things, so... > > > > (...) Volunteer? > > Desperately as I would like to, there lies a problem, as I didn't > > follow an organised course to learn whatever little I know about > > computing. This web-like learning comes as a detriment in this regard. > > Yes, that's what I mentioned above that not everyone is a > programmer/developer. It happens. It would be good if everyone was > taught a little of programming at school, at least. Many people use > computers, so why not teach them how to do something with them aside > what others allow them with their applications? > > > But given the benefits that I have had because of this kind of > > learning, I would again choose this way. The only difference I would > > want would be to create my own course/syllabi and my own teachers. > > Yes, you see. Learning from the Web is not bad and has its benefits. > > > (...). Hurd unfortunately happened late. > > Yes, it did. It is a pitty, although Linux is not bad at all. > It still has a future however... when you get to see people "trying" to > EEE (Microsoft practice) Linux, it could take relevance to finish the Hurd. > I hope it never happens (EEE over Linux, Hurd is OK), though. > > > Let us please keep ourselves positive. Life on earth was also random. > > But this is what fractal, Self-similarity, can achieve. You have the > > entire earth as an example. Let us allow self-organisation to happen. > > > > We should take a step and then step back and let things self-organise. > > > > I believe in the Magic of life. I also often contemplate on whether we > > are actually simulated. People such as you, me, ..., we all are just > > islands of rationalism in a random ocean of reactive irrationalities. > > Though I would never have trouble terming our rationality as only as > > deep as a thin veneer that could easily be lost by a random accident, > > but that you, i, ..., exist as unique beings seeking continuity in our > > thoughts throughout our entire life speaks to me as a Test in a > > simulated environment to perfect our physical neural networks (or > > holographic computer programs). > > Sorry, but I have to say this: > > Ok, totally off-topic here, so I will do the same here. Yes, life looks > like magic, but how do you know it is random? In nature, I only see > not random things, it looks like everything was especially designed to be > that way. Things doesn't self-organise, there is a cause that produces > an effect. In the case of nature, it is done to keep organized itself > by its own mechanisms. In the case of community-driven projects, > if you throw a drop, you influence people; that people will try to make > progress on where you initially tried to. Not everything made by the human > ends right and self-organized. > > Em, and I don't think we live in a simulation. Dreams and nightmares > look like a simulation, real life don't. > > Finished. > > El sáb, 27 mar 2021 a las 12:12, Susmita/Rajib > (<bkpsusmi...@gmail.com>) escribió: > > On Fri, 26 Mar 2021 16:47:27 +0200, George Shuklin > > > (...) Yes, it has old pieces (all OSes have), (...) > > > > So do we need Artificial NeuNet to clean up Debian? Or write from > > scratch Hurd OS in a highly structured way? > > Don't try to do everything from scratch again. We just need to fix > manually > what is wrong and well done this time. Today, artificial inteligence > doesn't > look to know too much about organization (maybe I'm wrong). > > 3. END > > Thanks to everyone for all their contributions to this discussion. > Dear Susmita/Rajib, keep sharing those ideas. > > -- Christian.
