bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encoding multiple filenames in a single variable


From: Jon Seymour
Subject: Re: Encoding multiple filenames in a single variable
Date: Tue, 31 Aug 2010 08:14:58 +1000

On Mon, Aug 30, 2010 at 11:33 PM, Greg Wooledge <address@hidden> wrote:
> On Mon, Aug 30, 2010 at 11:25:00PM +1000, Jon Seymour wrote:
>> I am working on an extension to git, and need to store a list of shell
>> files that can be used to extend the capabilities of the command I am
>> writing. Most of the time, a variable of the form:
>>
>> GIT_EXTRA_CONDITION_LIBS="libA.sh libB.sh" would work, but technically
>> speaking, I do need to support spaces in the path (if nothing else,
>> git's test suite cunningly runs within a directory that contains space
>> in the name :-).
>
> If this is an environment variable, then you're screwed.  Environment
> variables can't be arrays, and if they could, they surely wouldn't be
> portable.
>
>> In the end, what I have done is make use of git's rev-parse --sq-quote
>> feature to quote filenames that can contain spaces. That way, if you
>> really want spaces in the filenames, you can have it, but if you
>> don't, then you get the convenience of space as a separator.
>>

>> So, for example:
>>
>>     GIT_EXTRA_CONDITION_LIBS="libA.sh 'lib B.sh' libC.sh"
>
> What does it do with filenames that contain apostrophes?  How do you
> read the filenames back out of this format?  The only ways I can
> think of off the top of my head to parse that kind of input in a
> script are eval and xargs, and those should send you screaming....
>
> There really is no good way to put multiple filenames into a single
> environment variable.  Your best bet is to put them in a file and
> make the environment variable point to that file.  The contents of
> the file would have to be NUL-delimited or newline-delimited.  I'm
> pretty sure that you'll end up going with newline delimiters and just
> saying "if your filenames have newlines in them, you lose, so don't
> do that".  Which is not the worst approach in the world.
>

All good points. I think I'll change tack slighty. git has a
configuration mechanism that can server to store lists that users
might want to configure and I can add an --include option where
required to allow wrapper commands to add their own libraries, as
required, thus eliminating the requirement to inherit such lists from
the environment.

Thanks again.

jon.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]