How to Find All Files with a Filename That Ends with Tilde

How to find all files with a filename that ends with tilde

You need to escape from the shell. And you need to specify search path, not *

find . -type f -name '*~'

To delete the files:

find . -type f -name '*~' -exec rm -f '{}' \;

Linux directory full of files with tilde sign(e.g. `example.txt~`), what does it mean and how do I get rid of it?

Since you seem to be having trouble, removing any file with a '~' anywhere in the file name would be as easy as adding another asterisk.

Example: rm *\~*

Strange that whatever application would place the tilde in the beginning of the file name, I've never seen that.

Global gitignore of files with tilde ~ (at the end of file name)

You can configure a global gitignore file which will affect all of your local repos:

git config --global core.excludesfile ~/.gitignore_global

Then treat it just as the usual per repo .gitignore file.

See https://help.github.com/articles/ignoring-files for more options.

How to keep git from tracking all files that end with a ~ ?

You want a gitignore file.

If you want to nuke everything that ends with a tilde (which should be safe; I can't imagine a reasonable use-case where that's bad), make sure the following line is in your .gitignore file at the top of your repo's folder hierarchy:

*~

---

If you also want to get rid of those tilde files laying around in your local file system, you can. It'd be best to make Gedit put its backup files somewhere else. JEdit and VIm, the two editors I use most, have such settings, and it's lots cleaner to keep those somewhere else than loading up gitignore.

Unfortunately, Gedit doesn't have that option. The best it can do is to turn off the ~ backups. Before you get worried, the worst case is that you lose what was in the file immediately before you saved. That's not a worst-case -- that's why you've got this in a git repo, right?

^{NOTE: If you want to keep the ~ suffixed files locally, do. The .gitignore you set up, above, will keep you from accidentally sharing them.}

You can turn off ~ suffixed backups like this

To prevent Gedit from creating these backups in the future, open up Gedit, open up the Preferences dialog (Edit > Preferences), select the Editor tab, remove the check in the “Create a backup copy of files before saving” option, and click Close. After doing this, Gedit will no longer make the backups with tildes all over the place.

BASH find files with ñ in name

(Part of this is stolen from a previous answer of mine.)

Unicode allows some accented characters to be represented in several different ways: as a "code point" representing the accented character, or as a series of code points representing the unaccented version of the character, followed by the accent(s). For example, "ñ" could be represented either precomposed as U+00F1 (UTF-8 0xc3b1, Latin small letter n with tilde) or decomposed as U+006E U+0303 (UTF-8 0x6ecc83, Latin small letter n + combining tilde).

OS X's HFS+ filesystem requires that all filenames be stored in the UTF-8 representation of their fully decomposed form (with a few exceptions that aren't relevant here). In an HFS+ filename, "ñ" MUST be encoded as 0x6ecc83.

When you type "ñ" on the keyboard, it uses the composed form U+00F1 (0xc3b1). You can see this with a hex dump:

$ echo ñ | xxd
00000000: c3b1 0a                                  ...

(note: the "0a" is a newline at the end of the "line" of output from echo.) But when you use it in a filename on a MacOS Extended volume, it gets converted to the decomposed form U+006E U+0303 (0x6ecc83):

$ touch ñ
$ ls | xxd
00000000: 6ecc 830a n...

In a UTF-8 locale these two different representations should be considered the same character, but apparently the find in macOS doesn't do this right:

$ LC_ALL=en_US.UTF-8 find . -name '*ñ*'
$ LC_ALL=en_US.UTF-8 find . -name '*n*'
./ñ
$ LC_ALL=en_US.UTF-8 find . -name 'n?'
./ñ

In the second and third commands, find is matching against the "n" code point, and treating the combining tilde as a completely separate character that follows it. BTW, note that I put quotes around the match patterns -- this is important because without them the shell will expand it to a list of filenames in the current directory before passing it to the find command.

The solution? Well, there's an icky option of explicitly using the decomposed form in the pattern. You can do this with bash's $' ... ' quoting form, which allows hex bytes to be specified with \x:

$ find . -name $'*n\xcc\x83*'
./ñ

But it's actually even worse than that, because starting in macOS High Sierra, Apple's using the new Apple File System (APFS), which allows both representations. And since find doesn't recognize them as characters, you can't even use a bracket expression like -name *[ññ]*' to match both of them, you have to use an extended regular expression with-Eand-regex`, like this (done on a Mac with APFS):

$ touch composed-ñ decomposed-n$'\xcc\x83' unaccented-n
$ ls
composed-ñ  decomposed-ñ    unaccented-n
$ ls | xxd
00000000: 636f 6d70 6f73 6564 2dc3 b10a 6465 636f  composed-...deco
00000010: 6d70 6f73 6564 2d6e cc83 0a75 6e61 6363  mposed-n...unacc
00000020: 656e 7465 642d 6e0a                      ented-n.
$ find -E . -regex $'.*(\xc3\xb1|n\xcc\x83).*'
./composed-ñ
./decomposed-ñ

(note that in a regular expression, .* is the way you match any sequence of characters, equivalent to * in a plain "glob" wildcard pattern.)

Isn't do-it-yourself Unicode support fun?

Unable to add files with name containing tilde, '~' followed by a number

This is the result of a change that was made to msys Git in December 2014.

On Windows' default filesystems, FAT and NTFS, DOS-style 8.3 file names are
supported for backwards compatibility. That means that there are multiple
ways to reference the same file. For example, the file
credential-cache--daemon.c can also be accessed via CREDEN~1.C (unless
another file has already been mapped to that so-called "short name", i.e.
the exact short name is unpredictable).

Since this mapping is unpredictable, we need to disallow such file names on
Windows, and while at it, we also exclude other file names incompatible with
Windows' file systems (e.g. NUL, CON, etc).

We use the core.protectNTFS guard introduced in the previous commit to make
sure that we prevent such file names only when appropriate.

To disable this behaviour, you can run:

git config core.protectNTFS false

However, since the new behaviour is there to protect you, I’d recommend
changing it back after having added your files:

git config core.protectNTFS true

Only disable this protection when you need to add files with tildes in the
name or check out branches containing such filenames.

In general, I’d recommend avoiding such filenames if working in
a Windows environment.

---

Related Topics