That part slipped through while reviewing the PR...

Closes #463

Otherwise, several --info switches will not properly override each other

This fixes "feh -D -1 -D 1" and similar starting the slideshow in paused mode
even though the last -D option specifies autostart.

Closes #456

Note that --randomize and directory names are not saved in fehbg. It only
contains the command line needed to recreate the wallpaper setup which
resulted from its invocation, i.e., after randomization etc. have been
applied. This is intentional.

closes #458

Use "extern volatile" instead of "volatile extern" to avoid "gcc" warning "'extern' is not at beginning of declaration [-Wold-style-declaration]".

ft is already checked on line 153 so this condition is useless. Check https://github.com/derf/feh/issues/440 for more details

It is a naive way of fixing it :) Needs attentive review

sig_exit may be changed by a signal handler, so its value should always be
read from RAM.

See also #435

This changes the behaviour of "feh --start-at FILENAME" as follows:

Previously, this would cause feh to load all files in the current
working directory, since no files or filelists were specified on the command
line.

Now this is a special case: feh will extract the directory component from
FILENAME, load all files in that directory, and display FILENAME.
This way, it's possible to use "feh --start-at ~%f" in XDG Desktop files
and browse files in feh using the prev/next keys

Closes #372
Closes #420

This more closely resembles the expected behaviour of --start-at, but
may lead to mismatches if several files in the filelist have the same
basename.

Closes #206

Related to #372 and #420

This is in line with other software. save_filelist now defaults to "L".

Quoting glibc rand(3):

The  versions  of rand() and srand() in the Linux C Library use the same random
number generator as random(3) and srandom(3), so the lower-order bits should be
as  random  as  the  higher-order bits.   However,  on  older  rand()
implementations, and on current implementations on different systems, the
lower-order bits are much less random than the higher-order bits.  Do not use
this function in applications intended to be portable when good randomness is
needed.  (Use random(3) instead.)