apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stribblehill <a.d.stribbleh...@durham.ac.uk>
Subject Re: [RESEND] [PATCH] Add apr_uid_shell_get
Date Wed, 04 Aug 2004 07:55:53 GMT
Quoting Cliff Woolley <jwoolley@virginia.edu> (2004-08-04 00:14:28 BST):
> On Tue, 3 Aug 2004, Andrew Stribblehill wrote:

<snip justification and usage case>

> > To this end, I need a function to query the user's shell. It seems
> > sensible to me (though I am new to apr) that it should go into apr.
> 
> The problem is that there's no portable concept of a shell, right?  I
> mean, users on Windows all get the same shell (or at least there's no
> shell associated with their uid as such), and certainly this wouldn't
> apply to netware... how would those platforms be handled, besides
> returning APR_ENOTIMPL?  I don't think they can be.  Typically our policy
> in APR has been that we provide the lowest common denominator of
> functionality... if a concept doesn't map onto anything but unix, we would
> tend to be hesitant to make it part of APR.  That's not to say there are
> no non-portable things in APR, but they're all stuffed away in apr_os_*...
> I guess maybe if this were apr_os_shell_get() I'd be more willing to
> consider it.  :)

That's true. I'm very new to APR so I didn't quite see it. If it were
apr_os_shell_get(), would a Windows APR return APR_ENOTIMPL or would
the function just not exist?

-- 
FISHER
NORTHEASTERLY 4 OR 5 BECOMING VARIABLE 3. OCCASIONAL RAIN. MODERATE

Mime
View raw message