How to delete a file whose name begin with -

Do not need a dictionary. Tri=three, via=way. It hints that there are many ways.
That's not the correct way to interpret the word 'trivial', not the correct etymology either: https://www.merriam-webster.com/dictionary/trivial

allgemein zugänglich = generally accessible.
The correct translation would be 'commonly accessible'. im Allgemeinen does translate to In general or generally, but in this context it is translated to 'common' as in im allgemeinen Interesse -> 'in the common interest'.
 
Under the supposition that Unix has a solution for everything. Yes, for example with a little of C code.
Did you seriously believe there might be no way to handle file names that begin with a dash? I don’t think so.
This is just a rearguard action on your part.

In an attempt to keep this thread on topic, a loosely related remark:

By the way, UNIX (more exactly: POSIX) file names are allowed to contan almost any character, with only two obvious exceptions: the slash (/) that is used for separating components within a directory path, and the NUL byte that is used to terminate strings in the UNIX API. The first can be worked around by using unicode characters that look similar, for example “” (division slash, U+2215):
Code:
$ cd /tmp
$ mkdir test
$ cd test
$ touch this∕is∕allowed
$ ls -l
total 0
-rw-------  1 olli  wheel  0 Mar 26 14:49 this∕is∕allowed
(You should use an appropriate locale, of course, e.g. UTF-8.)
 
The correct translation would be 'commonly accessible'.
Yes, commonly is much better translation.

About the etymology: it is trivial. It is trivial how it got the present meaning, as early as in antiquity.
Perhaps shkhln needs a dictionary because he lives far away. It is a Latin word, it is living sure in a
lot of romanic languages, it came sure to english with the french speaking normanic invasion of
William the Bastard.
 
The first can be worked around by using unicode characters that look similar, for example “” (division slash, U+2215):
In that context, it might be worthwile to also mention that Unix filenames and filesystems by design know nothing about encoding, they are just char sequences. So, using anything outside US-ASCII:
(You should use an appropriate locale, of course, e.g. UTF-8.)
you should always use the same locale that was in effect when naming the file ;)
 
Yes, commonly is much better translation.

About the etymology: it is trivial. It is trivial how it got the present meaning, as early as in antiquity.
Perhaps shkhln needs a dictionary because he lives far away.
Please try not to get personal.

Yes, the word “trivial” comes from the latin language and means “three ways”. But no, it does not mean that a problem has three (or multiple) solutions, as you tried to guess. Rather, it relates to a place where three roads meet, so it is a public place where people gather together, that’s why “trivial” literally means and “a public place” and hence the meaning “commonplace”.
 
you should always use the same locale that was in effect when naming the file ;)
Yes, of course, that’s what I meant. You need to use UTF-8 for both creating and using the file. That should go without saying.
Personally I use UTF-8 everywhere nowadays, so it’s not a problem.

Edit: By the way, UTF-8 is also compatible with POSIX semantics, because a valid UTF-8-encoded file name never contains bytes with the value 0x2F (/) or 0x00 (NUL). This does not hold true for most other encodings, e.g. you cannot use UTF-16 for file names. Therefore UTF-8 is really the best choice.
 
That should go without saying.
Not necessarily, e.g. NTFS on Windows always uses UTF-16 internally and the system does conversion to/from your current locale. So I think it's important to know Unix design is much simpler here :)
This does not hold true for most other encodings
Except for UTF-16 and UCS-4, which other encodings would pose that problem? Definitely not those in ISO8859 ;)
 
But no, it does not mean that a problem has three (or multiple) solutions, as you tried to guess.
Not in that strength. Not three, and may be not many. The place where the roads meet. The ways that
bring you to the solution. And even if it is only one long, steep way with a lot of obstacles, it remains:
trivial. And I did not try to guess: I do know what trivial means. I do not need to search the word in a
dictionary as I also do not search the word chair. And, using your own words, your opinion is wrong due to
ignorance.
 
Not necessarily, e.g. NTFS on Windows always uses UTF-16 internally and the system does conversion to/from your current locale. So I think it's important to know Unix design is much simpler here :)
Don’t get me started about NTFS … :)
Windows 10 still disallows creating files named “con:” or “<foo>” (like MS-DOS, 40 years ago).
 
Not in that strength. Not three, and may be not many. The place where the roads meet. The ways that
bring you to the solution.
That is your personal interpretation, but it is not the actual etymology of the word “trivial”. If you don’ believe SirDice, shkhln or me, please look it up in a dictionary or on Wikipedia. I'm not trying to insult you, I'm just trying to explain what the correct facts are.
 
Well, THAT's a different story and not really NTFS' fault.
Actually, it’s two unrelated issues. The first are reserved file names (like con, aux, lpt), the second are invalid characters (e.g. :, <, >, ?, * and a few others).
It’s true that it is not NTFS’ fault, it’s rather Windows’ fault, but NTFS suffers from it.

You can create such file names when you attach an NTFS disk to a POSIX system. But when you move it back to a Windows system, it won’t be able to handle them.

Another source of trouble is the case-insensitivity of NTFS. But this really starts to get off-topic.
 
It’s true that it is not NTFS’ fault, it’s rather Windows’ fault, but NTFS suffers from it.
Well, only when used in combination with win32. I didn't try, but would just assume you can happily name a file "con" when using the NT Kernel's interface instead of win32 (or maybe a different subsystem, if there were any…)

Anyways, seeing how this stems from the Unix idea of "device files", poorly adapted first to a very simplistic OS (CP/M), then just kept forever in an evolving OS (MS-DOS → Windows), is kind of amusing. I generally like when unnecessary breaking changes are avoided (one reason to prefer FreeBSD over Linux), but this seems a bit over the top :D
Another source of trouble is the case-insensitivity of NTFS. But this really starts to get off-topic.
Yes, sorry. I guess I should leave here, don't see anything on topic that wasn't already explained :)
 
That is your personal interpretation, but it is not the actual etymology of the word “trivial”.
No, it is not my personal interpretation. I have it from someone else. And my source is not some dictionary
or wikipedia.

I also know, how etymology is done. It is difficult to speak about facts. But in your discourse there are absolute
facts or opinions acording to your arbitrariness.
 
Sigh, seriously. You pointed to a description from an dictionary from 1918. Languages evolve. I'm pretty sure that dictionary from 1918 has words in it that are not in use any more. And it probably doesn't have a whole bunch of new words that are used nowadays. There are a lot of words in any language that changed meaning in the past 100 years.
 
So simple, im, thanks. Full path.

Buit still I wonder, why names got by glob are still seen as options. That may be risky.

It is risky. It is a bad thing. But since it has been standardized and gone over for about 30 or 40 years, it is considered correct behavior. Matter-of-fact, in the early 90s someone published a book called "The Unix haters handbook", and the example of having a file called "-Rf" in your directory and then doing "rm *" is chapter 1 of that book.

I consider it to be a nasty design flaw. In a well-designed system, this should not happen; there should be a clear distinction between options/flags/parameters and arguments to commands. Commands should be able to read what the command line was *before* globbing if they want to, and perform globbing only if appropriate, and how. But that's not the way Ritchie and Thompson wrote the first version, and their bad decision and shortcut has now become enshrined. Sad.

Other examples where this goes wrong: "find . -name foo*" fails if there are multiple files whose names start with foo in the current directory, while the intent of the find command is to find all files whose names start with foo. Or "echo Should we go to lunch ?" will spit out gibberish if the current directory contains files that have single-character file names, while "echo Should we go to lunch?" only does if the current directory contains files that are named "lunch" plus a single character. In the presence of unicode, all that goes completely insane, because the definition of "single character" becomes complex: what looks on the screen like a single character might not actually be one. And getting back: This command
Code:
echo "Should we go to lunch ?"
will work, independent of what files exist in the current directory. But that's not intuitive. Why do users need to learn how globbing and the shell work internally, and complicated quoting rules?

Well-designed operating systems (such as VMS or MVS/TSO) do not have these problems in their shells. But for Unix, this is water under the bridge.
 
Don’t get me started about NTFS … :)
Windows 10 still disallows creating files named “con:” or “<foo>” (like MS-DOS, 40 years ago).
And I actually think this is a good thing. I think file system standards should disallow creating file names that are likely to cause confusion. Like ones that contain newlines, invisible special characters, or non-normalized unicode sequences. For example, I can create a file whose name is a single space. You do ls, you don't see it, but the count of files is off by one. I don't think this should be allowed.

One of my favorite examples: It is possible to create two files in a directory, one whose name is "a with acute accent", and the second one has a name that is two characters, namely "a" and "overstrike acute accent". Those are separate files, but both file names look the same on the screen, even if you quote them. The even more insidious version of this is to use the two-character sequence "turkish i without dot" and "overstrike accent dot", which looks exactly like an "i", and it doesn't even have any accents. So now you have to files that look like they have the same name, and the only way to distinguish them is "ls -1 | hexdump -C". This is just insane.

But then, Unix has been this way for 50 years, it can't be changed now, it has such a high market share that no replacement will ever be created, and we'll live with it.
 
For example, I can create a file whose name is a single space.
I recently ran into something similar. Some id-ten-t developer had created a file with a space at the end of the filename. And some of my colleagues couldn't figure out why they couldn't get rid of it :rolleyes:
 
In the early 2000's I worked at a fashion company. One big problem was that designers would accidentally create files ending with jpg<space>. So, we'd wind up with directories having files like 123.jpg 123.jpg. Eventually, I think I did cat -e on the list and renamed the oddly named files. It was funny but not funny. They created these files on Windows and/or Mac, but as has been pointed out, Unix and Unix like systems allow it too.
 
I'm going to add this to my list of things to do for new junior admins. Create a bunch of weird files then ask them to delete some of them. See how long it'll takes them to figure it out. Like we used to send out newbies to reproduction to fetch a stack of 'landscape' paper. 😁
 
I'm going to add this to my list of things to do for new junior admins.
We used to have a small test for our junior admins at uni at campus. We did touch asd && chflags schg asd, gave them root and told them to remove the asd file. It used to be kinda fun. :)
 
Sigh, seriously. You pointed to a description from an dictionary from 1918. Languages evolve. I'm pretty sure that dictionary from 1918 has words in it that are not in use any more. And it probably doesn't have a whole bunch of new words that are used nowadays. There are a lot of words in any language that changed meaning in the past 100 years.
It is one of the best latin-german dictionaries. Classical latin, not even middle latin. Should classical
latin have changed in the past 100 years?! Yes, the word "trivial" has perhaps also a new despective
meaning. It is clearly a metaphor, beginning with speaking of a "way" when solving problems you
see a metaphor. Perhaps it is not so clear how exactly it arose, if it is a truth from the street (trivium)
as @oli want to see it or a more comprehensive metaphor, but the meaning is clear and coincides
with what Georges says about the old word.

I ask me, if @oli and all those computer scientists that understand words literally are able to see the
relation between "ready" and "to ride" (bereit und reiten, fertig und fahren), or never noted it.
 
But then, Unix has been this way for 50 years, it can't be changed now, it has such a high market share that no replacement will ever be created, and we'll live with it.
Yes. This is a strange thing. Unix is good enough, so that there is no place for something better.
 
Classical latin, not even middle latin. Should classical
latin have changed in the past 100 years?!
Classic Latin is a dead language. While lots of European Romance languages (French, Spanish, Italian, etc) are certainly based on that (and by extension other languages that picked up Latin words) their exact meaning or representation evolves over time. I'm pretty sure you wouldn't be able to understand Althochdeutsch (Old High German) just as much I can't understand Oudnederlands (Old Dutch). Heck, even in modern times I sometimes barely understand what someone from Limburg or Brabant says, I certainly don't know any Frisian (which is a whole different language of its own).
 
Back
Top