> ~/.freeciv [and its analog on other platforms] is not perfect,
> but in the absence of a better place, i think it'll do.

This would mean using get_save_dirs() for the client. Furthermore, the server needs a check of the path for the saved image file ...

> There is a chance for the user to select another directory,
> right?

Yes

> Just a question more: Is the user expect the image to save in
> the current directory or in the home directory (as for logs
> e.g.)?

I do not know. Perhaps some other opinions are needed. Where do you expect a program to save images? (current directory, home directory or ...)

> > Thus, it should return NULL for all other operating systems.
> > Is this OK:
>
> Yes. Note that the definition of init should be pushed inside
> the conditional block to avoid compilation warnings.

As the function is only used inside of shared.c the definition is now static (and inside a #ifdef).

changes:

• define current_dir() as static within shared.c and protect it by #ifdef's
• rename get_current_dir() to get_mapimg_dirs()

(file #10848)

> Maybe, I haven't be clear enough. As current_dir() is a part
> of the public interface, it must work in any environment. If
> it is used in Windows, it will probably produce an error.
> #ifdef must be added inside this function.

I did add some ifdef's to the function but they are not included in the patch. Before I do it again, I would like to discuss that is needed. At the moment the function current_dir() will only work for *nix systems. Thus, it should return NULL for all other operating systems. Is this OK:

> get_current_dir() doesn't make sense. The current directory is
> a single directory, so there is no reason to return a string
> vector.

This function is used for fileinfolist_infix() which needs an string vector as argument. It could be renamed to get_mapimg_dirs() which

• uses the current directory on *nix
• uses the directories returned by get_save_dirs() on other systems

The mapimg file saving from the client is special as it is handled by the client and not by the server as are save games.

updated patch:

• include get_current_dir() from gna patch #2019
• cleanup #ifdef's

(file #10845)

> Why returning as a read-or-write data?

Done; see below

> Please at least add comment to "if (tok[0] != '/')" that "/"
> is not root directory in some environments. (In windows
> absolute path would start with letter as in "C:")

Done; see below

> Also check that we don't already define such a string as a
> macro somewhere. IIRC we have PATH_SEPARATOR at least ('/'
> or '\') which you fail to use in this patch btw.

PATH_SEPARATOR is the separator between different paths, i.e. ";" (windows) or ":" (linux)

updated patch:

• current_dir(), user_home_dir() and user_username() return const data
• the check is only defined for *nix systems

(file #10828)

> Is this really portable?

It is not portable. For non-unix systems or systems without the environment variable $PWD the current behaviour is not changed. I have no knowledge about such systems to get the current directory there.

> Why returning as a read-or-write data?

No reason - it chould be const char *.

• do not duplicate file names if one path is given as relative and as full path
• see also gna patch #2019