Don't Name Files Like This On Any Linux Distro

[@mangopolice]

I love the freedom that Linux give us to absolutely break everything as we please.

[@itildude]

Yes, guardrails are boring.

[@dzhimy6266]

This is not operating system specific, any OS that implements a driver for the ext4 filesystem format lets you do this.

[@alexgghlebg5375]

@Power Ball! use vm when you try some code that have high risk like me with /proc and /etc/fstab (i have between 20 or 30 vm destroy actually)

[@mathgeniuszach]

with great power, comes great responsibility :P

[@deadeyegam]

@Power Ball! Lmao Even im a new arch user, and used to reinstall everytime something broke. I never bothered to fix it. Try using timeshift and btrfs instead to manage system snapshots if something breaks. Edit: my current record is 3 months without breaking an install. With timeshift and btrfs. That ended yesterday unfortunately. My dumbass thought it would be a good idea to give a linux vm the hard drive that had my root partition on it

[@insu_na]

I don't think these should be illegal in ext4, because ext4 is a general file system, not a file system meant to be operated only with bash (and shells with similar functionality).

[@LostieTrekieTechie]

Exactly, you can always put the file name itself inside of quotes.

[@viinisaari]

Maybe the default applications, eg. touch, should not let you name files like this then.

[@mikechappell4156]

@@viinisaari Programs shouldn't limit your choices. If the filesystem allows it, it is legal. The fact it is insane not withstanding. Using single quotes in the windows gui is quite common. These aren't filesystem problems, they are program issues, using "-" to designate arguments, DOS and VMS at least used to use "/" which is problematic because is used for separating directories on most *nix systems. The shell interprets "!" as the start of a history item and "$" as the start of a variable. None of these are problems with the program or filesystem but symptomatic of issues with the shell. You don't need to even use a POSIX shell though.

[@yuvalne]

+

[@terrydaktyllus1320]

@@viinisaari So somebody else has to put a "safety rail" for you just because you're not willing to learn how to use the OS correctly and "know the rules"?

[@anafabula]

I think con is a very nice filename. You should definitely have a file named con laying around, at least on a partition or usb-stick shared with Windows.

[@terrydaktyllus1320]

I share nothing with Windows - I rid myself of my Microsoft abuser when support for Windows 7 ended. Good riddance to bad rubbish.

[@HumanGamer]

@@terrydaktyllus1320 it's a joke. con is an invalid filename on windows

[@terrydaktyllus1320]

@@HumanGamer The reason stuff is written down is so you can go read it a few times if it needs to "sink in". You commented on "con" (of which I am aware) and "Windows". I replied to the Windows bit, not the con bit. Run along, sonny, and take that "high horse" with you.

[@linuxization4205]

@@terrydaktyllus1320 the windows part is also a part of the joke. You're not gonna be on the internet for very long if you keep taking everything literally.

[@terrydaktyllus1320]

@@linuxization4205 If you need to keep explaining the context of the joke to me then it clearly wasn't a very good one in the first place. That means "the joke is on you". You're welcome, sonny, you can thank me later - another problem solved for a self-entitled millennial.

[@fox2code]

Every charter for a filename is valid in ext4 except for the null byte, in fact it's possible to put terminal color codes in them and make "ls" a little bit more colorful.

[@brunoais]

I like that freedom!

[@mikechappell4156]

I believe everything but "/" and "\0" are legal, but putting escape sequences in file names is absolutely nuts. You shouldn't need to have to use various switches in "ls" to see actual filenames, if you do, change your naming convention.

[@Poldovico]

@@mikechappell4156 I'm pretty sure the slash is also valid. You just get a real bad headache when you want to do anything to that file again. EDIT: nope, no slash either

[@mikechappell4156]

@@Poldovico I found a thread indicating you could use slash; but it doesn't work for me on ext4 in VirtualBox. I'm not sure if that is a filesystem limitation or a kernel limitation though. (If you had a kernel that used : as the path separator, / might be legal.) I can't think of any non-*nix systems that can mount ext{,2,3,4} to test it and I'm not quite curious enough to start reviewing source code. I created a small filesystem and used hexedit to change a name to include a slash. ls gives me a bad message error, and fsck tells me the filename has an invalid character in it. So even if the standard allows it, it looks like the current implementation on Linux does not.

[@Poldovico]

@@mikechappell4156 I am unsure if by POSIX, it is specifically the slash or just whatever the path separator is to be disallowed. Might be the actual slash, though.

[@user-dc9zo7ek5j]

If you want to be evil: Name files non-latin languages so that the user can't type them out and to be forced to always copy the name, also add multiple spaces so that even if they copy the file they're forced to escape the name passing it to the command.

[@mercuriete]

If you start with double quotes, you don't need to escape. And tab (bash completion) works much better with double quotes.

[@someonestolemyname]

As a weeb living in the sinosphere I have to deal with them all the time, and I am still inept at the IMEs. I will just prefix them if I find them annoying.

[@shanent5793]

Why can't the user type out the names?

[@davidh.4944]

@@shanent5793 Lack of keyboard support. CJK characters in particular require an IME system of some kind, to convert keyboard sequences to the desired character. However, a simple workaround is to plop the filenames into an array and use their expanded values in commands. files=( * ) mv "${files[3]}" newname.haha

[@ricardog.s2505]

r/foundsatan

[@IllicitPrism]

I once borked my vim config so that it created an format named “~” in every directory I opened vim. Those were some scary rm commands…

[@wumwum42]

I remember having the same thing happen. Removed it via GUI file manager to be safe.

[@billeterk]

man find(1)

[@BaremetalFlesh]

​@@wumwum42 That's probably the only good way to do it

[@member5003]

Might as well name a file "$(rm - rf / & )", that'd be fun

[@nezu_cc]

the / is not a legal character

[@dekrain]

then ~ instead of /

[@Zandraccoon]

I like to put zero width spaces in my file names, so it looks like I have a bunch of files with the same name.

[@Poldovico]

If I remember rightly, by the UNIX spec a filename can be any null-terminated sequence of characters not containing a slash /. Fun when I accidentally created myself a filename containing a carriage return.

[@georgehelyar]

The most annoying thing is that these kinds of file names are usually created by mistake by getting the arguments wrong in some other command, like you go to use --out foo but miss a - and end up with a file called -out or whatever

[@CyberDruga]

Just one thing, the -- thingy is optional for the dev that made the command, but it is mandated If they want it to be POSIX compliant

[@liorean]

This is a problem with the shell and applications if you ask me. A consistent escaping method is the solution. The file names themselves should permit any bytesequence (no null termination of strings, the file name length should be stored separately, mostly because of overflow and underflow issues). Also, there should be a single uniform way to enter any Unicode character independent of keyboard layout, without actually knowing the name or number of the unicode entry, that works identically in terminal (or even before OS loading, in the bootloader) and in graphical settings, and you should also have ways to enter bytesequences that are not valid unicode. But that is a pipedream.

[@tejing2001]

You can specify absolutely anything by surrounding it in single quotes (apostrophes, same thing), then replacing each single quote in the filename with '\'' (singlequote, backslash, singlequote, singlequote). Most people don't realize you can start or end quoting mid-word, but it does work, and allows you to escape the single quotes with backslashes, and everything else with the single quotes. This is the method used by many programmatic "escape for shell" routines.

[@Omnifarious0]

I name my files various variants of $(rm -rf $(echo -ne '\057')) I remember a long time ago, before ls grew protections against this, someone having a filename with tons of vt100 escape sequences that would do all kinds of things when you did 'ls'. This has been a feature of Unix forever, and it's what allowed Linux/Unix to essentially seamlessly move to utf-8 encoded filenames. Every character except for '/' and '\0' has always been legal on Unix since the very beggining. The first Unix (and a few revisions thereafter) were limited to 14 character filenames. 14 characters plus 2 bytes to hold a 16-bit inode number so every directory entry was exactly 16 bytes long.

[@speed488]

Another thing nice about quotes and double-quotes is that you can concatenate them. This is pretty useful when you pipe stuff in an inline awk script where you need both quotes and double quotes in the script and also prevent expanding $ (column indexes). For example ["This is a concatenated "'$tring'] will be interpreted as [This is a concatenated $tring], but still a single argument.

[@N....]

On Windows, you normally can't have filenames that end with a dot or start/end with a space or contain consecutive dots. But if you use the long path syntax like "\\?\C:\Temp\ weird..file." you can create the file and watch as some programs handle it fine and others struggle to handle it. Windows File Explorer will display it but won't let you open it, for example. There's also the trouble with Unicode normalization, you can have two files with the same name but slightly different Unicode normalization.

[@chromacat248]

i’ve built a habit of putting ./ before every relative file path

[@knghtbrd]

Traditional UNIX has only one illegal filename character: The slash. Unicode throws some spanners into the works as you'd expect it would, naturally. But UNIX doesn't care. And there's always ways to access these things from the shell, if you know what you're looking at. Y'know where you really wind up with insane filenames? Using scripts that pull things like episode names for blu ray and DVD discs you've ripped for your media center. You'll encounter all kinds of characters that probably don't belong in filenames. You could learn to live in a GUI or you can learn to deal with these things in shells properly … but you will be dealing with them.

[@MarkParkTech]

I don't think they should be illegal, discouraged, sure, but not illegal. Mainly for legacy and compatibility with other systems reasons. Definitely don't make new files like that, but if you have to import files from another system that uses them as normal characters, you should be able to.

[@cheako91155]

We used to use the bell char, so terminals would make noise on an ls.

[@somethingelse401]

This video triggered me way more than it should have. I have stripped naming conventions and I'm pretty sure I just had me aneurysm looking at those file names

[@kennystrawnmusic]

I’ll never forget the time when I first started using Linux way back in 2008 (Ubuntu 8.04) and was dual-booting it with Windows because of driver issues, only to make the mistake of saving an OO document from my Linux partition to my Windows one with a colon in it. Perfectly valid from the Linux side of things, but when I went to open it on the Windows partition to print it, I was getting a boatload of errors that could only be fixed by rebooting back into the Ubuntu partition and renaming the file. Something to note if you ever intend to share files to people running different operating systems: this is all the more reason to avoid pushing the limits of legal Linux file names.

[@killistan]

I keep a "test" folder with weird filenames like these, to test my scripts against. Some of these files have control chars in their name... (bc I got burned by that once).

[@tjb0607]

i'd love to see a VM where the user account is renamed to something like that and just see how quickly things break

[@terrydaktyllus1320]

What stops you trying it yourself? Try stuff out and breaking it is how you learn, not by watching videos of someone else doing it.

[@FaranAiki]

@@terrydaktyllus1320 What stops you from thinking that not everyone is capable nor have the time to do that?

[@KSPAtlas]

I think the channel Enderman (or was it Flytech?) made a few videos where they named windows users things like con or ..., they broke hard

[@ribosomerocker]

happy new year. you explained the apostrophy/quotation thing really badly. it isnt really escaping; they're just strings. when you put something inside single or double quotes, it is usually interpreted as a string. every character inside the string is consumed until it comes across the matching closing quote, which is why "''" and '""' are valid strings. its just the shell decides to interpret some special characters within double quotes, but thats it.

[@therealb888]

Exactly my thoughts.

[@someonestolemyname]

Yeah and these behaviors are easy to understand if you know how arguments work, which is quite basic for a slightly complex shell scripting. Technically all datatypes in shells are strings, the difference is just how they are interpreted. Like how if I want to make a file that has a newline in it to break stuff I can just do 'touch $' ' ', is replaced with newline even though it is in single quotes because I told the shell to interpret it. And sane people wouldn't think of doing it because it will be a hassle to parse with ls.

[@davidh.4944]

No, that absolutely is escaping, explicitly so. The shell uses three types of escape sequence: The backslash escapes one single character following it. It only really works (or is needed) on a few otherwise special characters, however. The double quote escapes every character after it until it hits another double quote, while allowing a handful of special characters to still be parsed (particularly the backslash and $). The single quote escapes _every_ character after it until the next single quote, with no exceptions. Note that the quotes act more like toggles than containers. They are simply processed left to right. Escape on, escape off, Daniel-san. (Exception: some nested constructs like $(...) create their own parsing contexts, and any quotes inside them are treated separately from the line outside it.) bash and some other shells, also have $'...', which acts like single quotes, but any special backslash pattern inside it is instead expanded into the actual character it represents. See "man bash > QUOTING" for a more detailed explanation.

[@BrodieRobertson]

To treat it as a string it effectively has to escape certain characters within that string bubble. I know this isn't the technical explanation but it does the job at getting the point across.

[@billeterk]

@@davidh.4944 I agree with the ideas here but escaping is still the wrong terminology. It’s man bash - quoting, not escaping. There’s literal quoting, quoting with interpolation and escaping, and they’re all distinct.

[@xzaratulx]

didnt expect that as a last topic of the year 😊

[@triffid0hunter]

POSIX says all characters except null and forward slash are legal in filenames - meaning that yes, you can have filenames with newlines and unicode in them, and no this isn't a decision from the Linux or EXT4 teams. Pointing out that common shell metacharacters are legal in filenames may not be as daft as you think - shells operate at a much higher level than filesystems and there's no restrictions on which characters they use as metacharacters, so it would actually be dumber if the VFS layer had to trawl all known shells for "problematic" characters and forbid them… Funnily enough, the seemingly innocuous : (colon) is legal in Linux filenames but not windows - so if you ever want to give windows-using people a massive headache, just commit a file to your git repo with a colon in its name (or just have two files with different capitalisation) :P

[@donaldmickunas8552]

Yes, I’ve dealt with weird file names. Usually, I try surrounding them with quotes first. That usually works. If it is a file I’ve downloaded, I change the name asap.

[@NoNameBAM]

This stuff is exactly why lots of escapes exist. I say: Name files like this because tools should work with them anyway, and if they don't work they need fixing.

[@ianliu88]

Most of these problems are really bash escaping issues. Once you understand that in bash "foo", 'foo' and foo are three ways of writing the string foo, lots of the problems will go away

[@jonnypeace2810]

When ever i try and help people with scripts, i've fell victim of applying my own file naming standards, but the realisation is.... some people don't have the same standards.

[@finefindus]

I actually run into the issue with files with $ in them, android apps use them for some compiled class names. Took me way to long to figure out why the wrong file was opening

[@PizzaLovingNerd]

2:35 RMS Feet

[@MyAmazingUsername]

Made me laugh. Should have said "RMS Feet Food" for more accuracy.

[@vk3fbab]

I think these limits are combinations of the filesystem support and the shell being used. Agree with the sentiment that one shouldn't create names that ruin other people's (or your own) days. That said I learnt some new things esp using double hyphen.

[@wisnoskij]

Ya, I have seen the (double dash) used before when chaining command line arguments. Rust is setup to compile and run at the same time in general for testing. So you cargo run -- (the compiled program's cl imput) Note: apareantlly double dash enclosing test is how --YT does strikeout--

[@harrygenderson6847]

--That's pretty cool--

[@MasterHigure]

A previous workplace of mine had an 'æ' in its name, and the shared OneDrive folder where we had all the different project files of course had that character in it, along with spaces and a dash (giving us a folder name like "OneDrive - Workplæce"). It was the source of several issues, but the funniest one was that R sometimes interpreted the 'æ' as an 'f' in scripts, and thus obviously couldn't find the files it was supposed to find (the error message was basically "Couldn't open 'OneDrive - Workplfce/project_name/library', no such file or directory").

[@markopetrovic367]

Weird filenames definitely make problems with shell, but I don't think ext4 should make them illegal at the filesystem level. Someone may find a fair use for them for something in a very specific situation. Also Linux is mostly POSIX compilant and regarding filenames POSIX says in chapter 3, part 3.169 that any character except the slash character and the null byte may be used in filename. That includes even characters with ASCII values lesser than 32, things like Carriage Return, Shift In, Shift Out, etc. Even NTFS supports that at the filesystem level and it is possible to create such filenames on NTFS partition from Linux. If anywhere, restrictions regarding filenames in Linux should be placed in file managers like in Windows since normal users shouldn't need Carriage Return in their filename.

[@myria2834]

you didn't mention it as a safe option, but I regularly use (parentheses) and [brackets] in file names, to make certain notation more visible, and it's completely safe as far as I can tell.

[@CandyCaneChris]

My favorite filename is Linebreak.

[@ivanv754]

All those poor souls who have Ed Sheeran’s albums neatly organized in folders by name.

[@terrydaktyllus1320]

Do you mean "the deaf" or "the lacking in any musical taste"?

[@dzhimy6266]

The only invalid characters are a null char and the directory delimiter, any combination, even emojis, broken text encoding and raw binary data is a valid file name so long as it doesn’t contain a null char or the directory delimiter.

[@danielberglv259]

This just shows a conflict between a shell and a filesystem. Can't see why the filesystem should make considerations for various programs, when deciding how file names should look. No mater what rules you set, you could potentially find a program that conflicts with it. A filesystem will make rules to avoid conflicts within it's own domain. How it's used by a program, is up to the program or the user of said program. Not really seeing a problem here.

[@ulfnic]

*edit*This was clarified though I want to highlight it because it surprised me when I learned about it...*/edit* -- isn't a special shell feature, it's up to the program to read it and decide to honor it. Virtually all popular programs do and it's built into shared libraries but things like hobbiest shell scripts often don't read params using `getopts` or bother to build in -- support. So it's not an absolute guarantee -- will always work.

[@BrodieRobertson]

I don't believe I said it was a shell feature, I'm pretty sure I said it was up to the application

[@ulfnic]

I could have worded that better. I'll add an edit, thank you.

[@harrygenderson6847]

Question: can you craft 'malicious' filenames? For example, a file which, when accessed through a bash script, instead goes and removes ~/.config?

[@SolomonUcko]

It depends on how exactly it's used. For example, using a variable without quotation marks will invoke whitespace-based argument splitting in shells such as bash.

[@billeterk]

I seem to recall a “compression” program in the 90s that would store data in file names to get around user quotas :-)

[@drstefankrank]

If you have some strange filenames you can't get your head of, try the "detox" command which renames all that crap to standard characters.

[@arimcbrown]

happy new year Brodie

[@edmund3504]

i only use emoji in file names 😃👍

[@user-dc9zo7ek5j]

Common javascript programmer stuff.

[@herkulessi]

As far as I know, the only explicitly disallowed Characters in filenames are '\0' and '/'. I am pretty sure even NEWLINES are allowed, or BELLS or any of that fun stuff... SHell scripts with stuff like that is.... Fun. Lemme tell you.

[@dfs-comedy]

I think the takeaway here is not to avoid these filenames, but rather to avoid programming in shell where you have untrusted filenames. In any non-shell languages, "weird" filenames are not a problem at all. If you have to traverse a directory (that you don't completely trust) with find / xargs, be sure to use -print0 with find and -0 with xargs.

[@0x007A]

It is an incompetent craftsman / craftswoman who blames their tools.

[@tunichtgut5285]

If all fails you can use the Inode numer. Since "rm" doesn't accept Inode number it is a little bit complicated: do a "ls -i" and then a " find . -maxdepth 1 -inum xxxxx -delete".

[@mikechappell4156]

That is one ugly delete command.

[@danielrhouck]

Pretty sure these file names were allowed because they didnʼt want to come up with complicated rules or anything. The rules are really simple: a filename can have any bytes in any order, except for a slash and a NUL. This means not just spaces but also newlines, tabs, backspace, the BEL character, emoji, `watch?v=utrzbD_JlTM`, asterisk, tilde, backslash, etc. are all allowed, but also nobody designing the filesystem had to figure out how to disallow them or whether they should be.

[@AlexandreJasmin]

Your typical Unix file system will allow for almost any sequence of bytes in a file name as long as it's not ".", "..", or include a NUL byte "\0" or slash "/". Notably, bytes sequence that don't respect your system encoding like invalid utf-8 surogate pairs are "valid" at the filesystem level. Some "foreign" file systems are more restrictive, NTFS use UTF-16 encoding instead of aribitrary byte sequences for instance.

[@ultradude5410]

And you didn't even mention non-printing or control characters in filenames? You can name a file and it accepts it. You can have a newline in a filename. You can have tabs in filenames. You can have *vertical* tabs in filenames. IIRC the only illegal character is a forward slash.

[@remrevo3944]

Well, paths in linux don't even have to be valid UTF-8, so that's only the beginning. IIRC the only things you can't use are "/", ":" and "\0".

[@StarkRG]

name a file "-rf --no-preserve-root *" and put it in someone's root. I think noob-friendly distros might lock out the "no-preserve-root" option (Pop_OS! seems to, at least), but it could certainly be an issue on a server.

[@Aeduo]

I'm guessing they didn't want to bake-in behaviors that depend on specific shells, that someone might not even be using.

[@Artoooooor]

-log: this is not a problem. FS allows given file name and the tool allows to use it. If a name can be mistaken with parameter or variable there is just a way to escape them.

[@MH_VOID]

newlines in file names are particularly annoying to deal with. I make sure to delimit with a null byte when dealing with directories including files with newlines in the name, but it's annoying to do so sometimes

[@rinumu2736]

You can use newlines in filenames and break scripts which use them to separate data in pipes 😈

[@mikechappell4156]

I know a few commands deal with this. "xargs" has -0 and -print0 to help deal with this mess, but I imagine most tools will break with embedded new lines.

[@denisde4ev]

also `cat -- "-"` will not print your file named "-". cat will read input as no arguments are provided. because `--` means end of options and `-` is short for input (for some reason not considered an option). I cant find a reason why but GNU implementation of touch: `touch -- -` also does not work, no error but not file either, however using `busybox touch -- -` does create the file `-`. Also some programs do not support `--` as end of options. so its better to use relative path `./-` and using`--` as end of opts is pointless

[@kxuydhj]

certain modified letters like "ë" and "å" are a nightmare because of character encoding. in particular, one of those filenames ended up causing Ark (kde archive tool) to tell me the tarball containing my backup was corrupted. using tar from the cli worked like a charm. they also mess up libreoffice on tumbleweed if i recall correctly and certain applications just have their own way of treating them causing even more creative issues when those applications intersect. not to mention the way filesystems seem to treat them. and that's why i now only use lowercase letters, numbers and underscores for filenames.

[@michaelheimbrand5424]

A crazy fact is how popular it is to have the pipe character "|" in the title of web pages. I guess it´s a design thing. So what you might think, it´s not a file name. OK. Now think about how common it is for people to drag from the address bar to the desktop to create a desktop shortcut to a web page. Congratulations, now you have a file with "|" in it´s file name. I had a lot of "fun" with file copy errors on my wife´s homedir on our server. Look at the web page titles and you may be surprised how common it is with that bloody pipe-symbol in the title.

[@etopowertwon]

LMAO. No. You can pry dashes(including at the start) and spaces from my cold dead hands. It's enough pain I can't use "?" on windows. I honestly thought the video would be about `echo hi >"$(echo -e "a b")"` or names that are not even represented by unicode.

[@nezu_cc]

unpopular opinion: I think that all characters except the "/" and "\" should be valid. And if an application, shell, or the user should know how to handle them. I hate the idea of putting arbitrary restrictions on things just because someone might get confused.

[@kreuner11]

They can still be removed by doing it with a programming language

[@billeterk]

Or find, or rm or….

[@entelin]

There are unfortunately lots annoying file naming stuff across all os's. NTFS supports longer paths and names than I think basically all the windows tools do, so you can get in situations where the only way to delete certain files is with (some) command-line tools. Mac is way over permissive with naming which causes interoperability problems, and just generally mac users seem to like to write a whole thesis as their filename which is incredibly annoying. Unfortunately, you cant really change existing shell languages, or filesystems to help with this issue as it would break all sorts of stuff. That said, there's no way that any of the shells we have represent something akin to optimal shell design, so making a new one from scratch would be the best bet. Would be cool for example if it was less whacky and more modern from a programming perspective, an option for precompiling would be interesting and would have some use cases.

[@terrydaktyllus1320]

NTFS? Never heard of it.

[@brylozketrzyn]

In modern windows you can enable long path file support. But beware - some apps may not be compiled with proper string support of file path.

[@Poldovico]

Mac is as permissive as Linux is, because they both follow the UNIX specification with regards to file names. Namely, a file name can be any string. Emojis, tabs, newlines, carriage returns... The only thing that can't be part of a filename is the NULL character, because it is the string terminator (or alternatively, you could say it is the last character of every filename). EDIT: no slashes either

[@ivesennightfall6779]

pretty sure the reason ext4 allows it is for posix compliance. almost disappointed you didn't put a BEL into one of the filenames though, or a newline

[@BrodieRobertson]

I could spend all day making dumb file names

[@Haskellerz]

Naming all my files -rf now

[@bettercalldelta]

You can even add ANSI color codes to the file name and ls will actually display the color

[@tenj00]

The reason they are allowed is because not the whole world is using an American Keyboard and there are characters like this ÖÜäæ, 北方話北方話 漢字 and ภาษาไทย or 한국말 and so on. They have to be encoded in UTF Standards and be supported by Filesystems and Operating Systems.

[@Beyley]

i ran into this when i cloned a git submodule into the folder `--force` and couldnt delete it without a GUI app

[@akdev1l]

The definition of what a valid file name is actually comes from POSIX, the spec says anything that doesn't include a nul terminator or a path separator is valid modern Linux filesystems stay loosely posix-compliant

[@justanotheruser8271]

04:42 What's nonsense. You can touch file $SHELL. You just have to use superuser privileges. What could possibly go wrong, comrade?)

[@opalmay]

I just faced this the other day when I made a script for smb mounting and kept the 'c$' from the windows format in the mount folders names. It messed up my neovim. I could've modified my script but ended up forking plenery.nvim

[@xeenypl]

It's not because of compatibility with other filesystem NTFS and FAT doesn't support is just because "file name is a string which doesn't have to '/' or binary zero" why bother checking anything it's additional overhead (ext is old and backwards compatible)? Also, most pain is with Japanese/Chinese.

[@mikechappell4156]

At least in *nix the shell does the work, it has nothing to do with the command or the filesystem. The shell just executes a command and passes the strings that follow it as arguments. These strings can be flags, filenames, the subject of an email or other arguments. The shell doesn't care. You can write a command that will allow you to execute the last command N times, whatever the last command is; or another command you want executed daily with a standard name an extension based on the date, etc. The shell allows you to do these things trivially unless you want you pass through special characters. With a sensible naming convention this should virtually never be an issue.

[@xeenypl]

@@mikechappell4156 what? I mean you are right but what that has to do with my comment. I commented that because he sed ext3 should not support specialist characters.

[@dylan.t180]

This was fun 🤩

[@telotawa]

cool, naming my user !-s$SHELL

[@uplink-on-yt]

Learning about shells and how "everything is a token" eh? Make a file called "-rf" and then run "rm *" In paranoid mode, you quote everything and dash-dash before any wildcard expansion.

[@TheSolidSnakeOil]

[0-9a-z-_] The only characters I ever use in filenames.

[@NTmatter]

Emoji are perfectly legal as well. Good luck with that 😊

[@brunoais]

I prefer freedom! If I want an exclamation mark on my filename, I use an exclamation mark on the filename. It's my problem.

[@terrydaktyllus1320]

My point exactly and thank you for agreeing. On Linux, one is an adult and one is expected to know what one is doing at all times. This is precisely why the "experienced" among us keep constant backups because we all make the occasional silly mistake.

[@rashidisw]

I don't really like the idea using + in file name, in some case that was an operator to join/concatenate files content in specific order, in other case it was chosen character to escape THE SPACE ...

[@wombatdk]

By that same argumentation you should also disallow the entire Unicode character range. Which is just silly. I use all the characters you mentioned in filenames, regularly, and never once had any issue whatsoever - not even on the command line. Instead of exhorting people to not use characters, tell them how to use/access them, like you did. Oh and not all file managers know how to deal with specific filenames either. Sometimes they interpret filenames with forward slashes as path.

[@your_new_sjw_waifu]

I don't like spaces (I use underscores) but I'm so jaded at this point I don't even care. Just learn how to parse filenames. All the scripts I write can parse pretty much anything. Actually, now I'm considering using emojis in my /var/log/ filenames just because I can. Some people (like me) just want to watch the world burn. I mean, I built a free email service written entirely in node where everything (including attachments) is stored in MongoDB just because I knew it would bother my friend Pete. It's built to be extremely scalable (horizontal scalability is limited by essentially the speed of a redis database) but even I will admit it's quite silly. After I built it and explained to Pete how it worked, his only response was, "Why do you hate your computer?"

[@notliach]

Where I work, some users have been unable to process their product form because the backend system keeps crashing when trying to process the form's XML. Upon investigation, we discovered that the application did not expect users to submit filenames with '>' and '

[@ko.pi.pe.]

in windows some system api's can make filenames that the gui won't let you make.

[@edwardecl]

you can't stop me...

[@cluesagi]

Or you can be like Hiroyuki Sawano and name your files like '09. 凸】♀】♂】←巨人.flac'

[@amayra2010]

thanks you for this video

[@bjornroesbeke]

However much i dislike the "$" in file names, i use it to make sure these directories are sorted first, because "_" and "-" are ignored.

[@russellgreene8]

Filenames are not even constrained by unicode, just throw some random bytes into there: python -c "open('a\1\2\3\xff\x12', 'wb')"

[@kdcadet]

Spaces have caused me a lot of headache when looping over files in bash. Setting IFS was the best solution i found. Probably even better would be to write a python script instead though. But bash is just so great for some tasks, so its so disappointing when someone's love of spaces ruins that.

[@billeterk]

Globs are usually ok for that. Was the list of files text?

[@Hauketal]

Spaces are just a first symptom of a severe vulnerability. Write your scripts so that no interpretation by the shell happens where you don't want it. That includes ALL file names. What about a file named echo got you;rm -rf ~; unpacked from an archive?

[@kdcadet]

​@@Hauketal These are 1-use scripts that I use for data munging. A typical template I use is: for f in $(ls /mnt/data/); do echo $f # for instance done or for f in $(find /mnt/data -iname "*.png"); do ... how would you fix this? also, the "rm -rf ~" would result in printing rm -rf ~ for my example loop. Under what condition would that file name actually be executed as a command? echo $f | /bin/bash other than that, I can't think of a situation.

[@billeterk]

Yeah, ‘ls’ isn’t designed for parsing it’s output. for f in /mnt/data/* should work. For find something like find . -type f -print0 | while IFS= read -r -d '' file; do # commands with “$file” done

[@Hauketal]

@@kdcadet Never use $f unquoted. If it contains a ; like in my example, that starts a new command. Also using a for loop around find is just double processing. Use the -exec option of find instead.

[@markus321xyz]

I got myself in troubles, because I put a space as the first letter accidentally on some files by renaming them with a bad and ugly written script. I didn't noticed it in the gui and transfered the files, other Linux scripts and the windows users didn't like it.

[@jemsterr]

That tied to touch something in my root directory.

[@xBZZZZyt]

00:16 what os can't use " " in file name?

[@Khytau]

"rms feet" 😂

[@ronny332]

Can't understand both sides. Why 1. use messy filenames and 2. don't understand how to handle them 🙂. Daily business. Take a look at a usual office and see what the workers create for crazy stuff. Most of the shown hard to handle files points to our all missing knowledge about basic Shell stuff. As there is a file with a crazy name there is no "impossible to handle". There is only missing knowledge about handling them.

[@logicalfundy]

I would say that quote marks not escaping the dash in the file name like "-log" should be considered a bug. Why would they not escape the dash? Also, as another comment pointed out - the role of the file system is not really to enforce all of the conventions of shell commands.

[@mk72v2oq]

If you have programmed CLI app (or even bash script which uses $1, $2...), you will know that the command line arguments are just strings. Args parsing is done by the app itself, so it can only assume that "if the string starts with a dash, it is probably an arg".

[@billeterk]

Yep. The shell does it’s expansion / interpolation first but in this case the ‘-‘ does not need escaping.

[@therealb888]

Happy new year 🎉

[@rotteegher39]

Don't troll your friends like that xD