In the case of interpreters, you get quite broad permissions through freedom 0. Freedom 0 is the freedom to run the program; this freedom is particularly unconstrained by the GPL. You can run and do whatever you want with the program, unless the output consists of parts of the program itself; copyleft only takes place when you convey/distribute something. Copyright law might see that differently, and might consider the act of running to require a license, but if it does so, you get one very liberal from the GPL.
Interpreter question in GPL FAQ
That means that you don't have to put your scripts under GPL when they run on an interpreter, e.g. bash; even when you make use of the many bash-specific constructs that make your script “depend” on in the sense that it won't run on any other shell.
This is particularly important, if you think of shar-style installers, i.e. shell-scripts that install some proprietary software that is data embedded inside a shell script and extracted by running it. If bash would “taint” that installer, all that software would have to be GPL'd. That's not established.
The whole thing is difficult, because copyright does not talk about technical things such as linking, subclassing, function calling or just running an interpreter which interprets builtins just like a C compiler calls functions — these are technical details that don't matter. Invoking a bash-specific builtin in a script from a copyright point of view is IMHO exactly the same dependency of two works as calling a function in a C library, or, for what's it's worth, using a C language element in a C program (or a GCC extension, which ties your program to GCC; and it does not help if later a clang developer clones it — the creative process of using a GCC feature is what creates the derivative work, not the existence of a clone, which, by ruling that APIs are copyrightable, is on its own a copyright violation). It might also be possible that the interpretation of the GPL that merely calling a function in a library is creating a derivative work actually depends on that interpretation of the Google vs. Oracle case (because a short reference to other works is fair use as minor citation).
That thing of interpreting a script is covered by freedom 0, the right to run a program. Running GCC translates your C source into some assembler or binary representation, and by giving you freedom 0, it can't be a copyright violation, regardless if copyright would say that using GCC extensions makes your program a derivative work of GCC: For that part, you have a license. Interpreting a script with an interpreter is just the same; that is the purpose of the interpreter.
What you do likely need is a permission to load other software into that interpreter together with your program, i.e. if you use some Python/PHP/Ruby framework stuff together with your code that makes use of the framework (and therefore by copyright is a derivative work), then you better hope that this framework is under LPGL — or your code is GPL compatible. The same applies to libraries that you interface to in your interpreter, e.g. using SWIG to bind to C libraries. You cannot use the right to run an interpreter to loophole that part.
One difficult part here might be if that C library is already a core part of the interpreter; e.g. if the interpreter offers regexps, and uses a library like PCRE to implement those (supposed that library is under GPL). The combination of interpreter and a hypothetical GPL'd libPCRE is ok, when the interpreter is GPL'd, too. The act of running the interpreter is freedom 0, i.e. unconstrained. Running an interpreter is the act of letting it interpret some script; which, in typical interpreters, is matching a lot of strings with regular expressions. That is accessing the libPCRE functionality just like linking to it, but through the core functionality of an interpreter, and therefore covered by the act of running.
That might not be legal, because the author of this GPL'd libPCRE did not give that permission of loopholing the GPL. The author of an interpreter, by defining the core parts of his interpreter, does give you a conscious permission to run it as such. On the other hand, the act of running the libPCRE is unconstrained, anyways, and the author of an interpreter like AWK should be free to use libraries for low-level stuff like regexps.
What is a core function of an interpreter? I would say something that does not require some syntactic element that reads like “include source file” or “import class”, and as such clearly refers to the imported element as not inherent part of the interpreter. If the interpreter has a scoping mechanism, accessing an already existing scope is not an import, adding a new scope by loading in the respective program is (same as dynamic linking). I.e. even if a core functionality of the interpreter gives you the ability to do C bindings on the fly, doing that does not loophole the GPL of that C libraries you can access; at some point in your bindings, you need to load that library, in which case you see that you now add another program to your program, and that's creating a derivative work.
Interpreter core functions are covered by freedom 0, so scripts under incompatible licenses as such are ok, regardless if they are legally a derivative work or not (they probably are).
Libraries in an interpretative language are just the same as compiled libraries, if you include them, you add them to your program, just as if you link to them.