How to delete a file whose name begin with -

You wrote: “It is a bug in my oppinion.”
Then Zirias replied: “It is specified in POSIX that globs are expanded by the shell (and if you want to pass them unexpanded to a command, you have to escape them).”
And then you asked: “How?”
 
You shouldn’t claim something is a bug or "risky" if you're not familiar with it at all. That will provoke exactly the reactions that can be seen in this thread.

The way globbing and parsing of command line options works is POSIX-compliant, and it works the same for every operating system that strives to be POSIX-compliant. And it is only risky if you don't know how it works. And the way it works is documented in the manual pages.

BTW, asking how to remove a file starting with a dash is a typical beginner's question. A beginner should never claim something is a bug, but instead try to learn why things are the way they are. Also, I can’t help but notice that quite a lot of threads you are involved with turn into non-technical arguments and finger-pointing. You need to work on your attitude.
 
Olli, yes, understanding things literally, you are right. I reacted fast and understood the unexpected hint of quoting as a solution to the original problem.

UPDATE: And I am sure that also experts from time to time do error of beginners. It is posix, it is consequent
behaviour, but in my opinion a risky. There is a reason why rm has a flag -i.
 
UPDATE: And I am sure that also experts from time to time do error of beginners. It is posix, it is consequent
behaviour, but in my opinion a risky.
An "expert" in the meaning you seem to imply will, when confronted with "unexpected" behavior, do some research, or just ask, instead of prematurely claiming something is a "bug" or "wrong".

And there's absolutely nothing "risky" with POSIX specifying that options start with a dash, and a double-dash marks the end of options. If you're doing it wrong, it will just not work.
There is a reason why rm has a flag -i.
There is, but that's a whole other topic not related here.
 
Yeah, the -i option is nice but not for automated scripts. With scripts you really need to handle filenames properly, especially if you store those filenames in variables that are dynamically filled. Most sysadmins take care of naming files properly (they know certain characters are difficult to handle, like the aforementioned -), but leave it to users to come up with some really funky filenames. Filenames that can royally screw up your scripts if you don't account for them.
 
An "expert" in the meaning you seem to imply will, when confronted with "unexpected" behavior, do some research, or just ask,
I just asked, in this informal forum. I think this is what makes the forum a nice distraction, a little small talk,
a little battlefield. Of course, before asking in the mailing list, I would do some, or more, research.

instead of prematurely claiming something is a "bug" or "wrong".

I did not claim, I said my opinion, that in your opinion does not count. Then why is that so a big offense?!

And there's absolutely nothing "risky" with POSIX specifying that options start with a dash, and a double-dash marks the end of options. If you're doing it wrong, it will just not work.

I knew the double dashes on only few programs. I never needed them before. The fact that this double
dash mechanism is necessary, tells that it is not a trivial problem.
 
UPDATE: And I am sure that also experts from time to time do error of beginners. It is posix, it is consequent
behaviour, but in my opinion a risky. There is a reason why rm has a flag -i.
Let me answer by giving three quotes from my collection of usenet signatures.

"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
 ― Doug Gwyn, UNIX developer

"If you aim the gun at your foot and pull the trigger, it's
UNIX's job to ensure reliable delivery of the bullet to
where you aimed the gun (in this case, Mr. Foot)."
 ― Terry Lambert, FreeBSD-hackers mailing list

"Unix gives you just enough rope to hang yourself --
and then a couple of more feet, just to be sure."
 ― Eric Allman, author of BSD sendmail and syslog

And finally: Recommended reading: Unix philosophy
 
I knew the double dashes on only few programs. I never needed them before. The fact that this double
dash mechanism is necessary, tells that it is not a trivial problem.
It is very trivial, but of course, you have to understand the concept. For the commandline invocation of a conforming utility, there are a few simple rules:
  • options start with a dash and must come first
  • the first non-option (positional parameter) marks the end of options
  • in case the first(!) non-option does start with a dash, insert a double-dash before, which explicitly marks the end of options
I just noticed this forum has a nice "ignore" feature…
 
I did not claim, I said my opinion, that in your opinion does not count. Then why is that so a big offense?!
Saying “in my opinion” is redundant. Of course it is your opinion, even if you don’t mention it.
But still, in this case it is a wrong opinion because it is based on ignorance.

I knew the double dashes on only few programs. I never needed them before. The fact that this double
dash mechanism is necessary, tells that it is not a trivial problem.
Actually it is trivial, as soon as you are aware of how the parsing of command line arguments works in UNIX.

By the way, you don’t necessarily have to use double dashes. You can also give the relative file name (./-file) or the absolute file name (/dir/-file or $PWD/-file). Of course, this won’t work if the argument is not an actual file, for example when doing things like expr -- -100 + 300 or grep -- -strike- somefile – in these cases you have to use double dashes, indeed.
 
I knew the double dashes on only few programs. I never needed them before. The fact that this double
dash mechanism is necessary, tells that it is not a trivial problem.
It is. You can't have a text interface without some meta-chars at least.
 
It is very trivial, but of course, you have to understand the concept. For the commandline invocation of a conforming utility, there are a few simple rules:

Well, perhaps basic programs follow that rules. I know a lot of programs that do not.

Saying “in my opinion” is redundant. Of course it is your opinion, even if you don’t mention it.
But still, it is a wrong opinion because it is based on ignorance.

Excuse me, but I cannot follow your absolute relativism.

It is. You can't have a text interface without some meta-chars at least.

Yes, it is trivial that it needs an extra mechanism. Does this mean that the original problem is trivial?
 
Yes, it is trivial that it needs an extra mechanism. Does this mean that the original problem is trivial?
For comparison, writing sed (grep, etc) snippets for FreeBSD ports requires people to juggle 3 levels of escaping. That's make, shell and sed rules. You never know whether you need $, $$ or $$$.
 
Well, perhaps basic programs follow that rules. I know a lot of programs that do not.
No, all standard UNIX utilities follow those rules. They use getopt(3) or similar library functions for parsing of command line options, or getopt(1) for shell scripts, or the shell’s built-in function for that purpose.
It is true that some 3rd-party programs do it differently, though. But rm(1) is clearly a standard UNIX utility.

Yes, it is trivial that it needs an extra mechanism. Does this mean that the original problem is trivial?
Yes, in this case it is trivial. If you think about it, if there are characters with special meaning (like “-”), then there must be a way to remove that special meaning. Like &lt; in HTML when you want to display the character “<” which has a special meaning.
 
For comparison, writing sed (grep, etc) snippets for FreeBSD ports requires people to juggle 3 levels of escaping. That's make, shell and sed rules. You never know whether you need $, $$ or $$$.

You understood "trivial" as "easy", I meant it as "demanding an extra mechanism", and the real meaning
of trivial is: "there are many ways".

then there must be a way to remove that special meaning.
That is, using your vocabulary, an opinion based on ignorance and hence wrong: that something is needed
does not mean that it must exist.
 
For comparison, writing sed (grep, etc) snippets for FreeBSD ports requires people to juggle 3 levels of escaping. That's make, shell and sed rules. You never know whether you need $, $$ or $$$.
Don't get me started on the backslash hell you can find yourself in with certain utilities. Dealing with Windows shares for example, \\servermame\share -> \\\\servername\\share. And sometimes you need to 'escape' the escape so you end up with \\\\\\servername\\\share. Or how about the infamous 'wave' escape; s/\/usr\/local\//\//. It'll drive you completely bonkers if you don't pay enough attention.
 
That is, using your vocabulary, an opinion based on ignorance and hence wrong: that something is needed
does not mean that it must exist.
Since UNIX supports file names that start with a dash, obviously a way exists to handle them.
 
Since UNIX supports file names that start with a dash, obviously a way exists to handle them.

Under the supposition that Unix has a solution for everything. Yes, for example with a little of C code.

A trivial problem is the one that could not be reduced (simplified) further. You can look up the meaning in a dictionary if you want.
Do not need a dictionary. Tri=three, via=way. It hints that there are many ways.
 
I guess the conversation is stirred to something different now but it may be that this thread will be thrown at some user who's actually googling the problem. The explanations why this is happening are mentioned already and even how to work around it. There's also another way (of few others) how to delete the files with find:

Code:
# the numbers on left are the inode numbers
$ ls -lai
total 10
2011 -rw-r--r--   1 martin  martin   0 Mar 26 12:59  --what is?this
2001 drwxr-xr-x   2 martin  martin   3 Mar 26 12:59 .
   2 drwx------  16 martin  martin  41 Mar 26 12:59 ..
$

# find the inode number in question
$ find . -xdev -type f -inum 2011
./ --what is�this
$

# see what really is in the name of the file
$ find . -xdev -type f -inum 2011 -print0 | hd
00000000  2e 2f 20 2d 2d 77 68 61  74 20 69 73 88 74 68 69  |./ --what is.thi|
00000010  73 20 00                                          |s .|
00000013
$
# remove
$ find . -xdev -type f -inum 2011 -exec rm {} \;
The -xdev is important as you want to search only on a current FS. There can be two files with the same inum across the FS.
 
One has to wonder has many other words you have arbitrarily redefined.

From a classical, well respected dictionary (Georges, Ausführliches lateinisch-deutsches Handwörterbuch,
1913-1918):

triviālis, e (trivium), I) dreifältig, dreifach, germanitas, Arnob. 3, 34. – II) allgemein zugänglich, allbekannt, gewöhnlich, gemein, scientia, Quint.: ludii ex circo, Suet.: verba, Suet.: carmen, Iuven.: mos, Calp.
allgemein zugänglich = generally accessible.

It is you or your dictionary what is redefining the word.
 
Back
Top