Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #233551 > unrolled thread

Possible?! A Debian public repository for all complex code lines with examples and scripts?

Back to article view | Back to linux.debian.user

Contents

  Possible?! A Debian public repository for all complex code lines with  examples and scripts? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2021-03-26 15:00 +0100
    Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? <tomas@tuxteam.de> - 2021-03-26 15:20 +0100
      Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2021-03-26 16:00 +0100
    Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? George Shuklin <george.shuklin@gmail.com> - 2021-03-26 15:50 +0100
      Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Dan Ritter <dsr@randomstring.org> - 2021-03-26 16:00 +0100
        Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Greg Wooledge <greg@wooledge.org> - 2021-03-26 17:00 +0100
          Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Dan Ritter <dsr@randomstring.org> - 2021-03-26 18:50 +0100
        Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? George Shuklin <george.shuklin@gmail.com> - 2021-03-30 16:30 +0200
          Re: Possible?! A Debian public repository for all complex code  lines with examples and scripts? Charles Curley <charlescurley@charlescurley.com> - 2021-03-30 23:30 +0200
    Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Dan Ritter <dsr@randomstring.org> - 2021-03-26 15:50 +0100
    Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Michael Grant <mgrant@grant.org> - 2021-03-26 16:30 +0100
      Re: Possible?! A Debian public repository for all complex code  lineswith examples and scripts? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2021-03-27 09:20 +0100
        Re: Possible?! A Debian public repository for all complex code  lineswith examples and scripts? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2021-03-27 17:20 +0100
          Re: Possible?! A Debian public repository for all complex code  lineswith examples and scripts? "Susmita/Rajib" <bkpsusmitaa@gmail.com> - 2021-03-29 07:10 +0200
    Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? David Wright <deblis@lionunicorn.co.uk> - 2021-03-26 16:50 +0100
      Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Greg Wooledge <greg@wooledge.org> - 2021-03-26 17:30 +0100
    Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-28 05:20 +0200
    Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? "Andrew M.A. Cater" <amacater@einval.com> - 2021-03-28 15:50 +0200
      Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-29 00:50 +0200
      Re: Possible?! A Debian public repository for all complex code lines  with examples and scripts? Cmdte Alpha Tigre Z <santiagopinth@gmail.com> - 2021-03-29 00:50 +0200

#233551 — Possible?! A Debian public repository for all complex code lines with examples and scripts?

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

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/

Similarly, let us look at the man page of grep:
https://manpages.debian.org/buster/grep/grep.1.en.html

Also,  https://www.oreilly.com/library/view/grep-pocket-reference/9780596157005/
And then the following pages:
https://tldp.org/LDP/Bash-Beginners-Guide/html/sect_04_02.html
https://www.cyberciti.biz/faq/grep-regular-expressions/
https://www.thegeekstuff.com/2011/10/grep-or-and-not-operators/

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.

It is clearly noticed that wide applications of tricks with wildcards,
regex and redirections aren't simply available in the man pages.

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?

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?

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?

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?

Best

[toc] | [next] | [standalone]

#233553 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

[Multipart message — attachments visible in raw view] — view raw

On Fri, Mar 26, 2021 at 07:11:24PM +0530, Susmita/Rajib wrote:
> My illustrious Team Leaders and Movers of the Debian List,

[...]

> 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?

I think "all" is a very tall order: the whole manual would probably
crumble under its own weight :-)

If you are looking specifically for bash stuff, I could recommend
Greg Wooledge's BashGuide [1]. Greg is a regular in this list.

Cheers

[1] https://mywiki.wooledge.org/BashGuide/

 - tomás

[toc] | [prev] | [next] | [standalone]

#233556 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On 26/03/2021, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
...		...	[snipped]	...		...
>> 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?
>
> I think "all" is a very tall order: the whole manual would probably
> crumble under its own weight :-)
...		...	[snipped]	...		...

Hello, Mr. Tomas, nice to hear from you. It has been my pleasure knowing you.
Why should "it" crumble under its own weight, even metaphorically? If
wikipedia didn't, this too won't.
Page sizes could be restricted to one particular kind of application
for a specific application of an internal/external commands.
I would say: let the crowdsourcing begin. Then, like Wikipedia, the
educated crowd could take over the evolution of the pages.
Unless we want to keep things under 'Control', things always find
their own way to optimisation.
Best

[toc] | [prev] | [next] | [standalone]

#233554 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On 26/03/2021 15:41, Susmita/Rajib wrote:
>
> 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.
>
> It is clearly noticed that wide applications of tricks with wildcards,
> regex and redirections aren't simply available in the man pages.

You are stirring the water around pool of ancient snakes here.

There is a lot of outdated engineering in Debian, indeed.

Some software is frozen in time (enjoy you sh compatibility forever).

Some use old-school approach of garbage in garbage out (which makes 
error debugging a nightmare, if few of those 'garbage out' things 
stacked on each other).

There are a very magical defaults in core pieces (like `debian/rules` 
with magical `%:\n    dh $@`), and if you dig deep enough, you'll find a 
perl script with assumptions which are no longer completely valid, and 
some regex magic for things you've expected to be precisely parsed.

It's all there.

But it's all software. Debian can't change sh to be 'not sh'. And any 
changes in a build stack are touching vast amount of software with 
extremely complex use-cases, so it's almost impossible to 'replace'. You 
can 'add' a new one, but it just make xkcd #927.

Said all that, it's the most comprehensive operating system I saw. Yes, 
it has old pieces (all OSes have), but general cleanness of the goal and 
quality of the execution made it worth tolerating those outdated pieces.

But more docs are the most welcomed thing to have.

[toc] | [prev] | [next] | [standalone]

#233557 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

George Shuklin wrote: 
> But it's all software. Debian can't change sh to be 'not sh'. And any
> changes in a build stack are touching vast amount of software with extremely
> complex use-cases, so it's almost impossible to 'replace'. You can 'add' a
> new one, but it just make xkcd #927.

To be completely clear, Debian did change sh from Bourne-ish sh
to dash in Squeeze -- 2006 or so.

-dsr-

[toc] | [prev] | [next] | [standalone]

#233560 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On Fri, Mar 26, 2021 at 10:59:20AM -0400, Dan Ritter wrote:
> To be completely clear, Debian did change sh from Bourne-ish sh
> to dash in Squeeze -- 2006 or so.

Squeeze was released in 2011.

Debian originally used bash as /bin/sh (as most Linux distributions did,
back in those days).  At some point, there was a desire to speed up
various parts of the system, especially booting, by using a leaner shell
as /bin/sh -- and thus, Debian switched to using dash rather than bash,
although it retains the option for the admin to switch back to bash,
for systems that need it (due to poorly-written local or third-party
scripts).

The change from bash to dash as the default /bin/sh happened in squeeze,
according to <https://en.wikipedia.org/wiki/Almquist_shell>.

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.

[toc] | [prev] | [next] | [standalone]

#233564 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

Greg Wooledge wrote: 
> On Fri, Mar 26, 2021 at 10:59:20AM -0400, Dan Ritter wrote:
> > To be completely clear, Debian did change sh from Bourne-ish sh
> > to dash in Squeeze -- 2006 or so.
> 
> Squeeze was released in 2011.
... 
> The change from bash to dash as the default /bin/sh happened in squeeze,
> according to <https://en.wikipedia.org/wiki/Almquist_shell>.

Thank you for the corrections!

-dsr-

[toc] | [prev] | [next] | [standalone]

#233680 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On 26/03/2021 16:59, Dan Ritter wrote:
> George Shuklin wrote:
>> But it's all software. Debian can't change sh to be 'not sh'. And any
>> changes in a build stack are touching vast amount of software with extremely
>> complex use-cases, so it's almost impossible to 'replace'. You can 'add' a
>> new one, but it just make xkcd #927.
> To be completely clear, Debian did change sh from Bourne-ish sh
> to dash in Squeeze -- 2006 or so.
>
Thank you for clarification. My point was that 'sh' approach (including 
bash and dash) is really, really bad. Bash as a programming language is 
super tricky, with lots of landmines and almost no validation whatsoever 
for errors (there is a bit, but way less than expected from any modern 
system language).

I use a lot of Debian packaging in proprietary settings (sigh, I get 
paid for this), and it's love-hate relationship. I love that I can do 
whatever I need to; I hate those implicit magic rules and obscure 
environment variables.

[toc] | [prev] | [next] | [standalone]

#233692 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On Tue, 30 Mar 2021 17:20:11 +0300
George Shuklin <george.shuklin@gmail.com> wrote:

> My point was that 'sh' approach (including 
> bash and dash) is really, really bad. Bash as a programming language
> is super tricky, with lots of landmines and almost no validation
> whatsoever for errors (there is a bit, but way less than expected
> from any modern system language).

Something that may help this problem is shellcheck. If you use emacs,
you can have emacs check on the fly with package elpa-flycheck. I
expect other editors have similar support.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#233555 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

Susmita/Rajib wrote: 
> It is clearly noticed that wide applications of tricks with wildcards,
> regex and redirections aren't simply available in the man pages.
> 
> 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?

No. This is exactly like asking:

Is there a dictionary of all grammatically-correct English sentences?

> 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?

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.

> 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?

These goals are not in conflict with each other. It is like
saying that you would like your meal to have several courses and
also be vegetarian.

Let me employ an analogy: computers are cities connected by the
Internet. If you own one or more cities, you can control them to
the best of your ability. When you want to build things in your
cities, you can spend money to get other people's plans, many of
which come with complete working examples, or you can spend your
own effort on building and directing things. Some people give
away their plans and examples for free, because they think the
world is a better place when cities are run well.

In one city, the inhabitants speak lots of different languages.
You don't need to speak all these languages yourself, but the
more you know, the better instructions you can give.

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.


-dsr-

[toc] | [prev] | [next] | [standalone]

#233558 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

[Multipart message — attachments visible in raw view] — view raw

Unfortunately this is a bit of a mess but you need to understand the
history and politics here.

First off, Debian, as well as the other Unix and Linux distributions
are a collection of lots of different things from differnet places and
you get an operating system out of it all.  Something like Microsoft's
Windows or the old mainframe operating systems like DEC's VMS or the
various IBM operating systems, these operating systems were put out by
a company which had complete control over all aspects of the system
and it's documentation.  GNU/Linux meaning Debian, Ubuntu, RedHat, or
any of the hundred or so linux distrubtions just are not this way.

Unix and Linux distrubtions are a collection of many things from many
places.  The 'ls' man page you mention is part of the GNU utilities,
not written by the Debian project, nor is the shell like sh, csh,
bash, zsh etc..

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.

It is unfortunate that today, sometimes the best documentation is by
doing a web search and reading though things on sites like
stackexchange or perople's personal blogs.  I say unfortunate but it
works.

Don't get me wrong, it would be great if there was like a wikipedia
for all this but I doubt it will ever happen, and Debian is just one
of many different projects that consumes as well as produces things.

[toc] | [prev] | [next] | [standalone]

#233600 — Re: Possible?! A Debian public repository for all complex code lineswith examples and scripts?

Yesterday, I also received a few precious observations (even
counter-views are welcome) from two gifted individuals. The
observations are too deep to let vanish into oblivion.
However, it is incumbent upon me to protect the privacy of those
gifted individuals. So I will only post a part of our observations,
while protecting the privacy of those intellectuals.
This post is for those who like to be enriched by others' visions and
have no reservation between 'Us' and 'Then', for which my motherland
paid dearly with a 1000 years of invasions, oppressions, umpteen
genocide and collective enslavement that continues even today by
Macaulayan-ism [references: myriads, especially, A Case For India,
Will Durant, The History of India, as Told by Its Own Historians, by
Henry Miers Elliot, Breaking India, by Rajiv Malhotra, Unbreaking
India, by Sanjay Dixit]
Best.
Rajib



_____________________________________________
	Submission from a Gifted Individual
_____________________________________________

(intentionally via private email)

On Fri, Mar 26, 2021 at 07:11:24PM +0530, Susmita/Rajib wrote:
> 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?

It is available online at the websites you enumerated.

> 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?

> 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.

> 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?

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.

> Shouldn't all codes and tricks involving them be available for
> everyone to use,

As said, it's all available.

> but still have the system so robust that it can't be
> hacked?

That is an entirely different topic.
[...]




_____________________________________________
		My Submission
_____________________________________________

Please pardon my leap-frogging.
> ...           ...     [snipped]       ...             ... 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.

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.

Educational institutes are like a tightly knit cabal, driven by their
self-interests (greed?) to have  control/power over the collective
using knowledge as a bargaining tool. In India, we call these groups
the Left Liberal cabal (perhaps Woke in the US?), who are all the time
antithetical to national(sic,collective) interests, most likely because
of baboonistics (a term i coined to explain the default reactive
automated mammalian-limbic self-preservation drives, which the
ancients thought was 'ego'. The actions are much closer to egotism to
megalomania. Ego appears to be simply awareness, clouded by
self-preservation drives).

Dr. RMS and his tiny group was a happy accident that was the need of
the hour at the time.[...] much greater things
would have been achieved. Hurd unfortunately happened late.

...             ...     [snipped]       ...             ...
> (intentionally via private email)
...             ...     [snipped]       ...             ...
I am curious on the 'why' part.

Thank you for reaching out.

Please just note that these final barriers built up against the FSF
must fall for Debian to become truly an FSF. Presently, it is very
difficult to find really complex code lines easily, I have found. The
moderators at the forums.debian.net wield much power over users and
acts autocratically. If you protest, they would ban you, even if you
have never said anything negative to anyone.

And the Zero-sum Proprietary, Proprietary Game participants win hands
down as a result, taking  the greatest of human virtues down with
them.

I therefore took much time in framing my draft.
[...]




_____________________________________________
  Submission from another Gifted Individual
_____________________________________________

Unfortunately this is a bit of a mess but you need to understand the
history and politics here.

First off, Debian, as well as the other Unix and Linux distributions
are a collection of lots of different things from differnet places and
you get an operating system out of it all.  Something like Microsoft's
Windows or the old mainframe operating systems like DEC's VMS or the
various IBM operating systems, these operating systems were put out by
a company which had complete control over all aspects of the system
and it's documentation.  GNU/Linux meaning Debian, Ubuntu, RedHat, or
any of the hundred or so linux distrubtions just are not this way.

Unix and Linux distrubtions are a collection of many things from many
places.  The 'ls' man page you mention is part of the GNU utilities,
not written by the Debian project, nor is the shell like sh, csh,
bash, zsh etc..

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.

It is unfortunate that today, sometimes the best documentation is by
doing a web search and reading though things on sites like
stackexchange or perople's personal blogs.  I say unfortunate but it
works.

Don't get me wrong, it would be great if there was like a wikipedia
for all this but I doubt it will ever happen, and Debian is just one
of many different projects that consumes as well as produces things.
[...]




_____________________________________________
		My Submission
_____________________________________________

Yes, [...] I have been aware of the entire game unfolding since
2006, which is why I made a conscious choice to reject Doze in 2007.
And I shall still stick to that decision.

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).

Thanks [...]




_____________________________________________
  Submission from another Gifted Individual
_____________________________________________

[...]
Unless I misread your message (which I may have!) you would like to
get people to create some sort of Wikipedia like repository for a
single well written coordinated online documentation for all of
Unix/Linux.  At least, that’s how I read your message.  This goes back
way before 2006, it goes back to the mid 1960s.
(https://en.wikipedia.org/wiki/History_of_Unix).  Linux is an off
shoot of Unix, and I don’t mean just a little, it’s definitely a
flavour of Linux.  It’s a laudable idea.  I had to learn it all the
hard way by reading nearly ever single unix man page and reading some
of the source code.

But if I were starting out, I would suggest reading the man page for
whatever shell you were using, bash for instance.  And here again,
Linux doesn’t even have a “standard” shell!  The original shell was sh
and then lots of people used csh and bash is relatively recent.  But
starting with that and learning the basic tools also sometimes called
the bin utils, things in /bin, is a great base to start with.  I don’t
know the books that are out there.  I know there’s tons and tons of
books that have been written over the years.  Not a single one is
definitive or THE book.  The man pages is the closest you get to
something definitive.

[...] I hope I understood your query and hope I helped shed some light
on why things are the way they are.  Not saying it will be impossible
to change but it’s gonna be hard.  You probably would need a set of
monks to start collecting all things together and once you had some
excellent site, you might be able to get people to start using it.
Where to get a room of a hundred or so monks to dedicate their lives
to documenting this, I do not know.
[...]




_____________________________________________
		My Submission
_____________________________________________

[...]
You didn't get me wrong! Perhaps the threat of an uncharted road and
final outcome ahead of us overwhelms. The threat of social ignominy if
so much of money, investment and time fail to achieve something
tangible.

In these circumstances, it is better to step back and relax. Allow all
the doves play out their roles. Wait for the system of Hawk and Dove
to stabilise.

Everything constructive is hard, This is how life is. We didn't know
that Linux would happen. But it did. We should put in our inputs and
then step back and watch the game from a distance, at best gently
nudging it from time to time, if required.

Monks will discover themselves. This is what kids who aren't
overburdened by academic pressure do. Their Consciousness has still
not broken free to self-reflect. Their Neural Networks are more
focussed on solving problems unburdened by enormous information
overload.
[...]

[toc] | [prev] | [next] | [standalone]

#233610 — Re: Possible?! A Debian public repository for all complex code lineswith examples and scripts?

On Fri, 26 Mar 2021 16:47:27 +0200, George Shuklin
<george.shuklin@gmail.com> wrote:
...		...	[snipped]	...		...	[snipped]	...		...
>     Message-id: <[🔎] e7278f2e-45d8-4d4c-130d-6928fb435e5d@gmail.com>
>     In-reply-to: <[🔎]
> CAEG4cZXowSjn0S+s6_UMXHwko_L6EXm=AQHxaQz74hnTPC64VA@mail.gmail.com>
>     References: <[🔎]
> CAEG4cZXowSjn0S+s6_UMXHwko_L6EXm=AQHxaQz74hnTPC64VA@mail.gmail.com>
...		...	[snipped]	...		...	[snipped]	...		...
> Said all that, it's the most comprehensive operating system I saw.
> Yes, it has old pieces (all OSes have), but general cleanness of the
> goal and quality of the execution made it worth tolerating those
> outdated pieces[...]

So do we need Artificial NeuNet to clean up Debian? Or write from
scratch Hurd OS in a highly structured way?


> But more docs are the most welcomed thing to have[...]

Ah, at last a heart-warming line!

Thank you.

[toc] | [prev] | [next] | [standalone]

#233646 — Re: Possible?! A Debian public repository for all complex code lineswith examples and scripts?

I continue to feel sorry for Dr. Cmdte Alpha Tigre Z  and Dr. Andrew
M.A. Cater and their so much efforts. I would take full responsibility
for not being able to explain myself better, despite having the seed
within me for so many years. May be, in distant future, this
impediment will be gotten over with by a Neural Implant.

To try and bring them to see what i meant, i shall begin with a self-critique.

I am sorry to have used the word Wiki. It gave a different idea than
what was intended. Wiki is not only about wikipedia, I should've
explained.

I used wiki to signify a collaborative approach in stockpiling code
lines (wait, elaboration follows in Section 2). With minimal
explanation. Only lines of codes (more in Section 2).

The best possible method of learning appears to be minimal
explanation, but exhaustive implementation of code lines in a
console/terminal.

Let (!@#$%) represent the phrase without [quote] and [/quote].

[quote] with a list of all possible permutations combinations
(henceforth, abbreviated as PC) [of options, switches, RegEx, et al,]
of basic, single code lines. List. Only. Minimal explanation. The
console shall self-explain through output.[/quote]

Section 2
------------
So here our wiki would be one page for one Man Command
(internal/external). But radically different from Man Page. Minimal(or
zero) text (!@#$%)

Then a Upper Tier of wiki page having unique combination of two
commands (internal/external) with (!@#$%)

Then a still Upper Tier of wiki page having unique combination of
three commands (internal/external) with (!@#$%)

But we could stop at some Tier until further need for complexity arises.

Our books (or online bash scripting pages) i consider horrible in the
matter of wastage of time. For coding a different set of NeuNet are
developed for abstract multi-dimensional memory space, while our
intellect tries all sorts of possible PC of each sector of this memory
space(MS) and could redefine/reorganise/compress this MS. Books
address filling up this MS inefficiently. It also causes so much
wastage of paper for very little purpose.

IN order for Debian books to explain things to us, our wiki should
have specific line, section, page reference for any unique single line
of code.

Then books could be compressed to a minimal size. Wiki could be
expanded, if required.

I should have gone to abstractions and pictures in the first place,
with pics uploaded to a folder of my Drive for the purpose.

Hope I have been clearer this time.

Apologise, Dr. Cmdte Alpha Tigre Z  and Dr. Andrew M.A. Cater, for
compelling you to write so much, as I couldn't explain myself better
when I could, upon hindsight.

Best
Rajib

[toc] | [prev] | [next] | [standalone]

#233559 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On Fri 26 Mar 2021 at 19:11:24 (+0530), Susmita/Rajib wrote:
[ … ]
> 
> Even the book that I have procured — The Linux Command Line, A
> Complete Introduction, by William Shotts  — has all codes spread (or
> s[t]rewn) across many pages and has to be brought together by exhaustive
> note taking.

This is why books become "well-thumbed", as their users turn back and
forth to different sections.

> It is clearly noticed that wide applications of tricks with wildcards,
> regex and redirections aren't simply available in the man pages.

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.

> 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?

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¹.
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.

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).

> 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?

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.

> 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?

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.

> 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?

I assume that you're talking here about cryptography on open systems.
Much the same applies: the algorithms used by the programs are
well-known, and the secrecy is maintained by your not revealing the
keys. Robustness of the algorithms is supposed to be increased by
opening them up for scrutiny.

¹ For example, English has a "rule" for ordering adjectives which is
  learnt as part of growing up, but must seem mysterious to adult
  learners. Fortunately, most shell options don't have to be placed
  in an arbitrary fixed order.

  (The rule is opinion-size-age-shape-colour-origin-material-purpose.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#233562 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On Fri, Mar 26, 2021 at 10:46:23AM -0500, David Wright wrote:
> On Fri 26 Mar 2021 at 19:11:24 (+0530), Susmita/Rajib wrote:
> > It is clearly noticed that wide applications of tricks with wildcards,
> > regex and redirections aren't simply available in the man pages.

Nor should they be.  The man page should document how the program
functions, but should not tell you *every* possible way you can use
the program.

You seem to be focusing on the shell, so take a look at the bash man
page.  The man page for bash 5.1 as distributed in bullseye is almost
6400 lines long (using standard 80-character lines).

If you wanted to include a tutorial, or a programmer's guide book,
inside of this man page, it would be even larger.  And it's already
a tremendously large document.

People have written whole books on shell programming.  (Whether those
books are any good is a separate question.)  It's a huge topic.  It's not
something you can just tack on to the end of a man page.

> 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.

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.

The libc implementation is a little bit different from bash's
implementation, which in turn is a little bit different from dash's
implementation.  But the most basic features are the same.  Many programs
use fnmatch(3) or glob(3) or both, in order to maintain some level
of compatibility with how the shell does pattern matching or pathname
expansions.

Regular expressions have a completely different lineage.  They were
developed as part of computer science theory back in the 1960s, but
the ones we know and love were originally written in various Unix tools
such as ed(1), grep(1) and awk(1).  Back in the 1970s, each of these
tools had its own separate regular expression engine, so they all had
slightly different feature sets and syntax.

Around the 1990s, people decided it would be a lot more sensible to
share and standardize the regex engine across the various tools, so
that for example grep(1) and sed(1) would both support the same
expressions.  But some of the tools were a little too different from
each other for there to be just one regex engine.  Eventually a
compromise was reached, and Unix (POSIX) standardized on two regex
languages: BRE (Basic Regular Expressions) and ERE (Extended Regular
Expressions).

sed(1), grep(1), ed(1) and some other programs use BRE.  Or at least
they're supposed to.

awk(1), egrep(1) a.k.a. grep -E, and some other programs use ERE.

The engine that supports these two types of regular expression is
implemented in the C library, and is documented in regex(7) and regex(3).

Bash uses ERE, but only in one place: the =~ operator in the [[ command.
Bash uses the C library's implementation for this, rather than trying
to write its own engine.  Pretty much everything else that bash does
uses globs.

The GNU implementations of sed and grep, which are supposed to use
Basic Regular Expressions, actually use their own special regex engine
with their own special extensions.  The effect of this is that people
who only learned Linux, not Unix, often write scripts that use the GNU
extensions, and therefore do not work on any other Unix-type systems.
You'll want to watch out for that.

There are several other regular expression engines, which go beyond
the two flavors standardized by POSIX.  The most common of these is
undoubtedly perl's engine.  It implements a great number of extensions
to the regular expression language, and has been around for decades.
A mostly-compatible clone of it called PCRE (Perl-Compatible Regular
Expressions) was spun off and is implemented as a C library.  Some
programs use it.

Tcl has its own extended regex language, which it calls ARE (Advanced
Regular Expressions).  It's not as popular as perl's, but it does have
some of the same features.

I'm sure there are a bunch of other flavors floating around out there
as well.

[toc] | [prev] | [next] | [standalone]

#233619 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

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.

[toc] | [prev] | [next] | [standalone]

#233624 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

On Fri, Mar 26, 2021 at 07:11:24PM +0530, Susmita/Rajib wrote:
> My illustrious Team Leaders and Movers of the Debian List,
> 
We are all volunteers - the salutation is fine, but we're no more than
volunteers here.

> 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
> 
> 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/
> 
> Similarly, let us look at the man page of grep:
> https://manpages.debian.org/buster/grep/grep.1.en.html
> 
> Also,  https://www.oreilly.com/library/view/grep-pocket-reference/9780596157005/
> And then the following pages:
> https://tldp.org/LDP/Bash-Beginners-Guide/html/sect_04_02.html
> https://www.cyberciti.biz/faq/grep-regular-expressions/
> https://www.thegeekstuff.com/2011/10/grep-or-and-not-operators/
> 
> 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.
> 
> It is clearly noticed that wide applications of tricks with wildcards,
> regex and redirections aren't simply available in the man pages.
> 
As others have said: some of this is reading for yourself. Some of it is
noting common patterns in utilities: what works for one, works for another.
There are detailed books for a couple of these: patterns that work in awk 
and grep will often work in shell script regular expressions as well.

> 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?

A complete set of documention, comprehensive in every detail to answer
every question is not practical. Search engines are your friend here but
so is practical experience. Try things out with small examples - write your
own notes - in some sense, there is no substitute for doing these things, 
showing that you have done some trial and error, some homework, and then
asking for an explanation.
> 
> 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?
> 
Writing good documentation is hard and not always rewarding. Man pages / info
pages for GNU programs / taking simple examples and building your own
experience will all help. Do not try to do everything at once - pick a 
topic and read. Search the archives of the Debian mailing lists to find
the sorts of questions that get asked, spend a week with Wikipedia.

> 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?

Courses are one answer: asking good clear questions is another answer. 
Breaking issues into small pieces is helpful: explaining steps you've taken is
helpful. On a mailing list: asking one question - with a clear subject line -
sticking to one topic and waiting for answers for up to a couple of days
is always helpful. 

Have a look at the FAQ posted to this list once a month
for some ideas on how this list works. If something solves the problem / you 
find a good answer that might help someone else, adding something like 
subject line - [SOLVED] to the end of the mailing list thread will help the
next person find the answer more quickly.
> 
> 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?
> 
Human beings make mistakes: combinations of things combine to create an edge
case - a condition that couldn't have been seen in advance. Programs sometimes
have unexpected effects with some input or other. Lots of factors together
make vulnerabilities - sometimes those are exploited by people. The only 
robust, secure, unhackable system is one that is powered off, sealed in a 
metal safe inside a concrete block and dropped in the depths of the Pacific -
otherwise we can all only do our best.

> Best
> 

I hope this helps,

All the very best,

Andrew Cater

[toc] | [prev] | [next] | [standalone]

#233630 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

Hi.

El sáb, 27 mar 2021 a las 23:18, Cmdte Alpha Tigre Z
(<santiagopinth@gmail.com>) escribió:
> [many things]

Sorry, I forgot to finish writing my titles on my past post,
so if you need them, here are the lines where a different section
begin:

Line 344: 2.5. To Mr. Greg Wooledge.
Line 367: 2.6. To someone anonymous, forwarded by Susmita/Rajib.
Line 408: 2.7. To dear Susmita/Rajib.
PS to previous post: if you find my second last message as an offense,
I'm sorry, it was not my intention.

Additionally, in section 1.6, where it says [someone else], it is
Mr. David Wright.  I'm sorry, I forgot to replace that phrase.

Also, I noted in Debian's Code of Conduct, section 4, that it would be
good to include a summary for long posts. So here it is:

4. SUMMARY (for the whole thread, why not?)

4.1. Proposition.

Dear Susmita/Rajib is looking for a centralized source of tutorials
(or something alike) on Debian.  It is presented that tutorials are not included
in manual pages nor within some books.

4.1. Objections.

a) The proposed documentation would be very big (Cater, Ritter, Tomás,
Wooledge, me)(please read original message).
b) The requested information is already available on the Web (Cater, Grant,
Ritter, anonymous, me).
c) The manual pages and the source code have all the necessary information
and are definitive (Wright, two anonymous, me).
d) Debian has a lot of history and it is difficult to fix some inconveniences
(Shuklin, Wooledge).
e) FOSS is inherently decentralized and spreaded (Grant, maybe Wooledge).
f) The problem is ignorance (Ritter, Wright, maybe Cater, me).

4.2. Proposed solutions.

a) Some books are good for specific subjects (Cater, Tomás).
b) Modern search engines make the Web as a unified source of information
(Ritter, Cater, Susmita/Rajib, maybe Grant, me).
c) Learn one step at a time, get experience (Cater, Wright).
d) Learn the component parts and generalizations (Cater, Wright, me).
e) Get in contact with others that have the same learning objectives
(Wright).
f) Ask others for help with a subject (Cater, anonymous).
g) Look for a course (Cater, Wright).
h) The websites can be packaged and put into Debian (anonymous).
h) Build a very well organized compilation of common/relevant tutorials
or help build the Debian Wiki (me).

Please, if you want to enrich your knowledge, read the original sources...
They're marvelously good.

Have a good day.

-- 
Time zone: GMT-4
Months: Ene = Jan ; Abr = Apr ; Ago = Aug ; Dic = Dec

[toc] | [prev] | [next] | [standalone]

#233631 — Re: Possible?! A Debian public repository for all complex code lines with examples and scripts?

El dom, 28 mar 2021 a las 9:48, Andrew M.A. Cater
(<amacater@einval.com>) escribió:
> Have a look at the FAQ posted to this list once a month
> for some ideas on how this list works. If something solves the problem / you
> find a good answer that might help someone else, adding something like
> subject line - [SOLVED] to the end of the mailing list thread will help the
> next person find the answer more quickly.

Thanks for this.  I'll take that advice the next time when it concerns me.

El dom, 28 mar 2021 a las 1:57, Christian Nzhie
(<ngf.christian@gmail.com>) escribió:
> Thanks dear Cmdte Alpha.
> It was indeed very informative.

My pleasure.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web