Lars Gullik Bjønnes wrote:
> | Just committed. Attached FYI.
>
> | +/** Given a string "<glob> <glob> <glob>", expand each glob in turn.
> | + * Any glob that cannot be expanded is ignored silently.
> | + * Invokes \c convert_brace_glob and \c glob internally, so use only
> | + * on systems supporting the Posix function 'glob'.
> | + * \param mask the string "<glob> <glob> <glob>".
> | + * \param directory the current working directory from
> | + * which \c glob is invoked.
> | + * \returns a vector of all matching file names.
> | + */
> | +vector<string> const expand_globs(string const & mask,
> | + string const & directory)
> | +{
> | + Path p(directory);
>
> We should work very hard to get rid of this Path stuff. (I have that
> as one of my small projects.)
> Currently it is like a gobal variable, multi-threading (if we ever go
> there) will get really strange bugs because of this.
If we ever go there...
> | + for (; it != end; ++it) {
> | + vector<string> const tmp = lyx::support::glob(*it);
>
> So possibly this glob should also take a dir param (and not use chdir
> in any way to get the result)
The existing lyx::support::glob() is just a wrapper for the system glob().
As such, Path will be used even if the function takes a dir param.
My replacement function does take a dir param and does not use chdir:
template <typename StorageT>
void glob(StorageT & matches,
std::string const & pattern,
boost::filesystem::path const & working_dir,
glob_flags flags);
I'm not yet ready to replace the existing function with this (because I
have still to ensure that boost::throw_exception() is not called should
the transformed globbing pattern upset boost::regex). However, I can
certainly change the function API to take a dir parameter.
--
Angus
