Shell Script MIME Type

What does text/x-shellscript mean?

The text/x-shellscript media type labels a text payload as a shell script. Such a file contains commands for a command-line shell, commonly the POSIX sh language or a shell-specific dialect such as Bash, Zsh, or KornShell. POSIX defines a shell script simply as a file containing shell commands.¹

The usual filename extension is .sh, but the extension is a convention rather than part of the language. Executable scripts on Unix-like systems often have no extension at all. A script can also be passed directly to an interpreter, as in bash setup.sh or sh task.sh.

Is text/x-shellscript an official MIME type?

No. text/x-shellscript is not registered in IANA's media type registry, so it has no official registration template, standardized extension list, named inventor, or registration date.² The x- prefix survives from older conventions for nonstandard names. Current media type guidance no longer treats an x- prefix as a registration tree and recommends registration for generally useful, widely deployed types.³

The label is still used in real systems. Cloud-init recognizes text/x-shellscript for user-data scripts, and AWS documents it for shell-script parts in MIME multipart user data.⁴

Linux desktop MIME databases commonly use a different nonstandard name, application/x-shellscript. The freedesktop shared MIME database associates that name with *.sh, treats it as plain text and executable content, and detects several interpreter paths after #!.⁵ It does not list text/x-shellscript as an alias, so software can disagree about which label to emit.

If two systems must exchange these files, agree on the media type instead of assuming every MIME database uses the same spelling.

How do you identify a shell script?

Shell scripts do not have one fixed binary signature. They are text files, and the first line often names an interpreter with a shebang, for example:

#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' "Hello"

GNU Bash documents that #! at the beginning of the first line can tell the operating system which interpreter to use. It also notes that interpreter-line details vary between systems.⁶ This makes #! useful evidence, but not a universal magic number:

• A script can omit the shebang and still run when passed to sh or bash.
• #!/bin/sh and #!/usr/bin/env bash can select languages with different features.
• A .sh filename can contain ordinary text or even unrelated data.
• A valid shell script can have no extension.

For those reasons, this page does not claim a magic number. Check the filename, inspect the first line, and parse the file with the intended shell when accuracy matters.

How to open and check a .sh file

Any plain-text or source-code editor can open an .sh file. Visual Studio Code and similar editors can highlight shell syntax. Bash can read and execute a file supplied as its script argument.⁶

Before running an unfamiliar script:

1. Open it as text and inspect every command.
2. Confirm the interpreter named by the shebang is installed and appropriate.
3. Use the intended shell's syntax-check mode, such as bash -n script.sh, when applicable.
4. Review variables, quoting, redirects, downloads, privilege changes, and destructive commands.
5. Run it only with the permissions and isolation you are prepared to grant.

Browsers can generally display textual responses, but web behavior depends on the server's Content-Type and Content-Disposition headers. Browsers use the MIME type, not just the extension, to decide how to handle a resource.⁷ Serving a script as text does not make the browser execute shell commands.

Support in Poly

Poly recognizes .sh files as text/x-shellscript. You can:

• Open the script in a code-friendly text viewer with language-aware highlighting.
• Search its filename and readable contents using exact or semantic queries.
• Ask the Poly agent to read, explain, summarize, or reason about the source.

Poly does not execute the script while previewing, indexing, searching, or making it available to the agent. This keeps the experience focused on inspection and understanding. It also means Poly does not test whether commands succeed on a particular operating system, shell version, account, or environment.

Portability between sh, Bash, and other shells

The media type cannot tell you which shell language a file uses. The interpreter line and the script's syntax carry that information.

POSIX specifies the sh command language, while Bash documents behavior that changes when it is invoked as sh or placed in POSIX mode.⁸ A .sh extension alone therefore does not promise POSIX compatibility.

Converting a shell script

A shell script is already text, so most "conversion" tasks are really transformations:

• Save it as UTF-8 text when tools need a consistent encoding.
• Normalize line endings for the target operating system.
• Change the shebang only when the new interpreter can parse the script.
• Rewrite nonportable commands or shell-specific syntax when moving between shells.
• Use text/plain for generic display when the receiver has no agreed meaning for text/x-shellscript.

Renaming script.sh to script.txt changes how some applications classify it, but it does not remove commands or make unsafe content safe. Likewise, changing only the MIME label does not translate Bash syntax into POSIX sh.

text/x-shellscript in cloud-init

In cloud-init, this media type can be operational rather than merely descriptive. A user-data script beginning with #! is run once per instance during cloud-init's final stage.⁹ AWS also uses text/x-shellscript to distinguish shell-script blocks inside multipart user data.⁴

That context is important. A mail attachment or web response labeled text/x-shellscript should not automatically execute, while a cloud provisioning system may intentionally interpret the same label as instructions. Always evaluate the label together with the receiving application's documented behavior.