GNOME Bugzilla – Bug 309475
[PATCH] add g_get_user_shell (returns user preffered shell)
Last modified: 2011-02-18 16:14:11 UTC
Please describe the problem: based on gnome_util_user_shell http://cvs.gnome.org/viewcvs/libgnome/libgnome/gnome-util.c?rev=1.81&view=markup Index: glib/gutils.c =================================================================== RCS file: /cvs/gnome/glib/glib/gutils.c,v retrieving revision 1.174 diff -u -r1.174 gutils.c --- glib/gutils.c 22 Jun 2005 09:02:41 -0000 1.174 +++ glib/gutils.c 4 Jul 2005 19:34:11 -0000 @@ -1362,6 +1362,7 @@ static gchar *g_tmp_dir = NULL; static gchar *g_user_name = NULL; static gchar *g_real_name = NULL; +static gchar *g_user_shell = NULL; static gchar *g_home_dir = NULL; static gchar *g_host_name = NULL; @@ -1470,6 +1471,9 @@ { g_tmp_dir = g_strdup ("/tmp"); } + + g_user_shell = g_strdup(g_getenv ("SHELL")); + #endif /* !G_OS_WIN32 */ #ifdef G_OS_WIN32 @@ -1511,6 +1515,14 @@ if (!g_home_dir) g_home_dir = get_windows_directory_root (); + + + g_user_shell = g_find_program_in_path ("cmd.exe"); + + if (!g_user_shell) + g_user_shell = g_find_program_in_path ("command.com"); + + #endif /* G_OS_WIN32 */ #ifdef HAVE_PWD_H @@ -1606,6 +1618,9 @@ if (!g_home_dir) g_home_dir = g_strdup (pw->pw_dir); + + if (!g_user_shell) + g_user_shell = g_strdup(pw->pw_shell); } g_free (buffer); } @@ -1736,6 +1751,28 @@ } /** + * g_get_user_shell: + * + * Retrieves the user's preferred shell. + * + * Returns: A newly allocated string that is the path to the shell. + * + * Since: 2.8 + */ +G_CONST_RETURN gchar* +g_get_user_shell (void) +{ + G_LOCK (g_utils_global); + if (!g_tmp_dir) + g_get_any_init (); + G_UNLOCK (g_utils_global); + + return g_user_shell; +} + + + +/** * g_get_home_dir: * * Gets the current user's home directory. Index: glib/gutils.h =================================================================== RCS file: /cvs/gnome/glib/glib/gutils.h,v retrieving revision 1.36 diff -u -r1.36 gutils.h --- glib/gutils.h 22 Jun 2005 08:54:28 -0000 1.36 +++ glib/gutils.h 4 Jul 2005 19:34:11 -0000 @@ -115,6 +115,7 @@ G_CONST_RETURN gchar* g_get_user_name (void); G_CONST_RETURN gchar* g_get_real_name (void); +G_CONST_RETURN gchar* g_get_user_shell (void); G_CONST_RETURN gchar* g_get_home_dir (void); G_CONST_RETURN gchar* g_get_tmp_dir (void); G_CONST_RETURN gchar* g_get_host_name (void); Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
This could use some more checking. What if g_find_program_in_path (); fails? Also, g_get_any_init() does not cope with the case that a passwd lookup fails. Both can happen, and will leave g_user_shell unset, which will cause a crash (g_get_user_shell is not documented to return NULL on failure). Failure CAN happen. I've been using glib in a chrooted program recently, and the passwd/group databases may not be present in the chroot... If unset, please set it to a secure default, such as "/bin/false". Regards, Roger
The return type doesn't match the description: + * Returns: A newly allocated string ... +G_CONST_RETURN gchar* +g_get_user_shell (void) +{ +} Cheers -Tim
Under win32 you should try the COMSPEC environment variable before searching for cmd.exe and command.com.
Created attachment 48684 [details] [review] look at comspec and updated documentation
I preffer letting it return NULL instead of /bin/false updated documentation about it
What conceivable use would an application have for a function that reutrned cmd.exe/command.com on Windows and /bin/bash on Unix?
anjuta and gnome-terminal seem to be using it.
I was asking about the win32 support in particular.
I think the most interresting thing is for win32 users to know if it is command .com or cmd.exe and where it is located. but I agree that you can know this from looking at the windows version and looking up the file in the system directories. But isn't using a shared clean api better for this?
I agree with Owen in that can't think of any sensible cross-platform use of this function, in the sense that the return value could then be used for something that would work cross-platform as such. Any caller would also have platform-specific code to do whatever is necessary with the return value. Yes, I did add Win32-specific code to gnome_util_user_shell(), but that was mostly just so that code that calls it would compile without ifdefs. (I.e., I didn't want to just ifdef out gnome_util_user_shell() from libgnome on Win32.) Later when I actually get around to debug some caller of gnome_util_user_shell() on Win32, I presumably will have to add Win32-specific code to the caller to do whatever is necessary.
the windows program will have to detect if it is command.com or cmd.exe anyway. So why not use this function for that purpose?
I'd rather have this function return a POSIX shell or failure and then, if it turns out that a Win32 shell retrieval function is useful, then have a separate function for that. To me, a function isn't actually a cross-platform convenience function if you can't write unconditional code that uses the result... so it's just stuffing two unrelated operations under the same function name.
split it up in: g_get_user_shell_posix (void) g_get_user_shell_dos (void) do you agree on these names? and with failure you mean returning NULL ?
the windows variant would probably be g_win32_get_shell(), since it would probably only live in gwin32.h, right ?
Created attachment 48740 [details] [review] g_posix_get_shell and g_win32_get_shell win32 code isn't tested, need review
since glib seems to be in api freeze can this still be added?
I think this has very marginal value