Reserved characters in file system object names

Describe the bug Any file system object whose name contains UNIX reserved characters, and most importantly the dollar sign (<kbd>$</kbd>), is clearly against POSIX best practices, and qualifies, IMHO, as a bug.

Expected behavior Comply to operating system best practices when naming file system objects.

Notes I am discovering SvelteKit… and this looks like a great piece of software. But using the dollar sign in file names really bugs me. Sorry.

Of all ASCII characters why choose a symbol that carries a very special meaning for all UNIX-flavoured operating systems. Other symbols are conventionally used to distinguish special file system objects from others (e.g. <kbd>.</kbd>, <kbd>_</kbd>, <kbd>~</kbd>, <kbd>%</kbd>, or <kbd>!</kbd>). Why not use one of these?

Most systems are UTF8 today, so one could even use such extended symbols (e.g. <kbd>ƶ</kbd> → ƶlayout.svelte) – though I would not recommend this.

I strongly encourage to strip/replace this dollar sign from all file names, ASAP.

[rmunn]

There are only two reserved characters in UNIX filenames, / and \0 (the null character). All others are fair game, including $. Space characters in filenames actually cause more problems for shell scripts than dollar signs, because once a dollar sign has made it into the parameters it won’t be shell-expanded, whereas spaces cause problems if your Bash script is written with $@ instead of "$@". The only thing you need to do is quote with single-quotes instead of double-quotes: "$layout" will be expanded to the value of the layout environment variable (or a blank string if there is none), whereas '$layout' will be the literal string $layout.

Speaking as someone who has used Linux since 1999, the dollar sign doesn’t bug me at all. But it’s worth considering whether to change to a different character. Once Svelte-Kit is officially released it will be far too late, but right now the @ character should be considered. It already has a sort-of de-facto usage in Javascript, and @lib as an alias for src/lib would make a lot of sense, etc.

But if $ is going to be replaced, do NOT use the tilde (~). It will cause just as many problems, or maybe even more, than $ would.

[marcastel]

‘Best practices’ is handwavy — can you elaborate on why $ is a problem?

Sorry for the late reply. OOO. I see that you have already adopted changes. Thanks for considering this 😃

For the record. David Wheeler elaborates on this. <kbd>$</kbd> is a meta character as are <kbd>*</kbd>, <kbd>?</kbd>, <kbd>:</kbd>, <kbd>[</kbd>, <kbd>]</kbd>, <kbd>"</kbd>, <kbd><</kbd>, <kbd>></kbd>, <kbd>|</kbd>, <kbd>(</kbd>, <kbd>)</kbd>, <kbd>{</kbd>, <kbd>}</kbd>, <kbd>&</kbd>, <kbd>'</kbd>, <kbd>!</kbd>, <kbd>\</kbd>, and <kbd>;</kbd>^(b). The C language primitives that handle exec()'d or shell’d^(a) commands will treat them specifically unless they are properly escaped. As for any programming language, using meta-characters should be done with caution. Very much like when using <kbd><</kbd> or <kbd>></kbd> in SGML-derived markup languages such as HTML. Basing a naming convention on the use of such meta-characters is, IMHO, a bad practice.

Further allowing meta-characters (and the dollar sign in particular) can lead to unsuspected exploits. The dollar sign orders the underlying system to expand or execute something. $USER will reveal your login name. ${.sh.*} will reveal details of your shell interpreter. $(rm -rf /) will wipe your disk. In the early days of the World Wide Web and the first CGI scripts, this was a common security issue. Exploits via query strings is still a major security concern today. I agree that, by design, Svelte will never expose this directly in production. Nonetheless adopting conventional best practices here would be my recommendation.

David Wheeler’s quote says it all:

Seek freedom and become captive of your desires, seek discipline and find your liberty.

^(a) Extra risks may arise with different handling by the platform’s specific C library implementation, or by additional functionality introduced by non-POSIX compliant shells, Bash, Fish, etc. The $@ vs "$@" debate fails in most scenarios beyond direct execution of simple shell scripts because of the backslash hell to properly escape a string which will be transmitted by multiple programs (e.g. ssh connections or GitHub actions).

^(b) Note that I have NOT included the <kbd>~</kbd> character. It is a meta character, ONLY for SOME shells and ONLY if it is used as the leading character followed by a <kbd>/</kbd>; in such cases it represents a users’ HOME directory. This character has commonly been used as a leading/trailing symbol to mark temporary files and is not subject to particular handling by C library functions.

BTW. Bash is GNU. Bash is not POSIX. Nor is Linux. Though they strive to be more and more. Younger generations tend to forget the very hard time we had in the 70s and 80s with the non-standardisation of UNIX. POSIX is what unified the myriad versions out there. Today’s UNIXes are all POSIX-compliant: AIX, HPUX, … even macOS. POSIX should be foundational to any best practices and conventions. So much so, that POSIX is now an international standard (ISO 9945).