rm delete hidden files
John Kelly
had a script where I wanted to empty a directory, without deleting the
directory itself. So I started experimenting, and found that
rm -rf * .*[!.]* ...*
will do it. Yet another stupid UNIX trick for the truly hard core ...
--
A: Maybe because some people are too annoyed by top-posting.
Q: Why do I not get an answer to my question(s)?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Alan Connor
<38e2h1tolhbj44hqq...@4ax.com>, "John Kelly" wrote:
> It was annoying me that "rm *" will not delete hidden
> files, because I had a script where I wanted to empty a
> directory, without deleting the directory itself. So I started
> experimenting, and found that
>
> rm -rf * .*[!.]* ...*
>
> will do it. Yet another stupid UNIX trick for the truly hard
> core ...
>
Thanks. I'll slip that into my rm man page (mine are text, just
for this purpose).
AC
Chris F.A. Johnson
> It was annoying me that "rm *" will not delete hidden files,
Of course rm will delete "hidden" files; it will delete whatever
files you tell it to.
> because I had a script where I wanted to empty a directory, without
> deleting the directory itself. So I started experimenting, and found
> that
>
> rm -rf * .*[!.]* ...*
>
> will do it.
So will:
rm -rf * .*
Or, with bash:
shopt -s dotglob
rm -rf *
When you specify a wildcard, the shell, not the command, expands
it, whether it's rm or any other command.
> Yet another stupid UNIX trick for the truly hard core ...
There's nothing stupid about it.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
==================================================================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>
John L
"Chris F.A. Johnson" <cfajo...@gmail.com> wrote in message news:qtf8u2-...@rogers.com...
> On 2005-08-28, John Kelly wrote:
> > It was annoying me that "rm *" will not delete hidden files,
>
> Of course rm will delete "hidden" files; it will delete whatever
> files you tell it to.
>
> > because I had a script where I wanted to empty a directory, without
> > deleting the directory itself. So I started experimenting, and found
> > that
> >
> > rm -rf * .*[!.]* ...*
> >
> > will do it.
>
> So will:
>
> rm -rf * .*
>
>
The latter includes .. which the OP wishes to exclude, hence the .*[!.]*
but quite what ...* achieves is unclear.
--
John.
Michael Heiming
Exactly, a quite dangerous regexp to use. A simple find would be
more save:
find . -type f -exec rm -f {} \;
Or use print and pipe to xargs if missing the "-exec" option.
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 302: microelectronic Riemannian curved-space
fault in write-only file system
John Kelly
<j...@lammtarra.notthisbit.fslife.co.uk> wrote:
>> rm -rf * .*
>The latter includes .. which the OP wishes to exclude, hence the .*[!.]*
Correct.
>but quite what ...* achieves is unclear.
For completeness, in case there exists a file or directory name which
begins with three or more dots, since .*[!.]* will not match it.
John Kelly
<michael...@www.heiming.de> wrote:
>>> rm -rf * .*
>
>> The latter includes .. which the OP wishes to exclude, hence the .*[!.]*
>
>Exactly, a quite dangerous regexp to use.
ls .* or ls .?* does show the contents of .. so at first, I thought
that rm -rf .* might be dangerous, deleting any directories one level
above, due to the recursive -r. However, I tried it, and it does not;
it only complains to stderr:
rm: cannot remove `.' or `..'
But in my scripts, I wanted to avoid stderr complaints, if possible,
without suppressing them via redirection to /dev/null, hence the
.*[!.]*
which is safe in the hands of an accurate typist. Now if you don't
have that much confidence in your hands, then I suggest using it only
in scripts, and carefully proofreading it before execution.
John Kelly
wrote:
>>but quite what ...* achieves is unclear.
>
>For completeness, in case there exists a file or directory name which
>begins with three or more dots, since .*[!.]* will not match it.
Oops. I should have said:
For completeness, in case there exists a file or directory name which
contains three or more literal dot characters and nothing else, since
John L
"John Kelly" <jak...@shtc.net> wrote in message news:q6e3h1t6aeobb51nd...@4ax.com...
> On Sun, 28 Aug 2005 13:57:04 +0200, Michael Heiming
> <michael...@www.heiming.de> wrote:
>
> >>> rm -rf * .*
> >
> >> The latter includes .. which the OP wishes to exclude, hence the .*[!.]*
> >
> >Exactly, a quite dangerous regexp to use.
>
> ls .* or ls .?* does show the contents of .. so at first, I thought
> that rm -rf .* might be dangerous, deleting any directories one level
> above, due to the recursive -r. However, I tried it, and it does not;
> it only complains to stderr:
>
> rm: cannot remove `.' or `..'
>
Ah yes, .. is a special case.
--
John.
Michael Heiming
>>>> rm -rf * .*
>>
>>> The latter includes .. which the OP wishes to exclude, hence the .*[!.]*
>>
>>Exactly, a quite dangerous regexp to use.
> ls .* or ls .?* does show the contents of .. so at first, I thought
> that rm -rf .* might be dangerous, deleting any directories one level
> above, due to the recursive -r. However, I tried it, and it does not;
> it only complains to stderr:
> rm: cannot remove `.' or `..'
You are lucky in the case, have seen already enough strange
things are likely to happen with ".*", so I generally avoid using
it at all especially with UID 0.
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 223: The lines are all busy (busied out, that is --
why let them in to begin with?).
John Kelly
<michael...@www.heiming.de> wrote:
>> rm: cannot remove `.' or `..'
>You are lucky in the case, have seen already enough strange
>things are likely to happen with ".*"
Since the shell regex .* matches .. I didn't want to use it with rm,
even though rm special cases the .. directory and refuses to delete
the .. contents even with the -r recursive flag. I dislike ambiguity
in general, and especially when depending on obscure or undocumented
special cases for safety.
That led me to wonder if it was possible to devise a shell regex which
would not match . or .. yet would match anything else beginning with a
literal dot. After googling for shell regex syntax, some thought, and
local experimentation, I was able to devise
rm -rf * .*[!.]* ...*
which may seem strange at first glance, but when you break it down, it
becomes perfectly clear:
1) the * matches everything except names beginning with a literal
dot, the so-called "hidden" files and directories.
2) let's consider this one:
a) the first . says the name must begin with a literal dot.
b) the next * matches 0 or more of anything.
c) the [!.] says there must be at least one character which is
not a literal dot, in the name. This guarantees that . and
.. will be unmatched.
d) the final * matches 0 or more of anything.
Thus the regex .*[!.]* will match any name (besides . or ..)
beginning with a literal dot, except:
3) The case where a name consists only of literal dots. Since we
don't want to match . or .. anyway, we use three literal dots
and follow with * to match all such names.
Thus covering all cases, and eliminating any ambiguity. Consider this
a proof, and find any errors.
If you are able. ;-)
Michael Heiming
> <michael...@www.heiming.de> wrote:
>>> rm: cannot remove `.' or `..'
>>You are lucky in the case, have seen already enough strange
>>things are likely to happen with ".*"
> Since the shell regex .* matches .. I didn't want to use it with rm,
> even though rm special cases the .. directory and refuses to delete
> the .. contents even with the -r recursive flag. I dislike ambiguity
> in general, and especially when depending on obscure or undocumented
> special cases for safety.
> That led me to wonder if it was possible to devise a shell regex which
> would not match . or .. yet would match anything else beginning with a
> literal dot. After googling for shell regex syntax, some thought, and
> local experimentation, I was able to devise
> rm -rf * .*[!.]* ...*
> which may seem strange at first glance, but when you break it down, it
> becomes perfectly clear:
[..]
> Thus covering all cases, and eliminating any ambiguity. Consider this
> a proof, and find any errors.
> If you are able. ;-)
Have not much doubt it should work fine if it doesn't match ".."
, but have to admit, I'd type a line 'find' magnitudes faster
then your expression.;)
BTW
You might want to consider setting your .sig delimiter to "-- ",
so modern newsreader can strip it automagically if replying.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 106: The electrician didn't know what the yellow
cable was so he yanked the ethernet out.
John Kelly
<michael...@www.heiming.de> wrote:
>Have not much doubt it should work fine if it doesn't match ".."
>, but have to admit, I'd type a line 'find' magnitudes faster
>then your expression.;)
I don't plan to repeatedly type it, either. But for scripts or
aliases, it's more terse than an equivalent find {-exec,|xargs}
command. Terse expression appeals to me.
>You might want to consider setting your .sig delimiter to "-- ",
>so modern newsreader can strip it automagically if replying.
You mean with an extra space trailing the two dashes? My newsreader
doesn't need a trailing space to recognize -- as the .sig delimiter.
I don't know if my newsreader is very "modern" or not, but I like it.
--
The sturgeon general says don't smoke fish
Michael Heiming
>>You might want to consider setting your .sig delimiter to "-- ",
>>so modern newsreader can strip it automagically if replying.
> You mean with an extra space trailing the two dashes? My newsreader
Yep.
The "standard" that is widely used on Usenet, but also with
email, is:
* "-- " (two dashes followed by a white-space character) on a
* line by itself.
> doesn't need a trailing space to recognize -- as the .sig delimiter.
Great but not standard and other newsreader don't per default.
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 94: Internet outage
Icarus Sparry
> On Sun, 28 Aug 2005 17:54:06 +0200, Michael Heiming
> <michael...@www.heiming.de> wrote:
>
>>> rm: cannot remove `.' or `..'
>
>>You are lucky in the case, have seen already enough strange
>>things are likely to happen with ".*"
>
> Since the shell regex .* matches .. I didn't want to use it with rm,
> even though rm special cases the .. directory and refuses to delete
> the .. contents even with the -r recursive flag. I dislike ambiguity
> in general, and especially when depending on obscure or undocumented
> special cases for safety.
The normal term for the shell pattern matching is 'glob' or 'globbing', as
it does not have the power of a regular expression. One of the
enhancements ksh did was to add a syntax for full regular expressions.
> That led me to wonder if it was
possible to devise a shell regex which
> would not match . or .. yet would match anything else beginning with a
> literal dot. After googling for shell regex syntax, some thought, and
> local experimentation, I was able to devise
>
> rm -rf * .*[!.]* ...*
>
> which may seem strange at first glance, but when you break it down, it
> becomes perfectly clear:
[snip]
> Thus covering all cases, and eliminating any ambiguity. Consider this
> a proof, and find any errors.
>
> If you are able. ;-)
Consider the file '...x' then this file name is generated twice. It
matches both the pattern 'something starting with a dot and having a non
dot character in it', and 'something starting with three dots'
The reason why you are not seeing any problem is that you are using the
'-f' option to 'rm', which suppresses errors. One can imagine a program
which say adds today's date to the end of every file which is passed on
the command line, your pattern would add the date twice.
One problem with the shell pattern matching is that if it does not match
then it passes the pattern as a literal to the program it is invoking.
Things like bash have the 'nullglob' option to change this.
A better solution is the glob pattern
* .[!.] .??*
If a file name does not start with a dot it is matched by the first term
If it does start with a dot and is two characters long and not '..' it is
matched by the second term
If it starts with a dot and is longer than two characters then it is
matched by the third term.
(Of course if it starts with a dot and is only one character long then it
is '.', and does not match any term)
John Kelly
<michael...@www.heiming.de> wrote:
>The "standard" that is widely used on Usenet, but also with
>email, is:
>
> * "-- " (two dashes followed by a white-space character) on a
> * line by itself.
I googled this:
http://www.chemie.fu-berlin.de/outerspace/netnews/son-of-1036.html
It says:
> Posters SHOULD avoid using conventions or encodings which make
> trailing white space significant; for encoding of binary data, MIME's
> "base64" encoding is recommended. Implementors are warned that ISO C
> implementations are not required to preserve trailing white space
So maybe the implementations requiring trailing white space, are the
ones not so modern. :-)
Michael Heiming
> I googled this:
> http://www.chemie.fu-berlin.de/outerspace/netnews/son-of-1036.html
> It says:
This is just a draft, anyone can make one and put it online, it
remains best practice since decades to use "-- ", if you like it
or not doesn't matter anyway. ;-) Don't care what your freaking
doze nntp sw can handle or not.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 453: Rhythmic variations in the voltage reaching
the power supply.
John Kelly
<use...@icarus.freeuk.com> wrote:
>> John Kelly wrote:
>> rm -rf * .*[!.]* ...*
> A better solution is the glob pattern
> * .[!.] .??*
Good catch. Aahz's law holds true ...
John Kelly
<michael...@www.heiming.de> wrote:
> Don't care what your freaking doze nntp sw can handle or not.
My software recognizes "--" as the .sig delimiter. It's yours that's
unable to cope. But if it's open source, it should be easy for you to
fix. ;-)
Sascha Wuestemann
> On Mon, 29 Aug 2005 17:46:52 +0200, Michael Heiming
><michael...@www.heiming.de> wrote:
>
>> Don't care what your freaking doze nntp sw can handle or not.
>
> My software recognizes "--" as the .sig delimiter. It's yours that's
> unable to cope. But if it's open source, it should be easy for you to
> fix. ;-)
Whenever I have found a definiton for the signature limiter it alway
reads "-- " and I have never noticed "--".
If your newsreader notices "--" then it is more user friendly than it
should be.
For example, Firefox (I believe, or was it Mozilla, hm, or both?)
recognize "www.domain.org" as a link in the signature (in the body text
above, too?) but my newsreader slrn does not which is correct, because
you have no http:// at the beginning of the word, which could also be
something completely different.
If I am not completely wrong "--" indicates a quote before of it and the
author following it (if not, correct me!).
cu
Sascha
John Kelly
<ne...@killerhippy.de> wrote:
>If I am not completely wrong "--" indicates a quote before of it and the
>author following it (if not, correct me!).
Do you mean two dashes followed immediately by a newline, or just two
dashes?
>If your newsreader notices "--" then it is more user friendly
More specifically; two dashes followed immediately by a newline. That
seems more intuitive as a .sig delimiter.
Trailing space before the newline, is not apparent when reading text,
and seems needlessly obscure. What purpose does it serve? If it has
no useful purpose, why retain it as a standard?
A flamewar over trailing whitespace in .sig delimiters ... what will
they think of next?
A simple regex can cope with either case ...
Michael Heiming
> <michael...@www.heiming.de> wrote:
>> Don't care what your freaking doze nntp sw can handle or not.
> My software recognizes "--" as the .sig delimiter. It's yours that's
> unable to cope. But if it's open source, it should be easy for you to
> fix. ;-)
[ http://www.ietf.org/rfc/rfc2646.txt ]
"
4.3. Usenet Signature Convention
There is a convention in Usenet news of using "-- " as the
separator line between the body and the signature of a message.
"
LOL...Typical doze user, just because your sw can't comply to RFC
standards, doesn't mean others would need to change their
compatible nntp client.
[ deleted .sig manually, since your reader is broken or/and you
are unwilling to fix and mine can't cut it off automagically on
reply, which is my whole problem with your "--" otherwise I
couldn't care less ]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 169: broadcast packets on wrong frequency
John Kelly
<michael...@www.heiming.de> wrote:
>[ http://www.ietf.org/rfc/rfc2646.txt ]
>"
>4.3. Usenet Signature Convention
>
> There is a convention in Usenet news of using "-- " as the
> separator line between the body and the signature of a message.
>LOL... your sw can't comply to RFC standards
You don't comprehend what you're reading.
As the text says, it's a historical "convention" which happens to be
mentioned in the RFC; it is *not specified* by the RFC.
>I couldn't care less
Really? Then I wonder why you keep going on about it ...
Michael Heiming
> <michael...@www.heiming.de> wrote:
>>[ http://www.ietf.org/rfc/rfc2646.txt ]
>>"
>>4.3. Usenet Signature Convention
>>
>> There is a convention in Usenet news of using "-- " as the
>> separator line between the body and the signature of a message.
>>LOL... your sw can't comply to RFC standards
> You don't comprehend what you're reading.
> As the text says, it's a historical "convention" which happens to be
There's no "historical" in the text above from RFC2646.
> mentioned in the RFC; it is *not specified* by the RFC.
>>I couldn't care less
> Really? Then I wonder why you keep going on about it ...
Good riddance!
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 215: High nuclear activity in your area.
Sascha Wuestemann
> On Mon, 29 Aug 2005 19:25:06 +0000 (UTC), Sascha Wuestemann
><ne...@killerhippy.de> wrote:
>
>>If I am not completely wrong "--" indicates a quote before of it and the
>>author following it (if not, correct me!).
>
> Do you mean two dashes followed immediately by a newline, or just two
> dashes?
Dunno, it was like this when I found it -- Bart Simpson.
If you can't convince them, confuse them
-- Harry S. Truman
Well, dunno what the differenc make for you. I take the first for
signatures, the second only for you.
>
> Trailing space before the newline, is not apparent when reading text,
> and seems needlessly obscure. What purpose does it serve? If it has
> no useful purpose, why retain it as a standard?
It is for the newseader to recognize the signature to highlight it for
your eyes watching it.
How does your newsreader react, when it reads multiple
--
or even
--
within the body?
-- snip just for the test --
What is highlighted?
-- /snip just for the test --
>
> A flamewar over trailing whitespace in .sig delimiters ... what will
> they think of next?
...who are "they"?
cu
Sascha
John Kelly
>On Sun, 28 Aug 2005 13:37:53 -0400, John Kelly wrote:
>> rm -rf * .*[!.]* ...*
>Consider the file '...x' then this file name is generated twice. It
>matches both the pattern 'something starting with a dot and having a non
>dot character in it', and 'something starting with three dots'
>A better solution is the glob pattern
>
> * .[!.] .??*
>
Hmmm ... after thinking about this some more, I see that your pattern
will have the same problem as mine, if the dotglob option is set. In
that case, the file '.x' will be matched by both the first and second
terms.
One more refinement, to allow for the dotglob option either on or off,
should be the final solution:
[!.]* .[!.] .??*
John Kelly
<ne...@killerhippy.de> wrote:
>How does your newsreader react, when it reads multiple
>
>--
>
>or even
When more than one, it treats the last "^--$" or "^-- $" as the .sig
delimiter. It makes no difference whether or not there is whitespace
between the two dashes and the newline.
As it should.
Thorsten Kampe
> In comp.unix.shell John Kelly <jak...@shtc.net>:
>> On Mon, 29 Aug 2005 17:46:52 +0200, Michael Heiming
>> <michael...@www.heiming.de> wrote:
>
>>> Don't care what your freaking doze nntp sw can handle or not.
>
>> My software recognizes "--" as the .sig delimiter. It's yours that's
>> unable to cope. But if it's open source, it should be easy for you to
>> fix. ;-)
>
> [ http://www.ietf.org/rfc/rfc2646.txt ]
> "
> 4.3. Usenet Signature Convention
>
> There is a convention in Usenet news of using "-- " as the
> separator line between the body and the signature of a message.
> "
>
> LOL...Typical doze user, just because your sw can't comply to RFC
His software complies but he doesn't. If the user is clueless his
software cannot force him to follow standards or best practices. Same
with his attribution novel^Wline.