It is not that easy. What is a compiler, what is an interpreted language?
For example python/perl are scripting languages, but are compiled into byte code and that is executed afterward.
Java is not a scripting language, but compiled and executed almost the same way.
C and C++ also first compiled into some kind of byte code and that will be again compiled into binary. What about Jython and CPython?
Java and python (and perl) never (cannot be) executed directly on the hardware, but in a VM (virtual machine). Although there were attempts to make real hardware to directly execute java byte code.
And what about javascript? And what about for example the c64 emulator, where the full hardware is emulated (including video, audio, cpu and other parts)?

Or for example what about embedded code, when you mix two or more languages in one system (file)?

Yes, you DO have it wrong. The interpreter is software, that interprets other and higher level software. Firmware is software. Your shell script is software. Any interpreted language is just software that has other software as a runtime requirement. A compiled language that does not compile to native (machine) code is also software that translates higher level software to a different form of software that has a runtime requirement. Generally a macro assembler is software that compiles a higher level language down to native code that may NOT have a runtime software requirement. It is still all software.

Not many C programs will run on bare hardware. Most depend on a loader and runtime C library, so are they interpreted?

If you say that scripting languages are any languages not compiled to native machine code, then Java is interpreted and Common Lisp is compiled, which may start some arguments.

If you say that languages that have separate compilation and runtime steps are compiled languages, then that includes Perl.

I think any definition is going to have some gray areas.

One thing that has always puzzled me is that people talk about shell scripts and perl scripts but python programs. Why?

Do they?

I'd say "Python scripts" to reference a plurality of .py files, or "Python application" to reference a piece of software made up of one or more scripts.

A script is explicitly a single file, but an application/program can be multiple files, and the latter are not common with Bash. (Not sure about Perl.)

Every language system – whether compiled or interpreted – begins its work by transforming the source code into some form of AST = Abstract-Syntax Tree. This is then processed to produce a set of low-level pseudo-instructions that actually drive the runtime of the interpreter. (Or, to produce object code, in a compiler.) The Python language actually saves this into a ".pyc" file.

The process of doing this preliminary step is so fast that we can simply ignore it.

Many languages, including compiled ones, use the "bytecode" approach. Even the original Apple ][, in its "Integer BASIC," did the same. (Steve Wozniak needed a "16-bit processor" but didn't have one, so he invented what he called "SWEET16.") A very lightweight program-loop can carry out a process that is represented in bytecode, which of course is very compact, and the "overhead" of that loop is inconsequential. Microsoft's various "compiled" languages use this approach frequently to produce smaller files.

Languages like Java and Adobe Flash use compilers which produce "bytecode" as their only output. The "JVM" runtime system used by Java is by now quite large, but the bytecode is quite small because a single bytecode instruction can invoke a very large amount of code within the JVM runtime.

All language systems today rely upon the presence of a binary dynamic library: "MSVCRTxx.DLL" in Windows, "glibc" in Linux/Unix, and many more. The compiled code is built to first load this library, then to make calls into it to do a great many things. This is generally considered preferable to "static linking," which produces much larger executables. (A single copy of the dynamic library is also shared by every process that is now using it, which translates to a considerable economy of RAM use.)

You seriously arguing that the PHP that powers Facebook isn't software?

All compilers reduce the source code to machine language. The difference between interpreted compilers and regular compilers is that the regular compiler saves its machine code output on a hard drive so that you don't have to compile the source again the next time you run the program while an interpreted compiler throws away the machine code after each run so that you have to compile the program every time that you run it.

No, not all compilers reduce to machine code. In fact, the ones that do are in the minority. Java, like p-code compilers, compiles source to an p-code that is then interpreted by a run time engine or interpreter. PERL does the same thing, and in version 4 and early 5 you could output the object code to a file. That file was not human readable, but would run on any platform with PERL installed. (It seems that was tricky to maintain, so they soon disabled that in version 5)

SOME compilers compile to machine code, and that reult then is NOT portable between platforms. V (v-lang) is a native code compiler, and some C compilers are as well. Early FORTRAN and COBOL compiled to machine code, but later engines may not. There are also compilers that compile source in one language (say MODULA-3) and output source in another language (perhaps C) to make it trivial to port the language engine to new platforms. (Such engine sources port and run quickly on any platform where a C compiler has been ported.)
There are special cases such as FORTH that run on a small (about 2K) core and compile to a psudo machine code. This makes it incredibly fast and portable to new hardware, and shockingly efficient and appropriate for embedded devices. It contains a compiler that compiles source code, but the compiler can be modified on the fly to change the nature of the output code! (Software magic! Smalltalk can do something similar at a higher level.)
Pure interpreted language never result in machine code, they result in a lower level source code that is executed by the interpreter runtime. Compilers input source in one form, and output code in a different form machine code being only one valid option.
Confusing the issue, is that there is nothing preventing someone from building a native code compiler for a pure interpreted language syntax! This we have compilers for BASIC and interpreters for C and Pascal.

Bottom line, if the code is instructions that result in execution by the hardware then it is software. Thus the term software applies to the source, interpreter, compiler, compiled source or object equally. This also describes both script source and the script interpreter or shell.

1 members found this post helpful.

You have it right in principle (with the caveats mentioned above) - except for the conclusion: it doesn't mean that a script isn't software.
Again, go to my post #5 and see how much of your installed software is at least partly scripted. You might be surprised.

On ESP8266 (and similar chips, like esp32) you can have microPython installed, that means the OS can directly run python code (and nothing else).

Python (not micropython) can store precompiled code next to the source files, those are the .pyc files.

And the interpreter creates machine code which it runs on the hardware.

The CPU will only run machine code. It will not run intermediate tables created by a multi-pass compiler. No matter what logic path a compiler takes it must ultimately present machine code to the CPU.

1 members found this post helpful.

the "engine" (or VM) will run the bytecode, you can say every bytecode will be "translated" to a function or call of a subroutine (within the engine). The real executed machine code is part of the engine, compiled elsewhere.

No, the runtime engine does not do a compile or translation on that object code. It interprets it. The only machine code presented to the CPU is that of the runtime engine interpreter. Please look it up, there are excellent descriptions of the p-code compilers, java and it's engines, that serve as excellent examples.

1 members found this post helpful.

Today, the use of bytecode techniques – even within "compiled EXEs" – has become quite commonplace because it is compact and because it works. The "bytecode interpreter" is basically a tiny loop and a big switch statement. There is no "overhead" associated with it.

The Java system uses bytecode exclusively, to provide cross-platform portability in what is nonetheless a "compiled" system: the Java source-code is evaluated once to produce a bytecode file that is thereafter run. The bytecode interpreter for this system has become quite large and complicated.

"Compile on the fly" systems like PHP work partly because "compiler technology is so damned fast now." It simply does not add any appreciable delay to execution.