Re: Re: is the number of dot files a measure of the darkness of Linux?:-D

[Patrice Duroux]

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

Re: is the number of dot files a measure of the darkness of Linux?:-D

[David Wright]

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

Re: is the number of dot files a measure of the darkness of Linux?:-D

[Jude DaShiell]

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
>

is the number of dot files a measure of the darkness of Linux?:-D

[Patrice Duroux]

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