SpaceCadet

Oh I wanted to say, “Do not use #!/bin/sh if you’re not writing bash-only scripts”

Hah, I was wondering if that was wat you actually meant. The double negation made my head spin a bit.

I have run into scripts that don’t work on Debian, because the author used bashisms but still specified /bin/sh as the interpreter.

The weird thing is that man bash still says:

When invoked as sh, bash enters posix mode after the startup files are read.
...
--posix
    Change  the  behavior  of bash where the default operation differs from the POSIX standard to 
    match the standard (posix mode). See SEE ALSO below for a reference to a document that details 
    how posix mode affects bash's behavior.

But if you create a file with a few well known bashisms, and a #!/bin/sh shebang, it runs the bashisms just fine.

Do not use #!/bin/sh if you’re not writing bash-only scripts

Actually #!/bin/sh is for bourne shell compatible scripts. Bash is a superset of the bourne shell, so anything that works in bourne should work in bash as well as in other bourne compatible shells, but not vice versa. Bash specific syntax is often referred to as a "bashism", because it's not compatible with other shells. So you should not use bashisms in scripts that start with #!/bin/sh.

The trouble is that it is very common for distros to links /bin/sh to /bin/bash, and it used to be that bash being called as /bin/sh would change its behavior so that bashisms would not work, but this doesn't appear to be the case anymore. The result is that people often write what they think are bourne shell scripts but they unintentionally sneak in bashisms... and then when those supposed "bourne shell" scripts get run on a non-bash bourne compatible shell, they fail.

Goodbye warranty then. Many manufacturers have already been doing that with chip tuning, which is also just a software modification. When you take your car in for service they read out the ECU to detect chip tuning, and your VIN gets flagged in their system if it has been modified. So if at some point in the future you make a warranty claim, you are SOL.

Then there's also the technical barriers they're putting up, locking them down so unauthorized software can't be flashed to them (much like Apple's iphone and ipad crap).

It still sucks that features are physically present in the car, but you have to pay to unlock them.

Yeah I'd say that sounds recent enough, but it's still possible that there's some obscure bios bug you're hitting.

You may also want to check if your bios is up-to-date.

My 5900x had some spontaneous crashes and reboots when I just got it, a bios update eventually resolved it. This was around the time zen3 was just out, and there were still quite a few bugs in AMD's AGESA library, which is included in the motherboard's bios.

Many motherboards still ship with an ancient bios, or just have been sitting on a shelf somewher for a very long time with an old bios. So if you have never touched your bios, check that first.

You're welcome!

Lots of bugs around screen blanking in plasma 6 it seems...

I also ran into this one: https://bugs.kde.org/show_bug.cgi?id=481308

and this one: https://bugs.kde.org/show_bug.cgi?id=483163

There’s still another odd behavior with ./ ! When extracted it will overwrite the permission/owner to the current directory source

Only if ./ itself is included in the tar file as a directory.

If my tar contains the following folder ./home/user/ and I extract it in my current home folder (which would be kinda stupid but It happens) this will overwrite the home folder

No it will not. It will extract your files to /home/user/home/user, so a nested home directory inside your home directory (yo dawg).

The man page section you quote is about absolute paths. That is, paths that start with a / without a leading dot. They indeed can be dangerous, but by default (GNU) tar strips absolute paths and will throw a warning like:

# tar -cf test.tar /etc/hosts
                   ^leading slash
tar: Removing leading `/' from member names

# tar -tvf test.tar
-rw-r--r-- root/root       184 2022-12-08 20:27 etc/hosts
                                               ^no leading slash

this kind of structure could actually be dangerous

citation needed

I mean, tarbombs exist, but not because of the leading ./ as far as I know and they're usually specifically crafted tar files to create harm, not something you accidentally create yourself while tarring stuff.

Has anyone a good explanation why the second way is bad practice? Or not recommended?

They're functionally the same. It's like the difference between mkdir somedir and mkdir ./somedir. The leading ./ is not necessary, so I guess you could consider it less clean, but I wouldn't lose any sleep over it.