Scripts that generate grub.cfg are located in /etc/grub.d/. You can edit them to specify classes. In my system (Debian) entries you ask about are added in /etc/grub.d/10_linux and /etc/grub.d/30_uefi-firmware.
Yeah, it's awful. But wait… Could one achieve this a simpler way? Assume we never heard about ifconfig deprecation (how many years ago? 15 or so?). Let's see at ifconfig output on my machine:
Seems that the cut part of pipeline is not needed because netmask is specified separately. The purpose of head part is likely to avoid printing IPv6 address, but this could be achieved by modifying a regular expression. So we get:
If you know a bit more about awk than only print command, you change this to
$ ifconfig ens33 | awk '/^\s*inet\s/{print $2}'
But now remember that ifconfig has been replaced with the ip command (author knows about it, he uses it in the article, but not in this example that must show how weird are "traditional" pipelines). It allows to use format that is easier to parse and that is more predictable. It is also easy to ask it not to print information that we don't need:
$ ip -brief -family inet address show dev ens33
ens33 UP 198.51.100.2/24
It has not only the advantage that we don't need to filter out any lines, but also that output format is unlikely to change in future versions of ip while ifconfig output is not so predictable. However we need to split a netmask:
$ ip -brief -family inet address show dev ens33 | awk '{ split($3, ip, "/"); print ip[1] }'
198.51.100.2
The same without awk, in plain shell:
$ ip -brief -family inet address show dev ens33 | while read _ _ ip _; do echo "${ip%/*}"; done
Is it better than using JSON output and jq? It depends. If you need to obtain IP address in unpredictable environment (i. e. in end-user system that you know nothing about), you cannot rely on jq because it is never installed by default. On your own system or system that you administer the choice is between learning awk and learning jq because both are quite complex. If you already know one, just use it.
Where is a place for the jc tool here? There's no. You don't need to parse ifconfig output, ifconfig is not even installed by default in most modern Linux distros. And jc has nothing common with UNIX philosophy because it is not a simple general purpose tool but an overcomplicated program with hardcoded parsers for texts, formats of which may vary breaking that parsers. Before parsing an output of command that is designed for better readability, you should ask yourself: how can I get the same information in parseable form? You almost always can.
The main thing you are doing wrong is reading howto articles in the web. Most of them are written by newbies who did the thing they describe for the first time, got something likely working and want to describe this for themselwes an for the other world. This does not mean they did everything right, and howtos usually contain numerous mistakes.
Better read official documentation. This will take longer time but you will understand what you do.
I don't know if Mint has GUI tools to configure samba server. I would better edit config file manually, it is more or less simple.
Are you really comfortable with ansible? The only reason to use it for your case is that you want to learn it. Time you spend writing a playbook and testing it will be much longer than installing everything manually on a single machine. And it will be impossible to reuse it if you consider moving to not debian based distro later.
If even file owner is not preserved (it is not always root, espetially in /var), you likely lost files' extanded attributes an, maybe, also permissions. Without them your system won't work normally.
Then, contents of these directories must be consistent with other ones. E. g. /var contains a package manager data about packages you installed. If you installed/removed anything after creating a backup, information about this will be lost.
If you created the backup while system was working, some files (espetially under /var, again) could be changed during that process, and this also makes such backup unusable. Every sysadmin knows that to create a database backup by copying files, dbms must be stopped.
In future, think about restoration before planning a backup and test if this possible immediately after it is done.
As the experience from other users in this thread, it seems not extremely rare to have an overgrown ~/.cache/ folder.
It is the first thread about overgrown ~/.cache directory I see since I use Linux (~16 years or so). But, as I wrote above, this sometimes (rarely) happens with log files and some other directories. Checking each of them is a waste of time, if not automated, checking just one or few of them makes sense only if you are testing some app and looking for files it creates.
Some users experienced accidential growth of /var/log. Some users experienced accidential growth of /var/cache. Some users experienced accidential growth of /var/lib. Some users experienced accidential growth of ~/.xsession-errors. Shall I continue?
Does every user need to begin his day checking all that places? No, he does not. It is waste of time. Such situations are extremely rare. If you are paranoid, check df to see if you have enough free space, and only if it unpredictably shrinked begin to ivestigate which directory has grown.
I don't remember if I ever cleaned it up. Probably a couple years ago when I moved my old HDD to new PC with freshly installed OS. It does not grow accidentally. Only in some very rare cases. As well as some other dirs under ~ and var. If it is a critical system, set up monitoring of free filesystem space. If not, you will notice if it becomes full (I can't remember when this happened to me last time, maybe ~15 years ago when some log file started to grow because of endless error messages).
You don't have to clean your ~/.cache every now and then. You have to figure out which program eats so much space there, ensure that it is not misconfigured and file a bugreport.
The notice has nothing to do with the license. You just write who holds the copyright. If you don't use code written by someone else, your name is enough.
Scripts that generate
grub.cfg
are located in/etc/grub.d/
. You can edit them to specify classes. In my system (Debian) entries you ask about are added in/etc/grub.d/10_linux
and/etc/grub.d/30_uefi-firmware
.