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
