This can happen with images that have ridiculous dimensions.

This ensures that X11 layout or other changes do not affect the .fehbg
contents, which are meant to only be updated when a --bg-option is used
manually.

Closes #482

When setting wallpapers without --no-fehbg option, a ~/.fehbg file is
created. This file is set to be an executable for later re-use.

Calling stat() without checking the return value can lead to issues.
If the call fails, then s.st_mode is undefined and excessive permissions
could be set to .fehbg, at worst even setuid/setgid bits for a world
writable file.

While adjusting this, I changed the code to use fstat() and fchmod() to
avoid a further -- but very unlikely -- issue: race condition in form of
TOCTOU. If the file ~/.fehsetbg is replaced by a symlink right before
the chmod call, then a different file would be set executable + the
default mode of the (newly created) file. I don't expect this to be a
real world issue but changed this part "while at it" anyway for more
robust code and a good example on how to handle files.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

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.)