You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/04/17 21:16:09 UTC
Split paths portability
While we consider Stas' ideas for a portable tmpdir, we should also consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms. I dunno what NetWare does here, anymore.
Two options; the one I like best (I think) is returning an apr_array_header_t *
allocated based on a pool arg. Contrawise, we should also have a function
that returns a char* from an apr_array_header_t. Something like;
apr_array_header_t *apr_filepath_list_split(const char *pathlist,
apr_pool_t *pool);
char *apr_filepath_list_join(apr_array_header_t *paths, apr_pool_t *pool);
Any objections?
Bill
Re: Split paths portability
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:29 PM 4/17/2002, you wrote:
>William A. Rowe, Jr. wrote:
>>While we consider Stas' ideas for a portable tmpdir, we should also consider
>>breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
>>as well.) These semantics change considerably from Win32 to unix and
>>other platforms. I dunno what NetWare does here, anymore.
>
>If you need the implementation details look at how Perl does it. it's in
>File::Spec which is a set of function working on Files/Dirs crossplatform.
Thanks. Those too would be good. I was first considering simply splitting
apart paths from a list. While a variable such as TEMP or TMP can simply be
passed to apr_filepath_merge(), you can't do that with path lists like PATH,
LIB or INCLUDE.
Re: Split paths portability
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> While we consider Stas' ideas for a portable tmpdir, we should also
> consider
> breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
> as well.) These semantics change considerably from Win32 to unix and
> other platforms. I dunno what NetWare does here, anymore.
If you need the implementation details look at how Perl does it. it's in
File::Spec which is a set of function working on Files/Dirs
crossplatform. In this particular case these are the functions you want
to look at:
splitpath
splitdir
catdir
catfile
and a few other useful functions.
Currently Perl includes implementations for:
/home/stas/perl.org/perl-current/lib/File/Spec/Cygwin.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Epoc.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Mac.pm
/home/stas/perl.org/perl-current/lib/File/Spec/OS2.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Unix.pm
/home/stas/perl.org/perl-current/lib/File/Spec/VMS.pm
/home/stas/perl.org/perl-current/lib/File/Spec/Win32.pm
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Split paths portability
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 02:16 PM 4/17/2002, William A. Rowe, Jr. wrote:
>While we consider Stas' ideas for a portable tmpdir, we should also consider
>breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
>as well.) These semantics change considerably from Win32 to unix and
>other platforms. I dunno what NetWare does here, anymore.
>
>Two options; the one I like best (I think) is returning an
>apr_array_header_t *
>allocated based on a pool arg. Contrawise, we should also have a function
>that returns a char* from an apr_array_header_t. Something like;
>
> apr_array_header_t *apr_filepath_list_split(const char *pathlist,
> apr_pool_t *pool);
> char *apr_filepath_list_join(apr_array_header_t *paths, apr_pool_t *pool);
Hmmm. While I think about this, I also suppose we aught to add the same flags
option we pass to apr_filepath_merge and family.
We should allow the user to retrieve a list of APR_FILEPATH_NATIVE strings, or
by default, turn them into APR-recognized format (e.g. forward slashes on
Win32,
etc.) And on apr_filepath_list_join, we should allow APR_FILEPATH_NATIVE to
create platform-recognized paths for substitution as the PATH variable, etc.
Other thoughts or observations?
Bill