On my system running any `mw` command after a fresh install from the AUR, I get:

```
/usr/bin/mw: line 37: [: 1.5: unary operator expected
```

Now the script doesn't error per-se but it does set the `master` and `slave`
variables to wrong values. I'm also not sure how this wasn't raised before;
maybe that's a new bash version thing? I'm on 5.2.37.

Anyway I faffed around trying to fix this, in particular with the `-gt` operator
but it turned out that properly comparing float numbers is a pain in the butt in
bash. I found solutions using `bc` which I thought were weird.

To keep things simple I ended up doing a little substitution on the dot `.`
character and turned these nasty floats into integers, along with using the
`-gt` operator which did the trick on my system. May be unorthodox so feedback
is more than welcome.

Thank you for the great software by the way, lots of gratitude for your work.

This reverts commit 883e570d6d.

Fixes text being interpreted as flags when it starts with a dash.
Try sending yourself a letter with subject starting with '-'.
E.g. if subject is '-10%' fixes error:
> Unknown option -10%

Signed-off-by: Jonas Dujava <jonas.dujava@gmail.com>

Signed-off-by: Jonas Dujava <jonas.dujava@gmail.com>

password. This is useful if you copy your .password-store
directory from one computer to another.

- also change slightly confusing naming for (re)inserting given
      passwords to pass store

fix #910

// solution: changed from '0:' to ':0'

Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>

// solution: remove '-q'

Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>

use MAILSYNC_MUTE variable, and non-silly
commands to derive $from and $subject

Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>

On case-insensitive filesystem,
`inbox` and `Inbox` are the same path.
Running `find Inbox inbox [expr]` will print twice the same information.

Use shell glob instead:
`find` will descend into path `inbox`,
ignoring letter cases, only once.

Fix #828.

To close #845 :

I added the `-x` flag to prevent the regex from matching on _every_ pro-
cess name containing an `X`.

Because I'm not entirely sure about portability (does every `pgrep` va-
riant support that flag), I didn't push this directly.

So what do you think @LukeSmithxyz ?