Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #235240 > unrolled thread
| Started by | Patrice Duroux <patrice.duroux@gmail.com> |
|---|---|
| First post | 2021-05-16 20:50 +0200 |
| Last post | 2021-05-27 21:20 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.debian.user
is the number of dot files a measure of the darkness of Linux?:-D Patrice Duroux <patrice.duroux@gmail.com> - 2021-05-16 20:50 +0200
Re: is the number of dot files a measure of the darkness of Linux?:-D Jude DaShiell <jdashiel@panix.com> - 2021-05-16 22:20 +0200
Re: is the number of dot files a measure of the darkness of Linux?:-D David Wright <deblis@lionunicorn.co.uk> - 2021-05-17 03:50 +0200
Re: Re: is the number of dot files a measure of the darkness of Linux?:-D Patrice Duroux <patrice.duroux@gmail.com> - 2021-05-27 21:20 +0200
| From | Patrice Duroux <patrice.duroux@gmail.com> |
|---|---|
| Date | 2021-05-16 20:50 +0200 |
| Subject | is the number of dot files a measure of the darkness of Linux?:-D |
| Message-ID | <CftZT-55d-1@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
Hi, 1. I was wondering about the presence of the /etc/.pwd.lock file on my system. For sure 'apt-file search /etc/.pwd.lock' is no help, but 'man -K .pwd.lock' do. I also searched the Debian user mailing list and found some relevant discussion on this file. Querying the Debian Code Search was also very interesting. Could there be a Debian web page to handle some sort of global search? I think this could be useful also for beginner not familiar with the diversity of Debian services, no? It will be for instance client to Debian Packages Search, Debian Manpages and Code Search, (also Debian Wiki?) that would provide at least links if topics are found in each of them. May be user would be able to select their targets. 2. After this I was curious about the overall content of all the packages on any dot files (including directories). For that I used the following to 2 commands: # the packages concerned apt-file --filter-origins Debian --regex search '/\.' | cut -d ':' -f 1 | uniq -c | sort -h # the top 10 of dot files apt-file --filter-origins Debian --regex search '/\.' | cut -d ':' -f 2 | grep -o '/\..*' | sort | uniq -c | sort -rh | head -10 They are very diverse and include some .git* ones. Are they always useful to provide? Is this something related to the Debian Policy? tracked by Debian Maintainer and/or in the scope of some QA tools? My opinion (as a sysadmin) is that I am not a big fan of dot files and moreover when they are not intended to be reserved (better restricted?) to the userland. Cheers, Patrice
[toc] | [next] | [standalone]
| From | Jude DaShiell <jdashiel@panix.com> |
|---|---|
| Date | 2021-05-16 22:20 +0200 |
| Subject | Re: is the number of dot files a measure of the darkness of Linux?:-D |
| Message-ID | <CfvoZ-62m-1@gated-at.bofh.it> |
| In reply to | #235240 |
If you were root and did ls -a /etc/.pwd.lock you'd probably find it. On Sun, 16 May 2021, Patrice Duroux wrote: > Hi, > > 1. I was wondering about the presence of the /etc/.pwd.lock file on my > system. > For sure 'apt-file search /etc/.pwd.lock' is no help, but 'man -K > .pwd.lock' do. > I also searched the Debian user mailing list and found some relevant > discussion on this file. > Querying the Debian Code Search was also very interesting. > > Could there be a Debian web page to handle some sort of global search? > I think this could be useful also for beginner not familiar with the > diversity of Debian services, no? > It will be for instance client to Debian Packages Search, Debian Manpages > and Code Search, (also Debian Wiki?) that would provide at least links if > topics are found in each of them. > May be user would be able to select their targets. > > 2. After this I was curious about the overall content of all the packages > on any dot files (including directories). For that I used the following to > 2 commands: > # the packages concerned > apt-file --filter-origins Debian --regex search '/\.' | cut -d ':' -f 1 | > uniq -c | sort -h > # the top 10 of dot files > apt-file --filter-origins Debian --regex search '/\.' | cut -d ':' -f 2 | > grep -o '/\..*' | sort | uniq -c | sort -rh | head -10 > > They are very diverse and include some .git* ones. Are they always useful > to provide? > Is this something related to the Debian Policy? tracked by Debian > Maintainer and/or in the scope of some QA tools? > > My opinion (as a sysadmin) is that I am not a big fan of dot files and > moreover when they are not intended to be reserved (better restricted?) to > the userland. > > Cheers, > Patrice >
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2021-05-17 03:50 +0200 |
| Message-ID | <CfAyl-yd-1@gated-at.bofh.it> |
| In reply to | #235240 |
On Sun 16 May 2021 at 20:30:03 (+0200), Patrice Duroux wrote: > > 2. After this I was curious about the overall content of all the packages > on any dot files (including directories). For that I used the following to > 2 commands: > # the packages concerned > apt-file --filter-origins Debian --regex search '/\.' | cut -d ':' -f 1 | > uniq -c | sort -h > # the top 10 of dot files > apt-file --filter-origins Debian --regex search '/\.' | cut -d ':' -f 2 | > grep -o '/\..*' | sort | uniq -c | sort -rh | head -10 The ones that concerned me (too strong, perhaps—just raised my eyebrows) were those in /etc. Modifying the command above, here's a "complete" list: $ apt-file --filter-origins Debian --regex search '/\.' | grep -v ': /usr' | grep -v ': /var' | grep -v '.placeholder$' | grep -v '.htaccess$' | grep -v '/skel/' elogind: /lib/elogind/system-shutdown/.keep_dir elogind: /lib/elogind/system-sleep/.keep_dir evilwm: /etc/xdg/.evilwmrc_simple fake: /etc/fake/.fakerc gridsite: /etc/gridsite/.gacl ncbi-data: /etc/ncbi/.ncbirc ncbi-data: /etc/ncbi/.nlmstmanrc netdata-core: /etc/netdata/.opt-out-from-anonymous-statistics pixelmed-apps: /etc/pixelmed/.com.pixelmed.display.DicomImageViewer.properties svxlink-server: /etc/svxlink/.procmailrc trafficserver: /etc/trafficserver/body_factory/default/.body_factory_info util-vserver: /etc/vservers/.defaults/cachebase util-vserver: /etc/vservers/.distributions/f7/apt/sources.list util-vserver: /etc/vservers/.distributions/fc1/apt/sources.list util-vserver: /etc/vservers/.distributions/fc2/apt/sources.list util-vserver: /etc/vservers/.distributions/fc3/apt/sources.list util-vserver: /etc/vservers/.distributions/fc4/apt/sources.list util-vserver: /etc/vservers/.distributions/fc5/apt/sources.list util-vserver: /etc/vservers/.distributions/fc6/apt/sources.list util-vserver: /etc/vservers/.distributions/rh9/apt/sources.list util-vserver: /etc/vservers/.distributions/suse91/apt/sources.list $ I eliminated .placeholder for obvious reasons, and I think .keep_dir performs the same function. I assume that /skel/ directories hold dotfiles to be installed elsewhere, like bash's ones, for example. I presume there's not much choice about .htaccess because this is a well-known control file. Reviewing my list from the earlier thread about .pwd.lock, I think .git/ probably has a similar constraint. As for /var and /usr—looking at my own system's /var, there are two: /var/cache/apparmor/…/.features and /var/spool/cron/atjobs/.SEQ and I might assume that .features avoids collisions with arbitrary program names, and .SEQ makes the directory appear empty when there are no jobs waiting to be done. Similarly, I'm guessing that /usr/share/…/<fontfamily>/.uuid is some unique version index that mustn't appear to be a fontname in that family's directory. (123 of 172 occurrences in /usr.) Eliminating one dot-directory, .git/, for a source package I unpacked, here are all the rest: /usr/lib/jvm/.java-1.11.0-openjdk-amd64.jinfo /usr/lib/python3/dist-packages/PyQt5/uic/widget-plugins/.noinit /usr/share/debian-reference/.htaccess /usr/share/dictionaries-common/site-elisp/.nosearch /usr/share/doc/debian-history/docs/.htaccess /usr/share/doc/python2.7/html/.buildinfo /usr/share/doc/python3.7/html/.buildinfo /usr/share/doc/texlive-doc/texlive/texlive-en/.dict.pws.gz /usr/share/emacs/26.1/lisp/gnus/.dir-locals.el /usr/share/emacs/site-lisp/dictionaries-common/.nosearch /usr/share/fvwm/default-config/.stalonetrayrc /usr/share/gnumeric/1.12.44/autoformat-templates/3D/.category /usr/share/gnumeric/1.12.44/autoformat-templates/Classical/.category /usr/share/gnumeric/1.12.44/autoformat-templates/Colourful/.category /usr/share/gnumeric/1.12.44/autoformat-templates/Financial/.category /usr/share/gnumeric/1.12.44/autoformat-templates/General/.category /usr/share/gnumeric/1.12.44/autoformat-templates/List/.category /usr/share/pandoc/data/docx/_rels/.rels /usr/share/pandoc/data/pptx/_rels/.rels /usr/share/texlive/texmf-dist/tex/latex/tools/.tex /usr/src/linux-headers-4.19.0-14-amd64/.config /usr/src/linux-headers-4.19.0-14-amd64/.kernelvariables /usr/src/linux-headers-4.19.0-16-amd64/.config /usr/src/linux-headers-4.19.0-16-amd64/.kernelvariables Going through just _that_ list and working out their justifications would not be profitable, I think. > They are very diverse and include some .git* ones. Are they always useful > to provide? > Is this something related to the Debian Policy? tracked by Debian > Maintainer and/or in the scope of some QA tools? > > My opinion (as a sysadmin) is that I am not a big fan of dot files and > moreover when they are not intended to be reserved (better restricted?) to > the userland. I'm not a fan of using them unnecessarily, particularly in /etc/, but I wouldn't want to restrict them where they bring about some benefit. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Patrice Duroux <patrice.duroux@gmail.com> |
|---|---|
| Date | 2021-05-27 21:20 +0200 |
| Subject | Re: Re: is the number of dot files a measure of the darkness of Linux?:-D |
| Message-ID | <CjtHY-3ar-5@gated-at.bofh.it> |
| In reply to | #235247 |
Hi, Thank you, David, for all the information. Scanning all these DOT files and checking what sort of documentation user/admin can easily get for them are steps in my process. I already started checking about the .SEQ file you cited for instance. Debian Code Search is very helpful. On the other side 'man -K' is not the best and a too naïve solution: it takes a lot of ressources and I did not figure out how to have just the list of pages and not display them. Is there a service similar to Code Search but for man pages? Best, Patrice
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web