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
(<bkpsusmitaa@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 (<dsr@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.shuklin@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 (<mgrant@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
(<deblis@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 (<greg@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 (<greg@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
(<bkpsusmitaa@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
(<bkpsusmitaa@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.