Hacker News Reader

Comment by est | Hacker News Reader

I never understood why Unix chose "-" for options. It creates unnecessary confusion. E.g. when deleting a directory called "-rf"

View on HN

Another viewpoint: the problem is caused by Unix allowing any character in filenames (other than slash and null). Other platforms are more restrictive in what characters filenames are allowed to contain. If you banned the '-' character from starting a filename, the problem wouldn't happen.

I personally think Unix allowing almost any character in filenames was a mistake. You can put newlines and other control characters in filenames. That has very little legitimate use, and is a potential source of security and other bugs. There is a proposal to amend the Unix standards to disallow control characters in filenames. But it doesn't look like it is going to be successful: https://www.austingroupbugs.net/view.php?id=251

A coworker of mine got into trouble when he named a directory ~ and then tried to delete it.

I once named a file $HOME and then carelessly tried to delete it without thinking twice.

> the problem is caused by Unix allowing any character in filenames (other than slash and null).

Most Unixes don't allow any character; they allow any byte other than ascii slash or zero. Turning bytes into characters is outside the scope of most Unix kernels and the filesystems therein.

> Turning bytes into characters is outside the scope of most Unix kernels and the filesystems therein.

All the major contemporary Unix(-like) kernels do have code in them to do file path charset translation. It is very important when dealing with removable media (ISO-9660, UDF), FAT filesystems, network filesystems (especially CIFS/SMB, but even some NFS implementations), filesystems defined in terms of Unicode such as NTFS, HFS+, APFS.

Traditional Unix filesystems don't do this, but they were originally designed at a time when few clearly distinguished the concept of byte from the concept of character.

Agreed!

Shell scripting would be so much more sane (and safe) if filenames couldn't contain spaces (or control chars) and couldn't begin with a '-' character. Then the shell's default $IFS would work as intended in the presence of pathname expansion, and there would be no need to use '--' to delineate the filename arguments from the option arguments when executing commands.

The only solution to that confusion would be not allowing the options identifying character in file/directory names. Changing the character would just "change" the confusion.

Wouldn't / just cause confusion trying to delete a directory called /rf ?

There's no directory called /rf so the mistake can do no harm, as a good design should be.

Your comment is based on the premise that there is, in common use, a directory called “-rf” but not one called “/rf”? Why would the former be any less likely than the latter?

Technically deleting a directory is done with the rmdir command. But rm with flags is flexible enough that I've seen very few people use rmdir

rmdir is usefull when you want to remove all empty subdirs, without touching files or directories with files. Just do 'rmdir *' and you're done.

I like using rmdir even for individual directories that I think are empty just so that I don't accidentally delete any files that I did not expect to be there.

I use it whenever I expect a directory to be empty and want an error if for whatever reason it isn't. It's a bit niche, but good to have in your toolbelt.

There's always going to be ambiguity.

rmdir /f /usr

Is that force-deleting the /usr directory, or the /usr and /f directories?

I mean on Windows it's

   rd /s /q \path\to\something

There's zero ambiguity because both "/" and "\" are special characters.

Except that on Windows, you can use "C:/path/to/something" nearly everywhere where it accepts "C:\path\to\something".

Except C:/ is not a command option, and only Unix people would write "/"

Sounds a bit provincial. That might have been true before mainstream internet access, but the average user these days is likely more familiar with unix style paths via URLs than local filesystem paths.

Also, most non-unix operating systems that don't happen to be made by Microsoft also use the forward slashes for paths.

> the average user these days is likely more familiar with unix style paths via URLs than local filesystem paths

The average user ignores the contents of the address bar. "That's all tech gobbledegook". Increasingly, browsers even hide its contents from the user, just displaying the domain name, making the average user even less aware of it.

> Also, most non-unix operating systems that don't happen to be made by Microsoft also use the forward slashes for paths.

What are "non-unix operating systems that don't happen to be made by Microsoft". Non-Microsoft operating systems in common use – Linux (including Android), macOS/iOS/Darwin/XNU, *BSD – are Unix-like, and hence I wouldn't really call them "non-unix" (even if they are not strictly speaking certified as such)

If we look at non-Microsoft non-Unix(-like) operating systems (none of which are commonly encountered nowadays), we see a lot which use neither forward nor backslashes for directories. For example, OpenVMS and RISC OS both use dots, classic MacOS used colons. Stratus VOS uses the greater-than sign, which it inherited from Multics. The IBM mainframe operating system MVS (nowadays called z/OS) uses dots to separate the components of a dataset name – although those components aren't exactly directories. (It also supports forward slashes in its Unix compatibility subsystem, but that wasn't around for the first 25 years of its existence.)

>> What are "non-unix operating systems that don't happen to be made by Microsoft".

It's a pretty big list. To name a few:

Beos (and derivatives), AmigaOS (and derrivatives), GEOS, Commodore DOS, Temple OS, TRON, plenty of Real Time Operating Systems...

You can make that exact same argument irregardless of what switch character Unix uses. The real problem is not the switch character itself, but the approach used by standard Unix tools to "parse options until parsing fails, then assume it's an argument" which becomes an amazingly great foot gun if the actual option is inserted by a shell glob or a shell variable.

For everybody reading, a directory called "-rf" is deleted by writing "rm -- -rf"; -- indicates the end of all user-provided options.

If you're working with files, another (perhaps more reliable) way is `rm ./-rf`.

Reply on news.ycombinator.com