Best Directory for Shared Scripts – Scripting Conventions

This is just a partial answer, since your question is fairly broad.

C++ defines an "execution character set" (in fact, two of them, a narrow and a wide one).

When your source file contains something like:

char s[] = "Hello";

Then the numeric byte value of the letters in the string literal are simply looked up according to the execution encoding. (The separate wide execution encoding applies to the numeric value assigned to wide character constants L'a'.)

All this happens as part of the initial reading of the source code file into the compilation process. Once inside, C++ characters are nothing more than bytes, with no attached semantics. (The type name char must be one of the most grievous misnomers in C-derived languages!)

There is a partial exception in C++11, where the literals u8"", u"" and U"" determine the resulting value of the string elements (i.e the resulting values are globally unambiguous and platform-independent), but that does not affect how the input source code is interpreted.

A good compiler should allow you to specify the source code encoding, so even if your friend on an EBCDIC machine sends you her program text, that shouldn't be a problem. GCC offers the following options:

• -finput-charset: input character set, i.e. how the source code file is encoded
• -fexec-charset: execution character set, i.e. how to encode string literals
• -fwide-exec-charset: wide execution character set, i.e. how to encode wide string literals

GCC uses iconv() for the conversions, so any encoding supported by iconv() can be used for those options.

I wrote previously about some opaque facilities provided by the C++ standard to handle text encodings.

Example: take the above code, char s[] = "Hello";. Suppose the source file is ASCII (i.e. the input encoding is ASCII). Then the compiler reads 99, and interprets it as c, and so on. When it comes to the literal, it reads 72, interprets it as H. Now it stores the byte value of H in the array which is determined by the execution encoding (again 72 if that is ASCII or UTF-8). When you write \xFF, the compiler reads 99 120 70 70, decodes it as \xFF, and writes 255 into the array.

It's fine.

Remember, it's your home directory; you can do anything you want in there. GNOME/KDE/whatever might complain if you go around deleting .config, but anything you do in your home directory will, by definition, only affect you. Adding some directories in .local is harmless.

Putting something in a dot directory will be mildly inconvenient, depending on your workflow. How much it will affect you depends on how you navigate the filesystem and how often you'll need to do it. If it was me, I'd make a regular directory to act as a root (probably call it local or apps) and use it that way, but that's personal preference.

Where you'll run into problems is that the system isn't set up to see your directory. You'll need to adjust PATH, MANPATH, INFOPATH, and LD_LIBRARY_PATH in your .bashrc (or whatever is appropriate for your shell). There will likely be other small "gotchas" as well.

I'm willing to be that there aren't many posts here about it because not many people need to do it. If it's a personal machine, there are few reasons not to use /usr/local. Everything's already set up for it in most distributions. If you're just installing a few apps, a lot of people make directories in /opt (like /opt/blender). Solaris does this when you install a package.

The only real use case for what you're describing is for developers or people who don't have root on their machine. Most people who don't have root just ask the admin to install a program for them - they probably wouldn't know how to compile a program anyway.