Sign in to follow this  
Unreal

Getting Username (Windows And Linux)

Recommended Posts

Hello there! I want to save my Engine config files at: \documents and settings\<user>\application data\my engine\ for windows and /home/<user>/my engine/ for Linux where <user> is the current logged in user that runs the application. how i will get the username for both windows and linux? any idea? thanks for your time!

Share this post


Link to post
Share on other sites
A simpe version under linux is to investigate the environment variables, as are available from the main() invocation. Herein the variable USER denotes the user's name. Even better is to use HOME that already denotes the user's home directory (and hence would be more suitable instead of assuming it being located in /home/).

Another way is to use getlogin() or getlogin_r() from the libc, included by unistd.h. There're some quirks with this functions, so you should carefully read the man pages of them.

Sorry, but I don't know to do this things under windows. Perhaps there is also something to find in the environment variables?

Share this post


Link to post
Share on other sites
To get the user's home directory, use the environment variable "HOME" under Linux / Unix (and the env var "userprofile" on Windows).

Environment variables are case sensitive.

Finding the username is something different, independent. Both Linux and Windows can be configured to place users' home directories somewhere other than the default, so you shouldn't rely on that.

Mark

Share this post


Link to post
Share on other sites
Quote:
Original post by Unreal
how i will get the username for both windows and linux?


I don't know about Windows. For Posix systems (e.g. GNU/Linux), you can use getpwuid(3) with getuid(2).


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pwd.h>
#include <string.h>
#include <errno.h>

int main() {
struct passwd *pwd;
pwd = getpwuid(getuid());
if (NULL != pwd) {
printf("Username: %s\n", pwd->pw_name);
printf("Home directory: %s\n", pwd->pw_dir);
}
else {
fprintf(stderr, "Error: %s\n", strerror(errno));
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}




Quote:
Original post by Kazade
I'm pretty sure that saving to:

~/my engine/

would work in linux. ~/ is a shortcut to the home directory.


It's the shell that expands ~ into the home directory. The C library doesn't.


Quote:
Original post by haegarr
A simpe version under linux is to investigate the environment variables, as are available from the main() invocation. Herein the variable USER denotes the user's name. Even better is to use HOME that already denotes the user's home directory (and hence would be more suitable instead of assuming it being located in /home/).


That's dangerous. Consider:


$ cat foo.c
#include <stdio.h>
#include <stdlib.h>

int main() {
char *home = getenv("HOME");
if (home) {
printf("%s\n", home);
}
return 0;
}
$ ./foo
/home/somebody
$ HOME=/root ./foo
/root


This isn't dangerous per se (lambda users can't write to /root), but it illustrates that you can't trust environment variables to get meaningful data.

Share this post


Link to post
Share on other sites
[quote]Original post by let_bound
Quote:
Original post by Unreal

Quote:
Original post by Kazade
I'm pretty sure that saving to:

~/my engine/

would work in linux. ~/ is a shortcut to the home directory.


It's the shell that expands ~ into the home directory. The C library doesn't.


Oops. My mistake.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by let_bound
This isn't dangerous per se (lambda users can't write to /root), but it illustrates that you can't trust environment variables to get meaningful data.


On the other hand, sometimes it can be a good idea to let the user specify another directory by redefining HOME in a shell. I remember doing that a few fimes, but don't remember the exact purpose of it...

Share this post


Link to post
Share on other sites
Quote:
Original post by Unreal
Quote:
Original post by haegarr
A simpe version under linux is to investigate the environment variables, as are available from the main() invocation. Herein the variable USER denotes the user's name. Even better is to use HOME that already denotes the user's home directory (and hence would be more suitable instead of assuming it being located in /home/).


That's dangerous. Consider:

code removed

This isn't dangerous per se (lambda users can't write to /root), but it illustrates that you can't trust environment variables to get meaningful data.

Its true that environment variables can simply be faked, e.g. I can tell the computer to display me chinese messages by setting $LANG to the appropriate value. Well, then I have to live with the result ;) But it isn't dangerous to let the user write to any directory the user has write permissions for. Of course, it is best practise to check whether opening/writing files is possible instead of breaking the program. The only "security" issue would be that the user may overwrite the same files of another user, but that can (and should) simply be avoided by file permissions. Last but not least I second the hint of the AP above.

Share this post


Link to post
Share on other sites
Quote:
Original post by Unreal
Its true that environment variables can simply be faked, e.g. I can tell the computer to display me chinese messages by setting $LANG to the appropriate value. Well, then I have to live with the result ;) But it isn't dangerous to let the user write to any directory the user has write permissions for. Of course, it is best practise to check whether opening/writing files is possible instead of breaking the program. The only "security" issue would be that the user may overwrite the same files of another user, but that can (and should) simply be avoided by file permissions. Last but not least I second the hint of the AP above.


I agree with the above AP as well. I sometimes do that when I have a lot of work to do in a directory, so that a just typing "cd" will take me back there. Note that if I did that and then forgot to reset it:

$ export HOME="/some/dir"
(do lots of work in /some/dir and its subdirectories)
$ cd # back in /some/dir
$ commit # commit to some RCS
$ run_the_game # it uses $HOME to find the home directory,
and saves its data to /some/dir


The next time I run the game (without setting HOME to /some/dir), it won't find its previous data. In fact, I'm likely to delete /some/dir after a while, when the work is done and commited.

It isn't dangerous as in "security breach". My example was meant to illustrate that you just can't trust any environment variable to be correct. The user could simply unset HOME and getenv will return NULL, getpwuid will not. Would it be stupid to do that? Absolutely, but a program shouldn't misbehave because of that.

If one is dealing with setuid/setgid programs though, manipulating environment variables can actually lead to security issues. Even using sudo can have some annoying side-effects. Admitedly, games seldom require that, but now that *NIX-like systems can be used fully by anybody without any kind of training, you'll see a multiplication of "dumb" mistakes (like "setuid" a game with UID 0 because a forum post said that games run faster with root privileges). Learning so-called best practices is usually a good idea.

Of course, you can get getpwuid to return meaningless data just as well. LD_PRELOAD will do that. But that's definitely asking for it. [grin]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this